What's in the Draft PCI DSS v4.0?

In late 2020, the PCI DSS v4.0 will be released. And in what promises to be an even more significant change than that from 2.0 to 3.0 (released in Nov. ’13), there is, rather unsurprisingly, a great deal of interest in its contents.

So what’s in it?

I’ll be honest, I can’t tell you, or more to the point, I’m not ALLOWED to tell you as the draft version is currently in ‘Request for Comment’ (RFC) status. Yes I have read it, not only that, I have mapped it line-by-line to v3.2.1 and analysed the differences in detail. I have even written a brief on what I consider the impact of those changes will be, but it will have to remain unread until the moratorium is lifted.

Continue reading

[SELF-PROMOTION] New Core Concept Security Website

After 6 years of faffing around, my Core Concept Security website is finally up and running! Click (https://coreconceptsecurity.com).

Core Concept Security

It’s very basic, so I should be grateful for your comments / suggestions on improvement.

Many thanks,

David

British Airways

BA Faces £500M Fine: Shut Up and Get Your FACTS Straight!

Just about every major news outlet in the UK has the same headline for the BA data breach: “BA faces record £500M fine for data breach!“. Some are not content with even this degree of utter nonsense and are actually making things worse by saying that affected passengers are now “threatening boycott“.

Continue reading
PIN on Mobile

PCI: Software-Based PIN Entry on COTS (a.k.a. PIN-on-Mobile)


Almost four YEARS ago I wrote Software PIN, the Rosetta Stone of Future Payments, then just over a year later I wrote; Mobile Authentication: Exceeding Card Present Security?

Just this month the SSC finally came out with their Software-Based PIN Entry on COTS Security Requirements v1.0.

[Ed. While I don’t have to wonder why PIN was my primary focus, I can see how pointless it was …almost. It just makes the delay on this standard that much more inexcusable.]

On with the story… Software PIN is more commonly referred to as PIN-on-Mobile (or the catchier PIN-on-Glass), and is the ‘game-changing’ technology that will; “enable merchants to accept PIN-based payments with the PIN entered on a commercial off-the-shelf device, such as a consumer-grade mobile phone or tablet.”

What has taken them so long to make what – from my jaded perspective – is the only move that will delay their inevitable demise? It’s not like there was some miraculous innovation in mobile or encryption technology in the last couple of years! Every requirement in the standard was available/achievable long before I even wrote my blogs. As were viable solutions for that matter.

I suspect there’s lots of reasons of why they were so slow, but chief amongst these has to be their complete inability to adapt to the fast-paced innovation rampant in the FinTech industry. Especially given their hopelessly antiquated technology. It’s only their global adoption and sheer ubiquity that keeps them where they are. I blame the banks too, change for them means acceptance of liability.

Come to think of it, what an amazing coincidence that PSD2 – the biggest nail in the payment card’s coffin since …well ever, came out this month as well. Weird huh?

As far as I am concerned, PIN-on-Mobile was the card brand’s last hold-out, now they’re done. Hopefully between the XYZ-Pays (ApplePay, SamsungPay etc.) and now the entry of cardholder PIN on [almost] any CoTS device, big merchants / retail associations will finally have the balls to stand up for themselves.

How many millions have they spent in the US on EMV terminals just to find out a few years later that it was not only entirely unnecessary, but they’re now tied into an investment that will leave them lagging behind their competition who were slower of the EMV block?

I know that’s harsh, and we really have no right to judge. Have any of the following questions ever occurred to you?:

  1. If I can use my phone to pay for something, why do I have to tie that payment to a branded card?;
  2. With all of the security requirements required for the entry of a software PIN, why the Hell do I still have to use one? In other words, if it’s that bloody difficult to secure it, why not use something else?; and
  3. Isn’t there a better way!?

If you’re like the majority of the population, these questions are more like:

  1. Why doesn’t MY bank support this?! (looking at YOU Barclay Business!), or more commonly; why would I use this service when I have a piece of plastic?;
  2. What’s wrong with PIN?; and
  3. [nothing]

The fact is that the lion’s share of the cashless transactions globally are performed by those who have never known a time before payment cards. We simply can’t imagine anything else and we don’t even notice their inconvenience. We also don’t see the costs imposed by the middlemen.

But let me ask you this; Would you ever go back to using a feature phone? I’ll [almost] guarantee that you had no idea what features you wanted in a phone until you used a smartphone for the first time. And now you can’t live without it. Hell, most of us can’t even put the damned things down!

The same thing WILL happen to payments, but not until consumer indifference is overcome by something shiny and new.

Frankly this blog is boring even to me, and I really have nothing more to say about payment innovation that I have not already said a hundred times. But I simply can’t let anything so patently meaningless as PIN on Mobile to go unanswered.

Innovation my arse.

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

PCI to GDPR

Going From PCI to GDPR? You Are Starting from Square One


To be very clear from the outset, if you think the PCI DSS is a good ‘stepping stone’ to GDPR, you need to do a lot more homework. Data security represents less than 5% of the entire GDPR, and the PCI DSS is – in my admittedly biased estimation – no more than 33% of a true security program.

I have, for years, railed against the PCI DSS as an inadequate baseline for security, and even the card brands and the SSC have never claimed it be more than what it is; a set of MINIMUM security controls related to the protection of cardholder data. Well, except for this ill-advised and rather naive quote perhaps;

People come to me and say, ‘How do I achieve GDPR compliance?’… Start with PCI DSS.

The PCI DSS was written for ONE very specific purpose, and it’s only ego, desperation, or vested interest that would lead people to think it’s anything more.

The reason for this particular blog is reading articles like the two samples below. It’s articles like these that lead organisations who don’t know better [yet] into making bad decisions. They also give cybersecurity professionals a bad name. Well, worse name, unscrupulous QSA companies and greedy product vendors have already caused significant damage.

Article 1, and by far the most egregiously overstated quote [so far] is from an article in SecurityWeek (PCI 3.2 Compliant Organizations Are Likely GDPR Compliant); “Any company that fully and successfully implements PCI DSS 3.2 is likely to be fully GDPR compliant — it’s a case of buy one and get one free.” Given the author’s apparent credentials, he should know better. Since when does the PCI DSS deal with explicit consent, or children’s data, or the right to erasure/correction/objection/portability and so on.

Then, in the very recent article 2; How the PCI DSS can help you meet the requirements of the GDPR – the author states that; “Failure to report breaches attracts fines of up to €10 million or 2% of annual turnover, whichever is higher. Breaches or failure to uphold the sixth data protection principle (maintaining confidentiality and integrity of personal data) can attract fines of up to €20 million or 4% of annual turnover (whichever is higher).

No part of the above statement is factually correct:

  1. Just because Article 33 – Notification of a personal data breach to the supervisory authority is included in Article 83(4)(a) – General conditions for imposing administrative fines, it does NOT mean that failure to respond in 72 hours will attract a fine. There are many caveats; e.g. Recital 85 states ; “the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it (Recital 85)”‘
  2. sixth data protection principle“? – Nothing to do with confidentiality and integrity, assume author meant the seventh principle (security).
  3. Maximum fines for data breaches are 2% (for an undertaking, a.k.a. a group of companies), not 4%.

The author then goes on to say; “The ICO is also likely to treat inadequate or non-implementation of the PCI DSS as a failure to implement appropriate “technical and organisational measures” to protect personal data…” which is clearly not the case. The ICO has always left loss of cardholder data / PCI up to the card schemes, and have already mentioned ISO 27001 in their “The Guide to Data Protection“.

Every article I have read on how PCI helps with GDPR, is at best, hugely overstated, and at worst, full of self-serving lies. I can fully appreciate the desire for cybersecurity companies (especially QSAs) to branch out from the massively price compressed and ultimately doomed PCI space, but to do so in this manner is unconscionable.

Unfortunately if you are falling for this advice, I can safely assume that you:

  1. have little idea of how limited the PCI DSS is, even as protection for the only form of data to which it’s relevant;
  2. have little idea what the GDPR is trying to achieve if you think a bunch of security controls are that significant a component; and
  3. don’t actually know what an ‘appropriate’ security program should look like.

This is actually not meant as a criticism, these things may not be your job, but if you have any responsibility for GDPR, you absolutely must learn to ask the right questions.  I will finish with some reasoning below, but leave it up to you to work out whose guidance to take.

PCI and GDPR are very far removed from each other.

  1. Data protection Articles are only 3.34% of the Regulation – yes, I actually worked this out on a spreadsheet. That means the GDPR is 96.66% NOT security control relevant. Of course IT and IT security are important and intrinsic to GDPR, but PCI does not cover anything else other than those things.;
    o
  2. PCI DSS makes no mention of the need for Governance – PCI compliance is almost invariably an IT project, and while this is obviously wrong, does not prevent organisations from achieving compliance. In GDPR, the IT folks have absolutely no idea where to start. Nor should they, IT/IS people aren’t lawyers and they do not control the organisation’s direction, they are business enablers who do as bid by senior management. GDPR requires a team effort from every department, which is exactly what Governance is.;
    o
  3. PCI DSS is about compliance to an already defined standard of security controls, the GDPR requires a demonstration of ‘appropriate security’ measures – For example, what if your annual risk assessment showed that the PCI controls were actually excessive? Could you scale some of them back? No, you can’t. Alternatively, what if your risk assessment showed that they weren’t enough, could your QSA insist that you went above and beyond? Again, no, so what the hell is the point of the risk assessment in PCI?
    o
  4. Only QSAs that started out as security consultants [not the other way around] have the skill-set to provide any help at all. If they were experts in ISO 27001, CoBIT, NIST etc., then yes, they can help you both define and implement ‘appropriate security’. If all they did was pass the QSA exam, the only guarantee you have is that they can read.
    o
  5. The PCI DSS can never keep pace with the threat landscape – It’s already way behind, and with its complete inability to change significantly, the DSS can never represent appropriate security. If the DSS did change significantly, both the card brands and the SSC would be lynched. Millions of organisations have spent BILLIONS on PCI, they will simply refuse to start all over again. GDPR on the other hand has no defined controls, it’s up to YOU to show that your controls meet the measured risk.

In the end, the only way PCI can help with GDPR is to use the assigned budget to do security properly. You will never reach GDPR ‘compliance‘ using PCI, but you will achieve both PCI and GDPR compliance on the way to real security.

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