Today I am going to write about tokenization. Four separate people have sent me a questions about tokenization in the last week. As a security paranoiac I figured there was some kind of conspiracy or social engineering going on – this whole NSA/Snowden/RSA thingy has me spooked. But after I calmed down and realized that these are ‘random’ events, I recognized that the questions are good and relevant to a wider audience, so I will answer a couple of them here on the blog. In no particular order:
- “What is throttling tokenization?” and “How common is the ‘PCI tokenization throttle function’ in tokenization products and services?” I first heard about “throttling tokenization systems” and “rate limiting functions” from the card brands as a secondary security service. As I understand the intention, it is to provide, in case a payment gateway is compromised or an attacker gains access to a token service, a failsafe so someone couldn’t siphon off the entire token database. My assumption was that this rate monitor/throttle would only be provided on de-tokenization requests or vault inquiries that return cardholder information. Maybe that’s smart because you’d have a built-in failsafe to limit information leakage. Part of me thinks this is more misguided guidance, as the rate limiting feature does not appear to be in response to any reasonable threat model – de-tokenization requests should be locked down and not available through general APIs in the first place!!! Perhaps I am not clever enough to come up with a compromise that would warrant such a response, but everything I can think of would (should) be handled in a different manner. But still, as I understand from conversations with people who are building tokenization platforms, the throttling functions are a) a DDoS protection and b) a defense against someone who figures out how to request all tokens in a database. And is it common? Not so far as I know – I don’t know of any token service or product that builds this in; instead the function is provided by other fraud and threat analytics at the network and application layers. Honestly, I don’t have inside information on this topic, and one of the people who asked this question should have had better information than I do.
- Do you still write about tokenization? Yes.
- Are you aware of any guidance in use of vault-less solutions? Are there any proof points or third-party validations of their security? For the audience, vault-less tokenization solutions do not store a database of generated tokens – they use a mathematical formula to generate them, so no need to store that which can be easily derived. And to answer the question, No, I am not aware of any. That does not mean no third-party validation exists, but I don’t follow these sorts of proofs closely. What’s more, because the basic design of these solutions closely resemble a one-time pad or similar, conceptually they are very secure. The proof is always in the implementation, so if you need this type of validation have your vendor provide a third-party validation by people qualified for that type of analysis.
- Why is “token distinguishability” discussed as a best practice? What is it and which vendors provide it? Because PCI auditors need a way to determine whether a database is full of real credit cards or just tokens. This is a hard problem – tokens can and should be very close to the real thing. The goal for tokens is to make them as real as possible so you can use them in payment systems, but they will not be accepted as actual payment instruments. All the vendors potentially do this. I am unaware of any vendor offering a tool to differentiate real vs. tokenized values, but hope some vendors will step forward to help out.
- Have you seen a copy of the tokenization framework Visa/Mastercard/etc.? announced a few months back? No. As far as I know that framework was never published, and my requests for copies were met with complete and total silence. I did get snippets of information from half a dozen different people in product management or development roles – off the record – at Visa and Mastercard. It appears their intention was to define a tokenization platform that could be used across all merchants, acquirers, issuers, and related third parties. But this would be a platform offered by the brands to make tokenization an industry standard. On a side note I really did think, from the way the PR announcement was phrased, that the card brands were shooting for a cloud identity platform to issue transaction tokens after a user self-identified to the brands. It looked like they wanted a one-to-one relationship with the buyer to disintermediate merchants out of the payment card relationship. That could be a very slick cloud services play, but apparently I was on drugs – according to my contacts there is no such effort.
And don’t forget to RSVP for the 6th annual (really, the 6th? How time flies ….) Securosis Disaster Recovery Breakfast during the RSA Conference.
On to the Summary:
Webcasts, Podcasts, Outside Writing, and Conferences
Favorite Securosis Posts
- Rich: Security Management 2.5: Negotiation. I hate negotiating. Some people live for it, but I can’t be bothered. On that note, I need to go buy a car.
- David Mortman: Firestarter: Crisis Communications.
- Mike Rothman: Security Management 2.5: Negotiation. This is a great post. A solid plan for buying any big-ticket item.
- Adrian Lane: Apple’s Very Different BYOD Philosophy. Nobody else has covered this to my knowledge, but Rich describes it very clearly. Enterprise-owned devices are simpler, but iOS almost seamlessly handles the division between enterprise and user domains on BYOD gear. Not very dramatic but simple and effective.
Other Securosis Posts
- A Very Telling Antivirus Metric.
- Reducing Attack Surface with Application Control: Use Cases and Selection Criteria.
- Incite 1/15/2014: Declutter.
- Advanced Endpoint and Server Protection: Assessment.
- Cloud Forensics 101.
- The SIXTH Annual Disaster Recovery Breakfast (with 100% less boycott).
- Reducing Attack Surface with Application Control: The Double-Edged Sword [New Series].
- New Paper: What CISOs Need to Know About Cloud Computing.
- Summary: Enlightening Embarrassment.
- Security Management 2.5: Migration.
- Security Management 2.5: Selection Process.
Favorite Outside Posts
- Rich: How long will 3rd party anti-malware companies support XP? The one place I don’t see the need for AV declining is XP. I’m waiting for banks to stop insuring retailers and other financial organizations who use it.
- Dave Lewis: A conversation with Joshua Rogers. Yeah, it’s mine.
- David Mortman: Empathy: The Essence of DevOps.
- James Arlen: Is Your Twitter Password Secure?
- Adrian Lane: The AWS of Things. I was not expecting Andrew to look at the AWS side of Nest – but an interesting view of how Google is currently on Amazon AWS.
- Gal Shpantzer: The AWS of things. My fav is Andrew Hay’s OSINT on Nest’s AWS presence. Complete with his own use of MasScan (Graham’s version of ZMap, kinda).
- Mike Rothman: The whole story… Inspiring story from Jeremiah about how he bought his Dad maybe the greatest present ever. And made an unforgettable experience out of it.
Research Reports and Presentations
- What CISOs Need to Know about Cloud Computing.
- Defending Against Application Denial of Service Attacks.
- Executive Guide to Pragmatic Network Security Management.
- Security Awareness Training Evolution.
- Firewall Management Essentials.
- A Practical Example of Software Defined Security.
- Continuous Security Monitoring.
- API Gateways: Where Security Enables Innovation.
- Identity and Access Management for Cloud Services.
- Dealing with Database Denial of Service.
Top News and Posts
- 10 Ways to Prep for – and Ace – a Security Job Interview. You might benefit from this, or you might find it funny. Or both.
- Asia’s First Bitcoin ATM.
- Starbucks iOS app leaves user data in the clear.
- Adobe Updates Flash, Reader, Acrobat.
- The business of ad blocking.
- Cell Phones Provide Cheap Trackers.
- Krebs looks at Target PoS Malware.
- BSides San Francisco 2014.
- Cisco confirms undocumented backdoor.
- Hack in the Box Europe 2014.
- Searching for Helen Fuchs. Good post. Also note the FBI knows who searches for what.
- Murdered Hasidic Developer Tracked by Hidden Cell Phone.
- Federal Court Guts Net Neutrality Rules. Our network, our rules.
Blog Comment of the Week
This week’s best comment goes to Todd Thiemann, in response to Advanced Endpoint and Server Protection: Assessment.
What role would attestation play in determining your security posture? This might not play in understanding vulnerabilities, but it would help to understand compromises. If you can attest that the hardware/software stack of a given system is in a known, valid/trusted state, you could go a long way towards avoiding Advanced Persistent Threats that have pre-occupied organizations of late.
Reader interactions
2 Replies to “Friday Summary: January 17, 2014”
@Audra,
I wish I actually knew/understood the full motivation behind this effort. Visa recognizes that tokenization improves security, but they don’t do stuff like this out of charity. It’s either because they think a standard, widely adopted, with drastically cut fraud, or that there is a new revenue stream to be had with the inclusion of a more advanced framework. Or both.
Does EMVCo genuinely think tokenization is viable for mobile security issues? No idea. I’ve heard several companies discuss different tokenization approaches for mobile payment, but these are all early/speculative proposals. I’m sure EMVco will _market_ that concept, but the real motivations — and the real framework/specification — are hidden from public view. I could speculate on some stuff but I’d like some facts or some of my sources to corroborate some ideas first.
-Adrian
What’s behind EMVco’s latest tokenization news: http://www.paymentsnews.com/2014/01/emvco-to-work-on-payment-tokenization-standards.html
Is this an effort by Visa/AMEX/Discover et al to solve mobile commerce security or a broader attempt by the card assns. to create a universal token that would replace the PAN? What’s EMVCo’s real motivation here?