Category: PCI

Seeing as the US Federal Trade Commission (FTC) orders came out last week, I am a little late to express an opinion. But I’m sitting here in my hotel in Short Hills, NJ waiting for my Chinese food to arrive and I’m at a loss for subject matter.

For those who don’t know, the FTC ordered 9 QSA companies to “provide the agency with information on how they conduct assessments of companies to measure their compliance with the Payment Card Industry Data Security Standards (PCI DSS).”

Press Release here; FTC To Study Credit Card Industry Data Security Auditing

Having just ploughed through their 7 page ‘Order to File a Special Report‘, it’s clear that the FTC did not consult with an experienced QSA prior to drafted their questions. If they had, they would not ask questions like;

“3. the  typical  length of time  to complete Compliance Assessments;”, or;

“4. the  Company’s pricing structure for Compliance Assessments and typical cost to clients of Compliance Assessments;”

Seriously? Why not just ask them to describe the average company, or how long is a piece of string!

They do ask some very sensible questions mind you;

“5. the method by which the scope of Compliance Assessments is determined“, and;

“6. the process by which the Company determines whether to use sampling as part of a Compliance Assessment, including, but not limited to, a description of the methodology used to determine that any sample is sufficiently large to assure that controls are implemented as expected.“

…but overall, the questions show a naiveté of several things about which I, and many others, have written ad nauseam (French and Latin in one sentence, aren’t I impressive!?). For example; asking about a policy that may prevent an organisation from providing additional services that are considered conflicting, goes against the SSC’s own written standard.

That said, you can read a number of things into the questions they DO ask that will likely have ‘The Sacrificial 9’ QSA companies messing their shorts if they don’t have a robust methodology in place.

Very few do.

My thoughts on their questions are as follows:

  1. For them to ask a question about sampling would suggest they have concerns that it is being seen by QSAs as a right and not the privilege it is;
    o
  2. Questions on conflict of interest suggest that they think the current system of ‘disclosure only’ is horribly flawed. Which it is;
    o
  3. The numerous references to methodology and policies indicates that the absence of a requirement for them is an egregious omission. Which it is;
    o
  4. The question related to training outside of the SSC’s QSA training suggests that it is required due to the poor state of QSA quality (there are some exceptional QSAs out there, but this is the minority). Which is true;
    o
  5. The recurring reference to document evidence to be provided with each requirement suggests that they are aware that validation is not performed well. Which it isn’t.

…and so on and so on.

I suspect that by the time the FTC come out with their report and implement their own requirements around privacy the world will have moved on from plastic to mobile, but this should be a wake-up call for EVERY QSA company to start doing their jobs properly. Not because I care about cardholder data, I don’t, but whatever the FTC are up will clearly involve privacy of all personal data. This I do care about.

Whether the FTC are testing the efficacy of a prescriptive, controls based, assessment methodology for their own ends I cannot say, but there’s no way this is just about payment cards.

The other QSA companies are hereby warned; you may have dodged the bullet for now, but your consulting practices will die with PCI if you aren’t careful.

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

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!]

Not feeling very creative today, but luckily the Payment Card Industry can always be relied upon to dish out plenty of blodder.

With a stunning twist, the SCC announced the potential release of the DSS v3.2 as early as March. It was greeted by the industry with a resounding; “Meh”. And quite rightly, have you read the potential changes? They are;

“…evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.”

While I understand this is part of their new program to; “…[move] towards a system of smaller, more incremental modifications to address things like the EMV roll-out in the US, rather than larger, wholesale updates.“, when was the last time you saw a large update? You could point to the change from v2.0 to v3.0, but you would only be showing your ignorance of the ‘ROC Reporting Instructions for PCI DSS v2.0’, the incorporation of which accounted for 95% of the difference between the 2 versions (take a look at this if you don’t believe me; PCI DSS v3.0 – Mapping to v2.0_v07NOV13).

But let’s handle each of these ‘changes’ in turn:

  1. Evaluating additional multi-factor – Note the use of the word ‘evaluating’, meaning nothing will actually change for some time. Is multi-factor auth a good idea for all privileged access? Yes, so let’s hope they actually enforce this one properly.
    o
  2. Incorporating some of the Designated Entities Supplemental Validation (DESV) – For ALL service providers, or just the ones to whom the DESV already applies? If the former, great, but the DESV is mostly a paperwork and process requirement, not additional controls. Not necessarily a terrible thing, but it depends on which requirements.
    o
  3.  Clarifying masking criteria – This one stumps me, how do you clarify the exposure of ‘first 6 and last 4’ only?
    o
  4. Migration for SSL and early TLS –  For to new date of 2018 to make ANY sense they should have left the requirement for offering TLS 1.2 by 2016, but allowing backwards compatibility until the later date. The way it’s written, merchants don’t even have to offer v1.2 of TLS until 2018 which is absolute nonsense.

The PCI DSS has always been, and will always be entirely inadequate to protect critical data assets, but frankly, what choice do the card brands have? They are fully aware of the inadequacy of their plastic in the face of current payment innovations, and the only saving grace delaying their rapid decline is the ignorance of the end consumer themselves. Henry Ford is often attributed the best phrase that sums this up perfectly; “If I had asked people what they wanted, they would have said faster horses.” The average consumer simply has no idea what could replace plastic, but when they do, the changes will be incredibly fast, and permanent.

The PCI DSS can never change dramatically, or the multi-billions spent on compliance to date would all be thrown away. Every organisation on the planet who is currently compliant (or reporting as such to be more accurate) would have to spend countless more billions to bring themselves up to the new standard. There is no way the card brands would survive the backlash. They have painted themselves into a compliance corner that cannot protect their 50 year old technology from the current threat landscape.

Yes of course implementing the PCI DSS controls on all forms of data is better than doing nothing, but barely, and can never and will never represent real security.

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.