Tag: PCI

Last week I had the pleasure of conducting a 1 day Advanced PCI course that included details of the changes between v2.0 and v3.0. It was clear that there is not only continued confusion regarding the ‘new’ content, but that the less scrupulous vendors of QSA and penetration testing services are using this confusion to charge more for the same service.

I have warned of this previously, but let’s be very clear. If you are being asked for more money based on the v3.0 changes, your service provider is:

  1. Confused about what the changes mean themselves;
    o
  2. Covering up for not performing their work properly in previous years;
    o
  3. Lying to you.

I fully understand the pressures QSA companies are under with regard price compression, competition and so forth, but using this DSS update to raise prices is unconscionable.

Here is an example;

Requirement 1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

In v2.0 of the DSS the ‘Testing Procedures’ states; “1.3.3 Verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”

In theory, the QSA could just say; “[QSA company] verified that direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.” However, in the ‘ROC Reporting Instructions for PCI DSS v2.0, September 2011‘ your QSA is responsible to do far more;

 Identify the network documents/diagrams specifying that direct connections are not allowed for traffic between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed firewall/router configurations prevent direct connections between the Internet and the cardholder data environment:

i. Inbound ii. Outbound

 Describe how observed traffic between the Internet and the cardholder data environment confirms that direct connections are not permitted:

i. Inbound ii. Outbound

Now look at v3.0; “1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.”

Other than changing ‘verify’ to ‘examine’, the reporting instructions are STILL not fully built into the new standard, but are getting closer. So the vast majority of the DSS v3.0 is just clarification of validation requirements based on a document that is already more than 2 years old.

To put this another way; your QSA and YOU were responsible for performing 95% of what’s in the v3.0 for the last 2 years. The other 5% are things you SHOULD have been doing anyway if your QSA was doing their job, and you were doing security properly:

2.4 – Maintain an inventory of system components that are in scope for PCI DSS

Seriously? How could you have EVER achieved compliance without having an asset inventory of some sort?

6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Verify that coding techniques actually address the ‘high vulnerabilities’? What ELSE would it be doing?

8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. 

The sad part is that they actually had to add this, as a lot of breaches were caused by NOT having this in place. Vendor due diligence is almost universally poor across PCI relevant service providers, and this is entirely the fault of each organisation, not the SSC.

9.9 Examine documented policies and procedures to verify they include:

 Maintaining a list of devices

 Periodically inspecting devices to look for tampering or substitution

 Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices

If you weren’t doing this already you deserve what you get.

10.x [Logging Stuff]

Significant clarification of what’s expected in logging and monitoring, and will only negatively impact those organisations doing the bare minimum to get through PCI.

11.3.x [Penetration Testing Stuff]

Nothing in here is different from the intent of penetration testing all the way back to v1.0, and if your QSA says things have changed, they have been doing it wrong all along.

12.8.x [Service Provider Stuff]

The only organisations this will negatively affect are service providers who were hiding the true extent of their service coverage, and clients trying to outsource responsibility of PCI compliance to others. If your organisation’s vendor due diligence and vendor management programs don’t already cover this, it’s your fault.

If you want a more complete listing of the changes, go here; PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx

Every QSA company has training courses, white papers, presentations and God knows what else trying to explain the difference between v2.0 and v3.0. If you want to save your time and money, learn how to do SECURITY properly and PCI will make perfect sense.

Take the phrase ‘cardholder data’ out of the DSS and replace it with ‘personal information about your family’. Name ONE requirement you don’t want in place?

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