Category: PCI

Analogy: A family member needs surgery, and you have two doctors in a side-by-side bake-off. One is respected, enormously experienced, and expensive. The other is fresh out of residency, inexperienced, and cheap.

Whom do you go for?

Unless you’re a sociopath, you pay for the one with the greatest expectation for success. So by a similar (though far less life threatening) extension, why would you cheap out on your choice of QSA? Or any consultant that matter?

Not only that, you probably expect the same results from every QSA, right? They all went through the standard training, so they should all be the same, right?

Are all doctors the same?

Like any profession, you have a MINIMUM standard to achieve before you start. For QSAs it’s 5 years in security (no-one lies on CV’s/resumes, right?), OR a CISA/CISM/CISSP (anyone can read a book and pass a multiple choice test), AND pass the QSA test. I can, quite literally, take ANY person and get them to a point they can pass that test in one week.

Instead of focusing the QSA test on their domain knowledge (networking, encryption, policy formation etc.) it focuses on merchant / service provider levels and a bunch of other stuff that does not test the consultant’s security or auditing skills in any fashion that makes sense to me. Can they read a firewall ruleset to determine if they have met the intent of requirements 1.X? Can they look at a netstat and see if their OS configuration standards are being followed per requirements 2.x?

The answer to those questions is; not necessarily, and while I cannot think of one security consultant who is an expert on all 12 DSS sections (I suck at encryption and anything to do with coding for example), you need someone with real-world experience to measure your compliance against not only the standard, but its intent. And if that intent does not align with the goals of the business in question, the process falls apart.

When it comes to PCI, you’re paying for experience / guidance / been-there-done-that, otherwise you’re better served doing it yourself. At least you know the business better than the QSA ever will.

I wrote something resembling a white paper on Selecting The Right QSA For Your Business a few months ago, and will be building on this process over the next few months. Anything is simple if you know how to do it, but that’s the point; YOU probably don’t know how to do PCI, nor would you then know the right questions to ask to find someone who does.

This may sound like I’m trying to push you into hiring only the expensive guys, but that’s not it, it’s never just about the money, it’s about VALUE for, and appropriate USE of, money. The issue most often is that businesses choose their QSA based on price. They didn’t want to do PCI compliance in the first place (believe me, no-one WANTS to do PCI), and therefore settled for the lowest bidder.

In my fairly significant experience, the cheapest QSA up front rarely ends up being the cheapest in the end. These are the top 5 things to watch out for, and reflect the SOPs of some of the less scrupulous vendors;

  1. Scope Creep – A proposal written in such a way that you THINK you’re buying what you need, but you end up having to buy additional services from them to finish the job;
    o
  2. Cheap Labour – You get what you pay for, and if you pay pennies, you’ll get the least experienced QSA at their disposal (this one serves you right by the way);
    o
  3. Pushing Other Services or Products – Some of the larger QSAs have entire suites of products and services they try and push your way. They will sell the QSA for cheap hoping to massively up-sell/cross-sell the more profitable managed services / products etc. This is permissible under the SSC regs., but hardly best practice, and in some cases even ethical, especially when the products don’t even support your compliance;
    o
  4. Lack of Appropriate Guidance – Achieving PCI compliance the first time is a project, staying complaint is a process. At no time during the assessment should there be roadblocks that are a direct results of the QSA’s inexperience. Projects that should take months often take years, and the additional costs can be significant;
    o
  5. The True Cost of Compliance – Usually the most significant cost of a PCI project is the labour cost of internal resources. Performed correctly, PCI can have significant benefits in terms of improved security posture, but unless the resources are used efficiently, the cost to the business can be very significant, especially in terms of availability for initiatives related to transformation or innovation.

In the end, you will get what you pay for, and if you have not chosen your QSA based on best-fit, you deserve what you get. Choosing a QSA / consultant is relatively simple, and I believe that It Takes A Consultant, To Hire A Consultant.

If you need help, do your homework, then ask the opinion of someone with zero vested interest.

[If you liked this article, please share! Want more like it, subscribe!]

Well, here it is, and I just can’t figure out why I’m actually disappointed. I saw the draft, I knew there could be no radical changes, yet somehow I was expecting a little more than this. I guess the phrase; “It is what it is.” is actually appropriate this time, and not just the recourse of people who have neither the vision nor the abilities to make positive change.

In the downloads section is the spreadsheet PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx, which is the final v3.0 standard, mapped back to v2.0 (my mapping, not the SSC’s), with my comments.  Help yourself.

For those of you who helped take your organisation through v2.0, and are worried about what v3.0 means to you, don’t be. You may have seen a bunch of articles about how it’s so much more detailed, how it’s going to take longer to assess, or how you should be taking every training course under the sun to get to grips with it. Don’t believe them.

It’s not that different, and if any organisation tries to gouge you for more money off the back of it, fire them. The ONLY reason to accept more services from your security service providers it to meet your BUSINESS goals as dictated by your risk and business continuity management programmes. As I have stated too many times; in terms of a security programme done properly, PCI compliance starts in the wrong place, ends in the wrong place, and is only relevant to cardholder data, which means the rest of your business may left exposed. So if you DO buy more pen testing / scanning / consultancy etc, do so for your business, not for PCI.

The less scrupulous QSAs and QSACs may point to the additional validation effort as a reason for raising their prices, but if they had been doing their jobs properly under v2.0, the difference is minimal. This effort has been required for at least 2 years under the SSC’s RoC scoring mechanism, not to mention the intent of the standard in the first place.

So what this really means to for the next three years is business as usual (BAU). Not the; we’re-doing-the-right-thing-for-our-business BAU, but the; this-is-no-different-so-let’s-ignore-the-opportunity-to-do-the-right-thing-for-our-business BAU. If there is any lesson that has been ignored more than the need to automatically cover compliance in a business-wide security programme, I don’t know what it is.

Service providers, payment gateways, PSPs, and of course, QSAs, all have a vested interest in the status quo when it comes to PCI. Whether it’s for marketing purposes, competitive advantage, or nearly the entire revenue source, PCI now has a life of its own. Given its 3 year life-cycle, and the impossibility of radical changes DURING that cycle, it will never break out of its limitations and be the driver for enterprise-wide good security practices that it could so easily have been.

Just a few small adjustments could have brought it more in line with what every business SHOULD be doing:

  1. Risk Assessment – Bring it to the very forefront in terms of importance. Instead of shoving down in section 12, the so-called ‘paperwork’ section, it should be a prerequisite to even begin the compliance program. Every known good practice, enterprise-wide, business saving security framework starts with a risk assessment, why not PCI?
    o
  2. Policies and Procedures – If you don’t know how policies and procedures not only form the foundation upon which any security programme is founded, and how they represent the entire security CULTURE of an organisation, maybe you should consider changing fields.
    o
  3. Security Awareness Training – Built on the policy and procedure foundation, and represents the single most effective way to reduce risk in ANY organisation. It can also be one of the cheapest.
    o
  4. Formation of a Governance Committee – This does not have to be the enormously complicated structure it may sound, it can be just one representative from each department meeting on a monthly basis to discuss the business. The business side wants more profits, the technical side wants to help enable that profit. If BOTH sides are made aware of each other’s needs, security will finally be performed appropriately, and not because of some external driver.
    o
  5. Make the CEO accountable for compliance – I cannot believe this one has never been introduced. It’s the CEO who could solve almost every issue experienced by organisations faced with achieving PCI compliance, yet it’s delegated to the people without either the influence, the budget, and often the expertise to do so. As much as possible in a non-government regulation, make the CEO personally accountable for compliance failures, or don’t be surprised when organisations lie to their assessor to make the whole thing go away.

Except for the last two, these things are IN the standard, and have been from the beginning. All, that needed to be done was increase their importance, provide PROPER guidance related to their position within accepted good security practice frameworks, and let the CEO know that if they fail to provide the correct support for the programme that THEY will be responsible for losing their credit card acceptance ‘privileges’. Maybe that will get their attention.

Gone way over my word limit, so I’ll end with my favourite phrase; Security is not easy, but it CAN be simple.

PCI compliance is no different, not ‘even’ v3.0.

Apparently an announcement was made at the PCI SSC ‘s Community Meeting in Nice that “European Payment Services (EPS), [is] the first company to have a solution listed…“, this according to Tenable’s Jeffrey Man in his new article ‘What’s Wrong with P2PE‘.

I’m not going to go into why P2PE is dead from a PCI perspective, Jeff covered that better than I can, instead I’ll cover it from an innovation and real-world perspective that the SSC simply cannot / will not include in their presentations.

Why P2PE is pointless, and dead before it reached the gate:

  1. If you have read the P2PE assessment procedures (which were about 2 years too late in being released), you’ll know that they make the PCI DSS look like a nursery rhyme. EXTREMELY complicated, and ENORMOUSLY expensive to achieve certification. I was, however, very surprised that PED / payment terminal companies with significant resources (like VeriFone and Ingenico) didn’t get into a race to corner the market early, but now it makes sense;
    o
  2. P2PE done the SSC’s way still requires PTS and SRED compliant payment terminals, which are massively expensive, and whose days are numbered. Mobile payments, and whatever comes next will, thankfully, kill retail’s reliance on payment terminals and bring secure, non-cash, payment capability to every merchant world-wide, no matter how small, or large and distributed;
    o
  3. Chip & PIN (EMV) technology is tied to the terminals and to the use of credit cards, which along with payment terminals, are dying technologies. Credit cards are 60+ years old, and EMV was a very poor patch to fill a gaping hole in credit card security, so innovation will, and in some cases already has, replaced the need for both;
    o
  4. Retailers are simply not going to make the massive investment in replacing their payment terminal estates before they end of life (EoL) just because of a possible reduction in PCI scope. And why would they then spend a fortune in expensive devices, tie themselves into a single service provider, as well as limit themselves to credit card transactions? Answer; they wouldn’t, not unless they’re irretrievable stupid;
    o
  5. The entire payment space is finally recognising the fact that it’s bloated, inefficient, enormously outdated, and complex. Innovation will simplify it back to its basics, which it that it’s not ABOUT payments, it’s about authentication. I don’t care how I access my funds, whether they be debit or credit (both of which are provided by the bank anyway), I just want to do it whenever I want, wherever I want, and without risk.

Any protection the card brands provide related to fraud and consumer protection can be provided cheaper and probably better by the banks, and this, along with the demand for better customer service, will drive the banks to compete for our business as never before. Gone will be the days that they can act as though they are doing US a favour.

As for the SSC’s announcement, I can’t blame them for wanting to announce any kind of success, God knows the DSS v3.0 is nothing to write home about.

[If you liked this article, please share! Want more like it, subscribe!]

I provided my first PCI guidance way back in 2005, and my first on-site assessment was in 2006. Since then I have performed dozens of on-sites across the globe, my last one in 2009. Until December 2012, I ran teams that delivered PCI assessments across EMEA and APAC, all of whom followed a proven methodology that took all the guesswork out of how to achieve compliance, and STAY compliant.

Over the last few months, my changed circumstances have led me back into the PCI weeds, and frankly, I am more than a little disappointed. The payment card industry is no closer to ‘getting it’ than they were 8 years ago, and the guidance provided by a significant portion of PCI professionals leaves a lot to be desired.

After >8 years, the industry SHOULD be integrating their PCI assessment processes into some form of overarching security framework, re-certification SHOULD be nearing business as usual, and QSA quality should have improved.

They’re not, it’s not, and it hasn’t respectively.

I have written several articles on the major issues with the DSS, and what to do about them, I have stated more times than I probably should that the problems begin and end with the CEO, and I have repeatedly quoted my tag-line;

“Security is not easy, but it can be simple.”

I even wrote white papers on How to Sell Security (and therefore how to BUY security), and Selecting The Right QSA For Your Business in an effort to help standardise and optimise the most important step towards compliance; asking for help.

For some reason this has not had the industry changing effect I had expected. Surely my 18 subscribers – 4 of whom are family members – should have had a bigger impact than this!? [uncomfortable silence]

I have said for a few years now that I should put all of my experience into a PCI self-help book. Well, now I’m going to. Not all at once mind you, I’m going to write each chapter as a stand-alone ‘white paper’ over the course of the next few months, and will request your feedback on each. When they are as polished as they are going to be, maybe I’ll try to get it published, but I’ll still give it all away here on my blog.

I will also include any tool-sets I use to conduct an assessment (plus samples / examples), and I will provide options for free-ware / cheap-ware tools that I have seen be of some use. I will NEVER recommend anything, and only offer up options upon which you must perform your own due diligence. I may highlight my OWN preferred solutions, but the choices, and therefore responsibility, will always be yours.

These are the chapters I have in mind, and in this order:

  1. So You Want To Be PCI Compliant? (a.k.a. Buy Nothing Until You Read This!)
  2. Biased Perspective – What The PCI DSS Is, And What It Can Never Be
  3. Prepare Your Organisation (i.e. Your CEO) For The Assessment
  4. The Assessment Pre-Requisites
  5. Report on Compliance Executive Summary – If You Can’t Write This, Start Again
  6. DSS Requirement 1 – Networking Stuff
  7. DSS Requirement 2 – System Configuration Stuff
  8. DSS Requirement 3 – Encryption Stuff
  9. DSS Requirement 4 – More Encryption Stuff
  10. DSS Requirement 5 – Anti-Virus Stuff
  11. DSS Requirement 6 – Vulnerability Management, Change Control, Secure Coding Stuff
  12. DSS Requirement 7 – Access Control Stuff
  13. DSS Requirement 8 – Password Stuff
  14. DSS Requirement 9 – Physical and Back-Up Stuff
  15. DSS Requirement 10 – Logging Stuff
  16. DSS Requirement 11 – Testing Stuff
  17. DSS Requirement 12 – Policy, Training & Incident Response Stuff
  18. Compensating Controls
  19. Validation and Evidence Collection
  20. The Holy Grail of Security, Continuous Compliance Validation
  21. The Future Of PCI – Things To Bear In Mind

There are entire companies founded on, and still making fortunes from, PCI. I can, quite literally, thank PCI for my entire career in security (well, that and Windows), but it’s time we put PCI into the proper perspective, and start spending that money on the only thing that makes sense; staying in business responsibly.

If anyone would like to collaborate of any of these chapters, feel free to reach out to me. Especially encryption!!

PCI DSS

Now that I’ve had the opportunity to review the full draft standard, it’s clear that there’s very little that’s difficult for you to achieve in the short term if, and I mean IF, you were doing PCI properly from v2.0 onwards. The majority of the changes are simple clarifications, and if your QSA was doing their validation and QA correctly, you would already be doing 99% of them.

That’s really all v3.0 is; a closer approximation to the Report on Compliance (RoC) scoring mechanism that’s been around for years. I understand the clarifications and the guidance are supposed to bring everyone’s understanding of the INTENT of each requirement into closer alignment, but all that does is reflect very badly on the current quality of the QSAs and the available guidance.  The corollary is that the QSA and ISA training needs some serious attention, and the DSS needs to focus less on the detail, and more on the senior management buy-in.

I also understand that it is VERY difficult to make dramatic changes to a standard when organisations have already invested significant capital and resources into achieving compliance. But even the SSC made it VERY clear from the beginning that the DSS was a MINIMUM set of controls around a single form of sensitive data, and should not be seen as a security programme that meets the entire business’s needs (per the PCI DSS v3.0: “PCI DSS comprises a minimum set of requirements for protecting cardholder data…“).

So why aren’t the changes in v3.0 more significant?  Or more in line with good practices?  I don’t really have a constructive (a.k.a. non-soapbox) answer to that, so I’ll focus on what I perceive to be the major flaws.

Here’s my Top 3 Flaws:

Governance:  This has as many definitions as there are people defining it, but in the end it’s very simple; Governance is the Business side and the IT side having conversations.  Business has the requirements (growth, profit, transformation etc.), IT has the enablement, and the organisation as a whole moves forward appropriately. Nothing should happen in an organisation outside of this framework if the business wants to grow/innovate/adapt effectively (for more see Security Core Concept 4: Governance & Change Control and Security Core Concepts: Tying it All Together)

Guess how many times the word ‘Governance’ (or equivalent) appears in v3.0?

Not once.

Risk Assessment (RA): The whole business/IT/security life-cycle starts with a risk assessment.  The business wants something, the RA determines the balance of risk/reward, and you move on to implementation if the balance is favourable.  The DSS calls for a RA, but it’s still woefully understated, and stuck down in the ‘paperwork’ section (Section 12).  This should have been performed even before you chose a QSA, should be intrinsic to services you eventually receive from them, and should have driven all purchase(s) of technology used to achieve both compliance and security in general (for more see Security Core Concept 1: Risk Assessment / Business Impact Analysis).

The Risk Assessment even had its own Special Interest Group (SIG) to improve the quality of the guidance, but the results were so watered down as to be ineffectual.

Sampling: MUCH better explanation than previously, but it’s missing the most important phrase; “There is no sampling in PCI DSS validation unless the client can reasonably demonstrate how all ‘like’ systems are configured and maintained identically, managed and monitored centrally, and are promoted into production through a well defined and documented  process.”

For too long sampling has been seen as a right, it’s not, it’s a privilege (like spandex). Saying “Sampling is an option…” is not enough to avoid clients demanding ‘pragmatism’ from their QSAs in the ‘this-is-too-difficult’ sense of the word.

I have so much more to say, and some of it is actually positive (like pushing policy enforcement validation), but I’ve already overrun my self-imposed word limit.

Finally, every organisation that relies totally on PCI for their security deserves to be hacked – sorry, but you do – but the SSC and the card brands still have an obligation to do more to evolve the standard into something that can be integrated seamlessly into an established, and comprehensive good-security-practice framework.  By the time the DSS catches up with the real world of security, payments will have moved on from payment cards.

Just ask any non-QSA security expert what you should be doing with your IT budget, I’ll bet it’s not PCI compliance.

[If you liked this article, please share! Want more like it, subscribe!]