Author: David Froud

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.

Answer: When it’s an ISO Standard.

But before you get outraged, I believe the problem lies not with ISO, it’s that we don’t really know what a standard actually IS!:

  • Ask one person and they’ll say a standard is something that all ‘like things’ must be. i.e. they all must be the SAME.
  • Ask someone else and they’ll say that a standard is something you must reach   i.e. it’s a minimum bar.
  • Ask yet another person and they’ll say that a standard is an average of all things.

Even the OED backs this up!:

  • Something used as a measure, norm, or model in comparative evaluations;
  • A level of quality or attainment;
  • Something used or accepted as normal or average; and
  • A military or ceremonial flag carried on a pole or hoisted on a rope

OK, forget the last one, but you get the point, which is that the English language itself allows for multiple, often conflicting, interpretations of the SAME word! e.g. does the word ‘minute’ mean 60 seconds, or something very small? Right, this cannot be answered without context, but how about in this sentence; “The mouse was so minute that it fit into the tiniest of gaps.”?

So clearly the implementation of an ISO standard in any organisation depends entirely on the context to which they have chosen to adopt it, or are being forced to abide by it. An organisation looking for a marketing or competitive edge will adopt ISO as a quality attainment for example, and another will choose to use it for comparative purposes in their due diligence processes. Each will focus more heavily on different aspects of the ISO framework, and both can still meet the intent.

For things like information security this is no big deal, which I assume is why ISO 27001 uses the word ‘appropriate’ EIGHTEEN times! “…appropriate security…”, “…appropriate documentation…”, “…appropriate levels…” and so on. An organisation SHOULD choose which aspects of the standard are appropriate, and then go as deep into the framework controls as they deem …well, appropriate.

But what happens when the ISO standard (which is interchangeable with ‘framework’ in my opinion) is something like ‘Financial Transaction Card Originated Messages — Interchange Message Specifications’ (ISO 8583), or ‘Universal Financial Industry Message Scheme’ (ISO 20022) where you would think that everyone should not only interpret, but implement them in EXACTLY the same way to ensure global interoperability. Surely these things are not like an API bridge where you do whatever you want in the back end, surely they are more like a big puzzle where every single piece must meet SPECIFIC criteria to build the big picture?

Sure the message syntax might be defined, but the USE of fields and what actually goes IN the fields is optional. Why do you think the Card Brands, Issuers and Acquirers are going to have such a hard time implementing EMV tokenisation for example?

The mobile phone has changed everything; the way we communicate, the way we shop, and it won’t be long before it changes the way we think. If we are to embrace the enormous potential yet to come, globally, we must agree on a better definition of ‘standard’, or we might as well not bother. Information out of context has been the cause of innumerable wars, terror crimes, religious and lifestyle persecutions, and the continuation of nationalist behaviour to the detriment of the species.

Maybe we should standardise the word ‘standard’ …oh, wait?

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

Way back in July 2013 I wrote the blog; “Why the US Will Not Adopt EMV (Chip & PIN)“, which, given the current state of EMV adoption in the US, was wayyyy off the mark.

My broken crystal ball aside, – hey, if I was any good at predictions I’d be blogging from my yacht anchored in the Med, not from my kitchen in Barnes – I still can’t figure out why the US would spend billions upon billions of dollars on EMV without demanding that those players with the greatest vested interest in ‘plastic’ build in a more permanent ROI.

Those player are:

  1. The Card Brands: This one is a given, any move away from plastic and towards mobile is one step closer to obsolescence (yes, I am ignoring EMV tokenisation, for many reasons).
    o
  2. Issuers: Also a given, what ELSE are they going to do?
    o
  3. Acquirers / PSPs: They have the best chance of segueing their current position into bringing their merchant-base future-proofed payment innovations and value-add services designed to improve the ‘consumer journey’.
    o
  4. Terminal/PED Manufacturers: Once the US has spent billions replacing their mag stripe PEDs with Chip / Contactless, what is left for PED makers to do? When the whole world finally works out that mobile phones and wearables only need something to read them (e.g another bloody phone), why buy crappy, massively expensive, devices that do next to nothing to improve the customer’s shopping experience?

These players have been around for so long that they are seen as the de facto standard, while all along they have been intermediaries designed only to make non-cash payments safe. To make them trusted. And they did a superb job, so superb in fact that it has taken technology almost SIXTY years to find something better! We went from the first production car to landing on the bloody MOON in the same time!

But it’s here now, and it’s been here since Apple created the iPhone. A device capable of so many modes of every factor of authentication, that we can really start calling it Identity Assurance, which is the foundation of only thing on which a payment is truly based; trust.

A credit card number, regardless of where it’s stored, how it’s stored, or even if it’s tokenised, will never be able to match what my phone can do.

For years now, the functionality of mobile devices has been perfectly placed to provide alternatives to plastic; e-wallets, direct debit, merchant-side tokens, even block chains, but here we are, in 2015, and we are still spending billions on the same technology our parents or even grandparents first used back in the 60’s.

Again, why?

Let me answer that with another question; How do YOU want to pay for things in a store? If whatever you wanted in payment technology could come true tomorrow, what would it look like?

The odds are that unless you’re in the payments innovation line of work, you really have no idea. You just want it to be painless, convenient, and if you’ve had issues in the past, safe. Payment cards are so much part of our lives that we cannot even imagine anything simpler. It’s only when you know what goes on in the background that the true cost of plastic comes to light.

From interchange fees, to PCI compliance, to fraud, to PEDs, to the plastic cards themselves, taking card payments is a massively expensive undertaking, and if you think those costs are not passed down to us, the consumers, then I have a bridge to sell you.

But you really can’t blame the consumer, we are not the ones who live and die at the whim of consumers in general …but retailers do. Would Walmart be as big if they only took cash? Of course not, they NEED non-cash payments, but what if the top TEN retailers in American had told the card brands that the first one to negate the need to EMV got ALL their business, can you imagine what would have happened?

Top 10 Retailer’s Revenue in 2013

Rank Retailer                   Rev. (USD Millions)
1 Wal-Mart $ 334,302.00
2 Kroger $ 93,598.00
3 Costco $ 74,740.00
4 Target $ 71,279.00
5 The Home Depot $ 69,951.00
6 Walgreen $ 68,068.00
7 CVS Caremark $ 65,618.00
8 Lowe’s $ 52,210.00
9 Amazon.com $ 43,962.00
10 Safeway $ 37,534.00
$ 911,262.00

That’s close to 1 TRILLION USD, the lion’s share of  which was accepted through plastic.

And what could Target have done with the $100M they spent on new PEDs, or the millions they are paying in fines and reparations for their 2013 breach? I point not to their ridiculous back-end processes as the cause of their woes, but their inability to focus on the true cause of their vulnerability; their inability to innovate collaboratively.

I guess, in retrospect, EMV in the US was inevitable, without consumer pressure for alternatives the retail industry just followed along like sheep, perhaps assuming payment cards were some kind of ‘official’ mandate. They are not, and the retail industry in the US missed an incredible opportunity for change. Now all they’ve done is set themselves up to not only pay for the ‘new’ infrastructure (at least up front), but to pay for the fraud as well.

While not entirely appropriate, it’s one of my favourite sayings, and applies to every level in payment food-chain, including the consumer.

“You are not entitled to your opinion. You are entitled to your informed opinion. No one is entitled to be ignorant.”

― Harlan Ellison

The concept of tokenisation has been around for centuries as a means to “reduce [the] risk in handling high value financial instruments by replacing them with surrogate equivalents.” The concept is simple, sound and proven, yet in today’s digital age, it raises questions that were previously not considered important, or even relevant. For example; If you need to tokenise something – an account number for example -, why do we expose those account numbers during a transaction in the first place?

The short answer is that we do NOT need to exposed account details, not with the dramatic advances in mobile phone authentication over the last 10 years. However, the reality is not that simple, in fact, the challenges faced by today’s organisations is enormous in both scale and complexity. From retail merchant, to acquirer, to issuer (especially the issuer!) cleaning up the detritus left by 50 years of card payments is a truly Herculean task.

But for 50+ years the global adoption of payment cards changed the course of payments forever, and did so in the right direction; away from cash. Despite the numerous benefits we have enjoyed from this non-cash pioneer, we now unfortunately see the cost of that success in the numerous and on-going data breaches involving millions of payments cards and BILLIONS of €/£/$ in fraud losses annually.

In the world of payments, even in 2015, the term tokenisation is synonymous with replacing a payment card (Visa, MasterCard, Amex, Chine Union Pay etc.) Primary Account Number (or PAN), with a token of less – or preferably no – value to an attacker. This is not a new concept, even for payment cards, as vendors have been providing tokenisation solutions for well over a decade, even longer in closed-loop payment environments.

So if solutions were available way back in 2005, why are there still countless billions of PANs floating around? The answer to this isn’t simple either, and it starts with the fact that there are at least three different types of tokenisation related to the surrogation of PANs:

  1. Acquiring / PSP / Merchant Tokens – “This token is created after the cardholder presents their payment credentials. ‘Acquiring Tokens’ may be used as part of the authorisation process, including card-on-file transactions.”

    Note: These tokens were the first to be introduced, and represent a ‘distributed’ model. Providers must only maintain Payment Card Industry Data Security Standard (PCI DSS) compliance and potentially Payment Application (PA) DSS compliance (depending on the implementation).

  2. Issuer Tokenisation – “Also known as virtual card numbers or alternate PANs, issuer tokens are created by issuers to reduce risk in specific use cases (e.g. commercial card applications, and consumer-oriented services).”

    Note: This solution can look almost identical to the Acquiring tokens.

  3. EMV Tokens – “Tokens compliant with the EMV Payment Tokenisation Specification – Technical Framework developed as a multi-scheme initiative by Visa, MasterCard and American Express and first published in March 2014. Ownership has now been transferred to EMVCo, who will take responsibility for further development of the framework going forward.”

    Note: These tokens were made available by the major card schemes beginning late 2014, and represent a ‘centralised’ model based on a specific standard; EMVCo’s ‘EMV Payment Tokenisation Specification’.

These solutions have their own benefits and drawbacks, depending on both your requirements and to whom you speak, but there’s one thing a tokenisation solution should NOT do, and that’s disrupt any legacy process. Loyalty programs, anti-fraud mechanisms, big data analytics and a host of others can all be tied to primary account numbers, and can all be broken if the token-to-PAN relationship is not maintained.

Perhaps the most obvious drawback of the EMV Tokens in particular is a direct result of one of its most significant security measures; a token can be assigned a ‘domain’, and only transactions in that same domain will be processed (an e-commerce token can only be used for e-commerce transactions for example). While this sounds logical, when you consider that an individual merchant can be a domain (Amazon for example), it’s obvious that just one card can have several or even dozens of assigned tokens. Every token costs the Issuers €0.20 for provisioning, then anywhere between €0.02 and €0.005 for ‘hosting and life-cycle management. An issuer who has just 5,000,000 tokens will be paying >€1M for up-front, then >€600K / annum to the Token Service Providers (currently just the card brands themselves).

It can be assumed that this cost will be off-set by the reduction in card fraud, but this further assumes an almost global adoption of the tokenisation service, and a seamless interface to the consumers. Consumers will simply not accept any additional complexity in the payment process.

So while the concept of tokenisation is a good one, it not only raises the question posed in the first paragraph; ”If you need to tokenise something why do we expose [those account numbers] during a transaction in the first place?”, the fact that tokenisation will be most prevalent in mobile transactions (like Apple Pay) raises a concept even more fundamental; why is there anyone in the middle?

A payment is a movement of value from one place to another, so it follow that there are only 4 stakeholders involved; the consumer and their bank, and the merchant and their bank, right? However, for a branded payment card transaction, you can add an Issuer (of the plastic), an acquirer (not necessarily your bank), potentially a Payment Service Provider (PSP) and of course, the card brand itself. All of whom take a piece of the transaction.

The card brands have performed this intermediary function for 5 decades, and their success was entirely justified. They put the trust into non-cash payments when none could possibly exist in a global market. Yes, there is fraud, fraud in the billions, but the volume of traffic across the card brand rails is in the multi-TRILLIONS.

Nothing could match the card brand’s acceptance, security and sheer ubiquity …until now. The smartphone we all take for granted has the capability to match the assurances represented by the card brand logos, all while bringing payments back to its original foundation; a representation of trust.

We are a long way from being able to disintermediate anyone in the current payments ecosystem, but tokenisation [for example] should only be seen as a patch on something broken as opposed to a solution in and of itself.

Anyone looking for solutions needs to learn to ask the right questions or their payment solutions will be out of date before they accept the first transaction.

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