Tag: PCI

After last week’s blog, where I challenged the relevance of the PCI DSS v3.2 (and basically the relevance of the entire standard itself), I received a number of comments questioning my reasoning. As is always the case, opinions differ, and while I have no intention of trying to change the mind of those who disagree with me, I will at least attempt to put together a more lucid argument around my position. This will consist of a summary of the various points I have made on this topic in numerous blogs over the last 2.5 years.

First though, let me stress that I do not believe the PCI DSS is all bad. I do believe it is managed poorly, and that it in no way represents a valid security program / framework, but in reality, it was never designed as such. It was a minimal set of security controls the cards brands wanted in place around their data in order to keep government regulators off their backs. Basically smoke and mirrors with some minimal risk reduction thrown in for appearances.

These are my Top 10 arguments for the irrelevance of PCI:

  1. 50+ Year Old Technology: You wouldn’t gut-refurbish a house you intend to knock down would you? So why would you spend a fortune on PCI compliance when it’s clear you’ll need whole new payment channels for mobile, the Internet of Things, and whatever comes after that? Cardholder data cannot be protected at a reasonable cost …ever, and as the influence of the card schemes wanes, the thieves will move on to whatever is most popular.
    o
  2. QSA Training: Almost, but not quite, an oxymoron, and one of the biggest reasons PCI became such a waste of time. The requirement for 5 years of security experience on a resume/CV was completely inadequate (and often faked). QSAs needed to be security consultants first and foremost, what we got was a bunch of auditors who completely missed the point. The point should have been that the DSS was a MINIMUM set of controls, and that real security was never to be found in compliance alone. The QSA training is absolutely pitiful.
    o
    Why does no-one question the fact that not one QSA on the planet is an expert in all 12 requirements? Every assessor has skills and weaknesses, yet they are permitted to assess the compliance of all areas. No client wants to pay for TWO assessors, and a minuscule number of QSAs actually sub the validation of their weaker subjects. Why? Because they don’t have to.
    o
  3. Conflict of Interest: There is still a LOT of money in PCI, billions in fact, and there are many QSA companies out there that can credit their entire existence on the back of that money. The competition is fierce, and given the fact that every organisation going through compliance has 100% control over the commercials, means that QSAs have to be extremely ‘pragmatic’. I have personally had organisations tell me that if I did not loosen my interpretation they would find someone who would. They were dumped as clients immediately of course.
    o
    The second conflict of interest is that you can sell your client a firewall [for example], manage it for them, monitor the output, vulnerability scan and penetration test it, AND assess it for compliance. No due diligence required on how you perform checks and balances, all you have to do is be up front about it. Utterly ridiculous.
    o
  4. Risk Assessment: The PCI DSS is the result OF a risk assessment, one performed by the card schemes themselves. That’s what the control requirements ARE! If it was a true risk assessment, the PCI assessment itself would be a choice, not mandatory, and there would exist an ability to accept residual risk. There isn’t. In fact, the only point of the risk assessment in PCI is to decide if you need to go above and beyond, and who in their right mind would do that if they didn’t have to?
    o
  5. Scope: It is the role of any good QSA to help a client reduce the scope of their assessment as much as humanly possible. This makes perfect sense from a risk-to-cardholder-data perspective, but when ALL a client’s focus is on the remaining CDE, the rest of the business suffers. In most organisations personal data is far more prevalent, and with the GDPR looming, a much more sensitive asset. Only an organisation-wide security program makes sense, one that’s in line with business goals, not just a single set of commercial obligations.
    o
  6. Governance: Easy, there isn’t any, and the word does not even appear in the PCI DSS. Not once. How are you supposed to run a risk assessment, determine control implementation in line with business continuity plans AND enforce repeatable processes to keep the controls in place without some form of governance?
    o
  7. Weak Controls: I have covered these ad nauseam; from the continued use of the word ‘periodic’, to lack of management systems framework, to logging and monitoring, the control requirements have always been, and will always be inadequate for real security. Perhaps this wouldn’t be so bad if the SSC didn’t keep saying things like; “[PCI] provides the most complete set of data security standards available globally.”, which in my view is nothing short of irresponsible.
    o
  8. Validation & Sampling: Sampling is supposed to be a privilege, not a right, and sampling starts at 100% until a client has earned a reduction. Systems that are installed the same, kept the same, managed the same, monitored centrally, ALL must be in place before sampling is an option, but try telling a client they must provide 10,000 pieces of evidence to achieve compliance (see 3. Conflict of Interest above).
    o
    Don’t get me started on the annual ‘point-in-time’ aspect. What security standard could possibly accept validation evidence that’s 364 days old? Nothing in the PCI DSS says you can’t.
    o
  9. Disaster Recovery & Business Continuity: These receive the very barest of lip-service, and frankly, even that is none of the card brand’s business. Beyond incident response, a company’s ability to get back online and stay in business is their own affair, so why even put “* Business recovery and continuity procedures” in 12.10.1 if not to create another illusion of best practice?
    o
  10. Threat Landscape: With a 3 year life-cycle and a complete inability to change radically, the PCI DSS is, and will always be inadequate to address current, and especially zero-day, threats. PCI compliance would spit out the back of a security program done well, ‘just compliance’ will always fall well short.

Basically PCI compliance is like being pressured into hiring the CEO’s son, no matter how lazy or incompetent the kid is, you can’t fire them. All you can do is marginalise them so they don’t actually do any real harm.

I have used the phrase “I hate PCI!” for almost 10 years now, and given that PCI has been directly responsible for funding my career, I may seem more than a little ungrateful. But it’s not about hating PCI, or even the SSC, it’s about making those who need help most pause, hopefully laugh, and above all, listen.

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

In a recent article in SC Magazine; “An Inconvenient Truth: New Customer Data Regulations Coming” Jeremy King of the SSC suggests that Payment Card Industry (PCI) “provides the most complete set of data security standards available globally.” I can only assume he means that the PCI Data Security Standard (DSS) contains a list of basic security controls every organisation should have in place, and not that the PCI DSS in any way resembles real-world security.

Because it doesn’t, and you only have to look at the number of breaches involving ‘PCI compliant’ merchants and service providers to see that PCI, by itself, does little to prepare organisations against the challenges they face.

PCI compliance is a commercial obligation, nothing more, and any fines levied are only paid because the merchant or service provider who was breached wants to keep taking plastic. The Payments Services Directive 2 (PSD2) and the General Data Protection Regulation (GDPR) will be LAW in the 28 countries of the EU, and attract both legal and financial repercussions that could potentially cripple even the largest of businesses. No standard based on a bare minimum set of controls will ever protect personal data in a meaningful way.

Nor will any ISO standard, or COBIT, or any other information security framework for that matter. At least the PCI DSS puts its money where its mouth is and tells you what controls to implement, all security frameworks do is tell you something is a good idea, never how to do it a manner appropriate to your business.

Because they can’t, only the individual organisation can ever provide definition, and business justification, around the horribly inexact – but regulation standard – phrases; ‘appropriate’ and/or ‘reasonable security’.

The implementation of a security program that can meet the intent of ANY regulation includes very specific processes that the PCI DSS does not cover, and if they do, it’s in a very limited fashion with no-where near the emphasis required to express the importance. For example;

  1. The Risk Assessment (RA) is way down in section 12, when it should have been the very first thing performed before PCI compliance was even contemplated. An RA performed in-line with the PCI DSS would not be sufficient.
  2. The only nod to Disaster Recovery and Business Continuity Planning is a single bullet in 12.10.1, when these processes are absolutely central to any organisation staying in business responsibly.
  3. The requirements related to 3rd party due diligence are entirely inadequate relative to the risk involved.

…and so on. I have addressed the inadequacy of the actual PCI controls many times, so I won’t bother repeating them here. Suffice to say, the majority of the controls would be no-where near enough.

There are only 3 main ways to appropriately address the current and new tranche of regulations / directives:

  1. Make the CEO legally responsible for security breaches, and apply criminal penalties in-line with the egregiousness of the negligence – Clearly fines don’t worry CEOs enough, perhaps some jail time would.
  2. Ensure the policies, procedures, and standards are world-class – There is no security program without the application of accurate corporate knowledge
  3. Training & Education – This should be self-explanatory

Compliance with any of the upcoming regulations is no different from any regulation already in place. There is nothing outside of an appropriate security program that will ever be required, so just do the things you should have been doing from the very beginning.

Security is not easy, but it IS simple.

If you really want to piss off the PCI Security Standards Council (PCI SSC), show them how you are writing your Reports on Compliance (RoCs) automatically. You’ll find yourself in remediation very quickly.

But why? What possible difference could it make that you say things the same way from report to report as long as the validation of the controls was performed correctly?

For example, let’s take Requirement 2.2.b; “Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.”

In order to validate that this in place you must perform the following three processes;

  1. Identify the policy documentation verified to define that system configuration standards are updated as new vulnerability issues are identified;
  2. Identify the personnel interviewed for this testing procedure, and;
  3. For the interview, summarize the relevant details discussed that verify that the process is implemented.

So, for 1.,  if you have mapped all relevant documentation to the PCI requirements (which you should) in your RoC Writing Tool (RWT), this will simply be an automated regurgitation of the document names, and hopefully section numbers. If not, you have the relevant documents already summarised in Section 4.10.

For 2., you should already have your personnel mapped against system grouping in your asset register, so again, this is just a regurgitation. If not, you have the relevant group(s) already summarised in Section 4.11.

For 3., this is where the SSC is looking for a true narrative, but all validation relevant to 2.2.b is performed in the same way for each system type, so as long as the QSA and their client are actually doing their jobs properly, the contents of this narrative will be basically the same;

For [asset group]:

“QSA interviewed [personnel], examined [documents], and obtained [validation evidence] for [client] [name of vulnerability management process] and [name of configuration standard process], as well as examined production configurations for [sample(s)].“

…and so on for each distinct and relevant asset grouping.

A huge advantage of this is that for any asset type you add, the list of related DSS Requirements, and the related validation evidence all become pre-defined and mandatory action items, assigned to an individual. Assuming you have also defined a compliance goal, you will also have due dates. Even further, with a correctly defined hierarchy you also have the beginning of true project management.

Imagine that, with asset management done well, you have an up-front list of EVERYTHING required to achieve compliance, along will full accountability for the collection of the necessary validation evidence. As the target organisation collects and uploads the evidence, the RoC is writing itself in the background, thereby giving full insight into the gaps and level of effort indicators required to either adjust resources, or justify technology or outsourcing investments.

Now imagine how simple APIs could accept information from end-point technologies like A/V for FIM, or from centralised management stations for logging or IDS, or how a simple agent could report against running services / listening ports / registry settings for an operating system, and you are starting to perform the validation itself automatically. Not against PCI requirements, but against your full gamut of corporate policies and standards, all of which are mapped against you asset type. And not annually, but all day, every day.

Forget PCI compliance, this is the type of Continuous Compliance Validation everyone needs, regardless of the data type, compliance regime, or industry sector.

Difficult? Yes. Simple? Always.

First a caveat; this blog is not aimed at all acquirers, nor is it aimed at every individual at any one acquirer, there are some very professional, knowledgable, and pragmatic acquiring banks out there who are providing excellent advice and guidance to their merchant base.

Then there are the others who not only seem to have no idea what they are talking about, but are actually making things actively worse in terms of both resource effort and overall expenditure for their merchants. This is suppose to be a program of APPROPRIATE security, not just compliance.

The latest, utterly inexcusable example of this is a Level 3 merchant I know who, wanting to do things properly, hired a QSA company to come in and help them prepare for the completion of their SELF Assessment Questionnaire (SAQ).

The first thing the QSA had to do was get the merchant to ask the acquirer which SAQ they wanted, as the acquirer had left that to the merchant. For those who don’t know, it’s the acquiring bank’s responsibility to determine the correct SAQ based on the merchant’s business processes and card transaction volume. The acquirer should NEVER point at a QSA for this decision, and should most certainly not be leaving it up to the merchant.

After spending a significant amount of time and money, this particular merchant completed 2 compensating controls, which were then required to be signed off by a QSA!! Are you kidding me!? It’s a SELF assessment!! You show me a QSA who will sign off on a compensating control without the context of a FULL Level 1 assessment or a million caveats and I’ll show an idiot.

Now try to imagine this merchant’s frustration  when he knows another similar merchant had just filled out an SAQ by themselves, got an ASV scan, and received no questions from the same acquirer? The original merchant tried to do it properly, tried to ensure they could answer every question properly, and were even honest about the things they could not do. Their reward for this was additional expense getting another QSA to come in and help them translate the PCI rules back to the acquirer.

Here I am now 4 short weeks later and I have another merchant being told that the acquirer would “accept a SAQ D” for their reporting requirement. Bear in mind that this client is an e-commerce merchant who has implemented a full redirect to a PCI compliant service provider and you can again imagine the frustration. Add to this that the merchant, who will be reporting full compliance within a month, was also “encouraged” to complete a Prioritized Approach Tool spreadsheet as well, and the whole thing becomes a farce.

I have a lot of sympathy for acquirers, their PCI  headaches are multiplied by as many merchants and service providers they acquire for, but this is no excuse to provide anything but the most pragmatic guidance as they can. PCI cannot be driven from behind a desk, and practical guidance can only come from those who have been in front of a client as a QSA. I can read a book on emergency appendectomies for example, but I would suggest you go to a real doctor.

Merchants: If you do want to do PCI properly, hire a good QSA or industry expert for ONE day to set the game-plan with your acquirer and your internal teams, then get on with it.

Acquirers; Hire ex-QSAs with good reputations to run your merchant-facing PCI Programs, you’ll save yourselves and your clients a Hell of a lot of pain.

If you have ever been on the receiving end of a PCI assessment, you had one of two reactions to this blog’s title. You said;

  1. “Yes it is, that’s what I hired you for!”, or;
  2. “Damned right it’s not yours, the QSA is only here to validate it.”

95% of you are likely in the first group, unless you had someone like me as your assessor. It is not the QSA’s report, it is yours! The QSA is only there to:

  1. confirm that you have completed your parts of the Report on Compliance’s (RoC) Executive Summary (Sections 1 – 5) correctly;
  2. edit the QSA relevant sections;
  3. document the validation results in Section 6 – Findings & Observations; and
  4. validate the evidence you provide, and for which you are entirely responsible.

A QSA will likely never know your environment as well as you. So if you don’t take FULL responsibility for the contents of your RoC it will be your organisation that it liable for any mistakes, not the QSA. You will also then have absolutely no remedy if you are breached, as your forensic investigation will expose significant differences between the RoC and reality. This is also why you should never, EVER, hide anything from your QSA.

PCI is too often seen as an audit (it’s an assessment), and the QSA an auditor (s/he’s an assessor) and volunteering information is considered a no-no. I have actually had a client say; “But you didn’t ask me about that!”. I always try to explain that I’m a consultant first and there to help. I can’t help if I don’t have all the information. But if I do find out that they’re hiding something from me, any sampling privileges are now out the window.

That’s one of the differences between clients who use their PCI budgets to spend on securing the business, and those who only care about tick-in-the-box compliance. The first type will spend far less in the long run, even if the process does take longer. Not only that, they will likely not only STAY compliant, they will have actually protected their business …their ENTIRE business.

Setting PCI compliance as the end goal is like telling your kids to aim for a C average in school. Even the Card Brands and the SSC themselves have only ever said the DSS is a “minimum set of security controls”. So why would a QSA, whom you have hopefully chosen well (see Selecting the Right QSA for Your Business), take any ownership in a process where the goal is almost never fit for purpose?

Anyone who thinks that the PCI assessment process is structured, formal, and conducted using well established parameters has never been through one. Every good QSA does their own internal Risk Assessment from day 1, and based on their gut instinct, will determine whether or not validation sampling is even an option. If I don’t trust you, you stay at 100%.

Want to get some benefit from a PCI assessment?:

  1. Choose the right QSA;
  2. Tell them EVERYTHING; and
  3. Take FULL ownership of both the process and the output.

It’s your RoC, accept it.

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