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

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, You Have Chosen Poorly

PCI DSS, You Brought It On Yourselves


I have never hidden my disdain for the PCI DSS, and have written numerous blogs as to why. Not just whinging mind you, I have always included a stab at providing solutions or alternatives. But every now and again, I have to remind myself why the DSS even exists in the first place. And who needs to accept a sizeable chunk of the responsibility for it.

It’s you Mr. Retail, and you Mr. E-Commerce, and especially you Mr. Service Provider. You are every bit as culpable as the Card Brands.

Yes, the payment card technology is 50+ years old, and hopelessly outdated. Yes it’s a ridiculous way of paying now that there are so many better ways. And yes, it’s very difficult to protect cardholder data, but it’s really not complicated. All it took was effort.

But organisations didn’t make any effort. For decades on end. From stand-alone terminals, to integrated points of sale, to e-commerce, and now to mobile, the threat landscape has changed beyond measure. The corresponding risk management programs have done next to nothing.

Let’s take a quick look at the causes of 3 of the worst card data breaches to date:

  1. T.J. Maxx (2007 – 45.7M Primary Account Numbers (PANs) compromised) – I know this one’s going back a bit, but it’s one of those rare examples of where the PCI DSS was [mostly] up to speed with the prevailing threat landscape. The breach was caused by weak encryption on their wireless access points. Although Wired Equivalent Privacy (WEP) was:
    o
    i)   known to be vulnerable way back in 2001;
    ii)  replaced by WPA in 2003;
    iii) deprecated by the IEEE in 2004, and;
    iv) addressed specifically in the DSS from as early as v1.0 – “4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA) technology if WPA capable, or VPN or SSL at 128-bit. Never rely exclusively on WEP to protect confidentiality and access to a wireless LAN.
    o
    …T.J.Maxx still had WEP as its standard. This vulnerability (plus horrifically poor network segmentation) lead to the compromise. It also took T.J.Maxx 18 MONTHS to find out.
    o
  2. Target (2013 – 40M PANs compromised) – Network access credentials stolen from a 3rd party and used to remotely log in to systems in-scope for PCI. An HVAC provider at that! Where to even begin on where Target went wrong?! But we can assume:
    o
    i)   vendor due diligence and management was sub-standard (addressed in Requirements 12.8.x);
    ii)  vendor access standards and monitoring were not in place (addressed in Requirements 8.1.5.a, 8.1.5.b, and 8.3.2.a);
    iii) change detection mechanisms were either not in place, or ineffective (addressed in Requirements 6.4.x);
    iv)  logging and monitoring mechanisms were either not in place, or ineffective (addressed in Requirements 10.x), and;
    v)   network segmentation was inadequate.
    o
  3. Home Depot (2014 – 56M PANs compromised) – Similar to Target, which makes this one even more embarrassing and unforgivable.

If we were to look at the thousands of other breaches that have occurred we would find little difference. It’s not so much concerted attacks from dedicated and skilled hackers that’s the problem, it’s the complete disregard for basic security practices by the vast majority of organisations. Organisations who KNOW better, but have chosen instead to just roll the dice.

I’m not saying that these three examples were not perpetrated by skilled hackers, but the level of skill required was significantly less than it should have been. In fact, if these organisations only had DSS levels of security controls in place, the attacks would have significantly more difficult. REAL security would have made these targets of last resort.

What Are You Going to Do About It?

As the South Africans say; If you want security, build your fence higher than your neighbour’s.” The reason the PCI DSS exists is because no one was building any fences!

The right things to do for security have, quite literally, been written down for generations. Ignore these basics and the upcoming regulations related to privacy will make PCI look like a walk in the park by comparison.

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

The Evolution of the PCI DSS, From v1.1 to v3.2


In honour of the SSC’s 10th year in power [oops!] business, I thought it would be interesting to run a little retrospective.

On December 15th, 2004, a day that will live in infamy, Visa released the Payment Card Industry Data Security Standard (PCI DSS) v1.0.

~2 years later, the PCI Security Standards Council (SSC) was formed, closely followed by the release of DSS v1.1.

Six iterations later, here we are at v3.2.

To emphasise yet again just how sad I am, I chose to map v1.1 against not just the v3.2 standard itself, but its corresponding Report on Compliance (RoC) Reporting Template . While this seems like an extreme comparison (download it here), I wanted to get the full flavour of just how PCI compliance assessments have evolved in the 10 years since v1.1’s debut.

At first blush, they would appear to be radically different. For a start, v1.1 was just 17 pages long, v3.2 is 139 pages, and the RoC Reporting Template is a whopping 198 pages! But what becomes clear very quickly is that most of the changes are related to assessment guidance, validation guidance, and wave after wave of clarifications.

I mean, seriously, excluding the Bill of Rights the US Constitution has only been amended 17 times in 227 years!

Take Requirement 1.1.1 for example, this is what v3.2 looks like in the v3.2 RoC Reporting Template:

Screen Shot 2016-08-10 at 10.46.04

This is from v1.1:

Screen Shot 2016-08-10 at 10.39.46

Radically different, right?

Not really, everything in 1.1.1.a – 1.1.1.c is validation guidance, nothing more. In other words, if the original v1.1 assessors were doing a good job, this is how they would have assessed their clients back in 2006.

But they weren’t doing a good job. Not even close. Even into v1.2 QSAs were still filling out ‘Yes’ for in-place and ‘No’ for not-in place.

What we have seen from v1.2 onwards is the gradual increase in detail related to the validation that has to be performed. From v2.0, a separate document was provided to QSAs, the ‘ROC Reporting Instructions for PCI DSS v2.0‘ that broke down what was expected during compliance validation.

This was also implemented poorly by a lot of QSA companies, while others were clearly unaware of its very existence.

Roll on DSS v3.0, the version that caused by far the biggest stir in the PCI community since the DSS’s initial release. There were shouts from the merchants that the SSC had just raised the bar to unacceptable heights. There were even complaints from QSAs that the ‘new’ instructions would increase the workload to the point assessments would be unprofitable. And worst of all, the more unscrupulous QSA companies actually raised their prices! Here are my thoughts on those companies; PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

The fact is that v3.0 was a consolidation of the DSS Requirements and the Reporting Instructions, and little more (detailed mapping here). If the QSAs and the organisations they were assessing had been performing assessments properly, the effects would have been minimal.

How Similar is v1.1 to v3.2?

About 82% according to my calculation. Obviously this is at the overarching control level, not the validation detail. v1.1 had exactly zero guidance in that regard.

Other than some wording and requirement numbering changes the controls have remained remarkably consistent.

…and the ‘major’ changes aren’t really that major. Certainly nothing outside of basic common sense:

  1. Req. 1.1.3 – Cardholder Data Flow Diagrams – [How would you determine scope in the first place?]
  2. Req. 2.4 – Asset Inventory – [Seriously, how could you possibly achieve PCI compliance without one?]
  3. Req. 5.x – Make sure anti-virus are actively running etc. – [Really!?]
  4. Req. 7.x – Additional requirements around job classification etc. – [RBAC is RBAC, this should never have needed changing.]
  5. Req. 8.6 – ‘Other’ Authentication Mechanisms – [About time non-password stuff was introduced.]
  6. Req. 9.3 – Physical access based on job function – [As opposed to?]
  7. Req. 9.9 – Protection of Terminals (only affects retail) – [Sigh…]
  8. …etc…

So What Are You Saying?

There are two ways to look at these results:

  1. The main controls of the DSS were correct from the very beginning and there has been no change in either the threat landscape, or security technology; and
    o
  2.  The card schemes do not WANT to make significant changes, because they already consider the controls to be risk reduction enough. Not to mention the poo-storm that would descend on them if they did.

I think we all know that the first option isn’t true, so that leaves the second. And can you really blame them? Besides, what does it really matter, the DSS will never have the opportunity to improve much beyond minor clarifications. Payment cards just don’t have enough life-span to warrant anything else.

Nothing more to add really, now I need to go get a life.

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