Screen Shot 2015-09-30 at 19.07.02

EMV in the US, I Still Can’t Figure Out Why?

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).
  2. Issuers: Also a given, what ELSE are they going to do?
  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’.
  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 $ 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

Screen Shot 2015-09-26 at 14.09.46

Tokenisation – Here We Go Again?

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.

Screen Shot 2014-01-05 at 11.35.15

Continuous Compliance Validation: Why The PCI DSS Will Always Fall Short

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 tun 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.

Screen Shot 2015-09-07 at 13.43.37

The Inherent Limitations Of The Contactless Card

This week saw an announcement from the UK Cards Association that the transaction limit on contactless cards had been raised from £20 to £30 to cover the average supermarket spend of £25. This is also in response to the news that the first half of 2015 saw £2.5bn spent on contactless transactions, compared with £2.3bn for the whole of 2014. Apple Pay has followed suit, although some retailers are considering scrapping the limit altogether given the authenticated nature of the transaction.

This remarkable growth is to be welcomed as it demonstrates the willingness of consumers to embrace new payment methods. Contactless is a swift and easy way to make payments and it is clear that consumers are, finally, adopting the technology, albeit mostly with the continued use of ‘plastic’.

Yet, a closer look at the statistics shows that the use of contactless is still limited and far from reaching its full potential. Figures, again from the UK Cards Association, show that the average spend on a contactless transaction is £6.98. Yet, the average debit card purchase in 2014 was £43.45, over SIX times greater!

Contactless is used, by and large, for small purchases. Even before the raising of the transaction limit to £30, the average spend represented just over a third of the transaction limit. Consumers use it to buy their morning coffee and lunchtime sandwich, and while contactless is growing in consumer popularity and  merchant acceptance, there are still significant gaps in capability distribution.

A look at a list of the companies that accept contactless payments is an impressive who’s-who of household names, but with the exception of Waitrose and Marks and Spencer, large supermarkets are noticeable in their absence.

In part, this could be due to the fact that supermarkets are focussed more on securing consumers’ higher value weekly shops rather than smaller baskets on grocery essentials, but not all PED/terminal estates are even capable of accepting contactless. Just about all new terminals are Near Field Communication (NFC) capable, but older models are not. Cost of replacement must be in line with infrastructure end-of-life, not desire for new capability.

Mobile Commerce (or m-commerce) has also added significant complexity to the retailer’s decision-making process. Traditional (and most legacy) terminals are built for purpose; the acceptance of branded payment plastic. The enormous flexibility and functionality of the MUCH cheaper mobile payment acceptance devices can significantly improve the entire consumer shopping journey, something that no retailer can afford to ignore.

Contactless cards don’t require any initial authentication to use them with the exception of mandatory PIN entry after a specified number of uses (usually 5 in the UK). This limits their usefulness to brick & mortar retail as the risk of fraud and chargebacks is fairly significant. With the use of contactless via a consumer mobile device, the number of authentication factors and modes can make contactless payments as secure as chip & PIN.

When consumers have the ability to seamlessly authenticate themselves to make a payment, the limits on how, and how much they spend, are removed.

So, while it is encouraging to see contactless payments become more popular, it is inevitable they will only reach their true potential via consumer mobile devices, and not plastic cards.

[Ed. Written in collaboration with]

Screen Shot 2015-09-01 at 13.59.12

Continuous Vulnerability Management: Security as a Baseline

Ask 100 security ‘professionals’ what vulnerability management is and at least half of them will begin with patching, another 25% will focus on vulnerability scanning and penetration testing, and the majority of the rest will start quoting the gamut of Risk Assessment to Business Continuity. I’m not saying they are wrong, but most will not be right enough.

If you accept this description as standard; “Vulnerability Management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities, especially in software and firmware. Vulnerability Management is integral to computer security and network security.“, it’s no wonder that actually performing appropriate vulnerability management is a concept rife with misinterpretation and bad decisions.

The old adage; “You can’t manage what you can’t measure.”, while often incorrectly interpreted from the original work of W. Edwards Deming, is actually completely relevant in information security. Security is series of baselines / whitelists /  known-goods, and is only ever effective if it’s simple and repeatable. In other words, if you don’t have a point to measure security from, how can you possibly know if it’s enough, or too much?

Like every process in security, vulnerability management  is only as good as the context in which you place it, and ANY security process out of context from the underlying business goals is doomed to failure. Rightfully so. The vulnerability management controls you put in place relevant to your environment therefore go through the exact same process as every other control, from firewalls to outsourcing.

Step 1: Determine your business goals – in order to conduct an appropriate Risk Assessment (RA) and Business Impact Analysis (BIA)

Step 2: Conduct a gap analysis – to determine the shortfalls or over-extensions between current security capability and desired capability

Step 3: Fill the gaps – to the capability level determined by the BIA (accept residual risk)

Step 4: Determine appropriate baselines – for the management, maintenance and monitoring of the ‘new’ infrastructure/processes

Step 5: Place appropriate ISMS-esque controls – around the ongoing management, maintenance and monitoring of the new infrastructure/processes

Step 6: Develop appropriate mechanism for the decision making process – from responsibility / function, to scoring / rating, to mitigation, everything must be in-line with Step 1 in order to be effective and sustainable

Step 7: Determine all control inputs to the process – including – and certainly not limited to – patching, vulnerability scanning, penetration testing, code review (if applicable), logging, FIM, and so on…

Step 8: Determine all appropriate internal and external sources of threat intelligence  – from relevant vendors to paid-for services.

Step 9: Bring everything together into a Management capability – one with a specific charter and report structure.

Step 10: Re-examine every step for continued relevant and effectiveness – on a regular basis

If this sounds complicated, it’s likely that you don’t understand one or several of the steps. All aspects of security are simple, they have to be, and while is can be difficult to implement, that’s almost always because you are not asking the right questions. In any endeavour outside of your business’s core competencies, the trick is not to ask for what you think you need, it’s to ask for help from someone who KNOWS what you need.

You don’t tell your doctor you have a brain tumour, you tell them you have a headache a leave the diagnosis up to the expert.

[Ed. Written in collaboration with Voodoo Technology, Ltd.]