Category: PCI

If the answer is yes, you have clearly not learned any lessons from years of regulatory compliance, breach headlines, every security best practice, or basic common sense. And if you continue to do nothing, for whatever the reason, you likely deserve the bad things that happen to you.

Yes that’s harsh, but non-compliance is all so unnecessary. Just like PCI, nothing the PSD2 mandates is something you should not have been doing a long time ago, and if 2 YEARS is not enough time to fix what’s broken in your organisation, please let me know so I can stop doing business with you.

If you’re a financial institution, did it not occur to you to stay up to speed with the latest and greatest advances in access control? Data classification and meta tagging? Did not the FIRST version of the PSD have enough hints that the ever-worsening threat landscape was only going to increase the security and privacy burdens?

Worse than this are the two major offenders; 1) Payment Service Providers (PSPs) who thought that they were somehow immune to regulation because “it’s not OUR data”, and 2) the FI’s who used them because they thought they could outsource the responsibility.

Yes, security come at a cost, and very little of that expense will ADD to your bottom line, but if it’s an ROI you’re looking for, how about staying is business? Between PSD2 sanctions and potentially EU General Data Protection Regulation (GDPR) fines/sanctions, and maybe even PCI fines if it’s cardholder data you lose, I would say your responsibility is clear.

But it’s not all doom and gloom, the path towards compliance is actually very simple. Not easy, simple.

First, get the CEO and/or Board of Directors involved. if they don’t care, no-one else will, and any project to achieve ANY form of compliance will either fail out of the gate, take twice as long, or cost twice as much. As I’ve said too many times now;

“Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter any goal here], its the CEOs fault, and no-one else’s.”

Second, run a risk assessment to determine 3 things; 1) what business assets and processes are affected, 2) what are the gaps between current and required capabilities and 3) how much should you spend to fill those gaps.

In parallel with the risk assessment, fix your documentation!! The cheapest and most important facet of every security program is the one most ignored, thereby rendering everything else you do somewhere on the scale of sub-optimal all the way to completely ineffectual.

Third, do NOT do this just to achieve PSD2 ‘compliance’, do it for ALL aspects of your business, and do it once. Done properly, any progress toward any form of regulatory compliance becomes a standard operating procedure, and eventually the ages-old cliché; business as usual. Anything other than this was wasted effort irrespective of it’s intended goal.

You wouldn’t ask your doctor for a temporary fix would you, security is no different?

In the end, you really only have 2 choices; throw a patch on a gaping wound and hope that you have implemented enough smoke and mirrors to stay under the radar, or do things properly and avoid the worst of the fines regardless of how long it takes to get compliant. While that sounds somewhat counterintuitive, the regulators do not WANT to fine anyone, but if data is lost, it will be the bullshit artist who will be hurt the most.

Just about everyone who writes on information security has had ample blodder from the numerous high profile breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.1 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetically, if you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less than a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.

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

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.

Readers of my blog know I am opinionated, which I why I have so many non-readers I suspect. I find myself now with something of a mission, and that is to either train providers of PCI-related services to perform 12.9 correctly, or I will make available a responsibility mapping matrix of their Attestation of Compliance (AoC)-defined services. Merchants need to perform appropriate due diligence, without full disclosure and guidance from Service Providers (SPs), this is all but impossible for the majority of non-PCI experts.

I  am not saying the SPs are doing anything nefarious,[mostly] they are not, it’s just clear that neither they, nor it would appear their QSAs, have taken the time to produce a responsibility mapping that makes sense.

I will not be posting names, but if you contact me on david@coreconceptsecurity.com and ask about a specific provider, I will tell you whether I have the mapping or not (just started this, so it’s unlikely, but stay tuned…). I am also happy to accept AoCs for your provider if you want a mapping done. Finally, I am also happy to help SPs directly if they would like to get ahead of this.

For Merchants: Regardless of the SAQ you complete, you are responsible for EVERY requirement in the PCI DSS, so any mapping and contract you have in place must be at that requirements level, not that of the SAQ, so if all you get is an AoC, there’s a very good chance your residual responsibility is significantly higher that you would like, and perhaps been led to believe.

At a minimum, your mapping will have 3 columns:

  1. AoC Mapping – This is the only ‘official’ recognition of the requirement numbers included that you have to go by, anything else the SP may say is irrelevant. If it’s not on the AoC, you cannot point your RoC/SAQ to it, and the requirements must still be assessed on your behalf. Note: Be VERY careful re: sub-requirements, if they are not SPECIFICALLY addressed, they are not included (Listing Req. 1.1.5 on the AoC does not necessarily mean Reqs. 1.1.5.a AND 1.1.5.b for example).
    o
  2. Services YOU Require – This is where you specify EVERY requirement you’re looking to outsource, but you need to be reasonable. There are surprisingly few requirements you can fully outsource (depending on the service), and you must detail what partial responsibility must remain with you. For example; you can outsource the changes to your rule-set, but you will usually retain ownership of it (which is the majority of Reqs. 1.X).
    o
  3. Residual Responsibility – This is what’s left for you to cover, and will represent an agreement between you, your service provider, and your QSA (if applicable). Anything NOT handled by your SP, is yours.

The above is not to say that an SP cannot provide significant support outside of their officially assessed services, but whatever they are doing needs to be noted, and included in your report.

For example; regardless of the services provided, EVERY policy requirement is owned by you, and followed by your SP. They may have their own policies, and even have them listed on their AoC, but those policies do not cover you as a merchant from a RoC/SAQ perspective.

Once complete and agreed by both sides, this mapping should form the basis of your contract. It does not matter if it’s an annex, addendum or in the main contract body, but the actual PCI DSS v3.0 requirement numbers must be part of any binding agreement. Whether or not you put SLAs around the services, or require full compliance on an ongoing basis, is a business decision, tying your SP to the DSS requirements they cover on your behalf is a PCI obligation.

I have uploaded an example of a Service Provider Responsibility Mapping that I recently provided to a client – help yourself. Hopefully it makes sense, but you are free to contact me if you would like more guidance.

This is actually a very simple process, as is everything else in security, it’s only not knowing yourself what to do that makes it difficult. So ask for help.

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

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