Brian Pennington

A blog about Cyber Security & Compliance


Tokenization (data security)

PayPal, Payments and PCI

The logo of Ingenico SA

Ingenico has announced a partnership with PayPal which will enable merchants with Ingenico POS devices to accept PayPal payment options, read the press release here.

Ingenico and PayPal have each made statements on the relationship:

“Today’s savvy shoppers want the option to choose how they pay for goods and are agile enough to easily switch between multi-shopping platforms. Our goal, as one of the key POS device and solutions providers, is to equip merchants with a versatile secure platform capable of accepting and handling diverse forms of payment,” said Thierry Denis, president of Ingenico North America. “By working with PayPal to bring their payment solutions to offline retail, we will naturally empower both the merchant, by providing a better way to connect with its shoppers to generate incremental sales, and the shoppers by adding speed and convenience at the checkout combined with expanded payment options. This relationship enables us to offer the most advanced solution for today’s practical shopper”

“PayPal’s vision for the future of shopping includes people making purchases anytime, anywhere and over any device. Ingenico is helping PayPal realize this vision by putting PayPal in stores and at the point of sale,” said Don Kingsborough, vice president of retail and pre-paid products. “Millions of PayPal users will soon have several innovative ways to make purchases at many of their favorite retailers, including using Ingenico terminals to swipe their PayPal payment cards or to enter the mobile phone number and pin associated with their PayPal accounts.”

Walt Conway a prominent QSA and manager at 403Labs commented:

The first question is, if a PayPal card triggers a transaction on an underlying Visa or MasterCard, might that PayPal account be considered a “high-value token” and, therefore, be in scope for PCI? The follow-up question is, if the PayPal account is in scope, is it necessarily a big deal?

I read the piece about Home Depot letting shoppers pay in-store using PayPal:

“On the payment front, this is also a test of Home Depot accepting a rectangular magstripe card that doesn’t say MasterCard, Visa, American Express, Discover or Home Depot on it.”

Separately, I saw where Ingenico launched a new PayPal offering. It enables PayPal users to make retail purchases (using Ingenico terminals, of course) by swiping their PayPal payment cards or entering the mobile phone number and PayPal PIN. Because many (although not all) PayPal accounts are tied to an underlying payment card, which is in scope for PCI, and because using such a PayPal account ultimately triggers a payment-card transaction, would PayPal in this case fit the PCI Council’s definition of a high-value token?

A high-value token is a new concept the PCI Council introduced and defined in its PCI DSS Tokenization Guidelines. Specifically, the Council defines a high-value token as one that “could potentially be ‘monetized’ or used to generate fraudulent transactions.” The guidance goes on to say: “Additionally, tokens that can be used to initiate a transaction might be in scope for PCI DSS, even if they cannot directly be used to retrieve PAN or other cardholder data.”

PayPal accounts were not designed to be tokens. However, because a stolen or compromised PayPal account could be used to generate fraudulent transactions, that PayPal account appears to act like not just any old token but a high-value token. The PCI Council states that high-value tokens may be in scope for PCI and, at the least, they require “additional controls in place to detect and prevent attempted fraudulent activities.”

Let’s move on to the second question. If a retailer (or its acquirer or QSA) considers PayPal accounts to be high-value tokens, does it matter? For many merchants, the PayPal transactions will use the same devices, networks and procedures that are already in scope for PCI.

Therefore, there might be no significant impact of PayPal acceptance for a retailer with a PCI-compliant POS system. Things might get complicated when the merchant stores the cardholder data, in which case the PayPal account information may expand the scope of data to be protected.

Thank you Walt for permission to use your excellent work.

Can Tokenization help to reduce the risk of fraud involving Credit Cards?

When it comes to protecting sensitive data, especially credit card data, an organisation needs protection in place because it is a constant battle against a variety of attacks with the two greatest foes being:

  • Social Engineering (e.g. preying on employees or customers)
  • Technology (hackers, viruses, etc.)

Social Engineering can be addressed by implementing regular training, professional management and monitoring, but Technology is a different story.

Technology is an on-going battle with thousands of new attacks being developed every week, e.g. viruses, Trojans, code breaches (e.g. SQL injections), etc.

New attack vectors require new defences, just like in fencing as one fencer makes a move the other needs to counter.

Security moves and counter moves cost time and money, especially when you consider that potential weakness could be in any device on the network e.g. phone systems, servers, BYOD, printers, etc. In a flat or non-segmented network one breached device could potentially lead to the breaching of all devices.

If multiple devices and applications require access to credit card data, e.g. CRM and Customer billing, the scope of risk is far greater which is why reducing the scope of the risk is so important.

Tokenization can dramatically reduce the scope by changing credit card data, and other sensitive information, into usable data that contains no Personally Identifiable Information (PII) or Credit Card data. The original data is then stored in a “data vault” which has strong encryption wrapped around it.

For some companies Tokenization has reduced the risk-points from several dozen to one and if placed in the “cloud” could place the organisations technology and infrastructure out of PCI DSS’s scope.

For details on reducing the scope of PCI DSS see my other post Eight Ways to Reduce PCI DSS Audit Scope by Tokenizing Cardholder Data

For a copy of the guide “Tokenization for Dummies” click here.


Data Security Survey to gauge organisations’ perception of their own IT security

As we near the end of 2011 Hitachi ID Systems has run its first annual Data Security Survey to gauge organisations’ perception of their own IT security.

Survey background

Hitachi’s survey focused on Identity and Access Management (IAM) and had several “hundred” respondents from 16 different industries including agriculture, aerospace, construction media and retail.

The largest group of respondents (69%) employed less than 5,000 people

Key findings of the survey

  • 52% of businesses were “somewhat confident” in their Data Protection Measures
  • 39% of business had “some” Data Protection Measures in place
  • 33% of business said they had “strict” controls in place
  • 15% had privileged access management systems in place (who has all the keys to all the safes?)

More findings are in the graph below:

Sticking with Hitachi. Hitachi ID Systems CTO, Idan Shohamn “Looking Ahead to 2012” predicts the following as future trends in the IAM space:

1. Bring your own device (BYOD)

The “BYOD” trend is both unavoidable and troubling. Users, including executives, insist on the undeniable convenience of using their own, integrated and super-portable endpoint device. IT professionals are struggling to control access to sensitive corporate data on devices — which they do not control. It’s going to take a lot of innovation to resolve this conflict, but maybe we’ll see some progress in 2012.

2. Market Consolidation (in the IAM marketplace)

3. Identity and Access Management as a Service (IAMaaS)

Hosting an IAM system in the cloud (IAMaaS) and using it to manage identities and entitlements both inside the perimeter and in the cloud is still a new, risky game. This said, there will undoubtedly be some uptake in 2012, but just early adopters.

4. Identity Administration and Access Governance

Another interesting development in 2011 was the emergence of “access governance” as a separate product category, layered on top of “identity administration.” Currently, there are vendors in this market such as SailPoint, Aveksa and Approva (News – Alert). The thinking is that a requests portal, approvals workflows, access certification and policy enforcement should be layered on top of whatever IAM system an organization already has; something simple like incident management or more robust like a user provisioning system.

“In 2012, I predict that we will see the market begin accepting identity administration and access governance as two sides of the same coin. Here at Hitachi ID Systems, we used to provide a separate access certification product; at some point we realized this was a mistake and simply folded the features into our Identity Manager. I expect that some of our competitors will do the same in 2012; they may even clean up their user interfaces and lower their TCO.

So what does this mean for the “access governance” vendors? They have to learn to compete with the big boys. Their solutions need to scale; running access certification for just finance and HR users does not qualify as an enterprise solution. They will have to offer connectors. And password management. And user enrollment. While developing an aesthetically pleasing user interface to cover up old junk is okay to sell for a little while, it’s certainly not enough in the long run.”

The full article can be found here.


Good news for Merchants as the PCI Security Standards Council releases Tokenization guidance

Information Security Wordle: PCI Data Security...
Image by purpleslog via Flickr

On August the 12th The Payment Card Industry Security Standards Council (PCI SSC) published guidelines to help Merchants and credit card processors take advantage of “Tokenization“.

The PCI SSC definition of Tokenization:  “Tokenization technology replaces a Primary Account Number (PAN) with a surrogate value called a “token”. Specific to PCI DSS, this involves substituting sensitive PAN values with non-sensitive token values, meaning a properly implemented Tokenization solution can reduce or remove the need for a merchant to retain PAN in their environment once the initial transaction has been processed.

Merchants are ultimately responsible for the proper implementation of any Tokenization solution they use, including its deployment and operation, and validation of its Tokenization environment as part of their annual Payment Card Industry Data Security Standard (PCI DSS) compliance assessment.

Organizations should carefully evaluate any solution before implementation to fully understand the potential impact to their CDE (Cardholder Data Environment). The paper helps guide merchants through this process by:

  • Outlining explicit scoping elements for consideration
  • Providing recommendations on scope reduction, the tokenization process itself, deployment and operation factors
  • Detailing best practices for selecting a tokenization solution Defining the domains, or areas that specific controls need to be applied and validated, where tokenization could potentially minimize the card data environment

This additional guidance also benefits tokenization service providers and assessors by informing them on how the technology can help their merchant customers limit or eliminate system components that process, store, or transmit Cardholder data, and reduce the scope of the CDE and thus the scope of a PCI DSS assessment.

“We’ve continued the process to investigate these technologies and ways that the community can use them to potentially increase the security of their PCI DSS efforts” said Bob Russo, general manager of the PCI Security Standards Council. “These specific guidelines provide a starting point for merchants when considering tokenization implementations. The Council will continue to evaluate tokenization and other technologies to determine the need for further guidance and/or requirements.”

Jeremy King, European director of the PCI SSC, said the process is challenging because not all cards have a 16-digit primary account number (PAN). Some Tokenization methods are more applicable than others according to the card in question. Some tokens try to preserve the format of the original PAN in order to maintain compatibility with internal processing applications, while other approaches may generate a new truncated or randomised number, King said.

Systems that allow you to get back to the PAN need to be properly protected, and are in scope,” King said.

Tokenisation can have a dramatic reduction on the requirements of PCI DSS. In simple terms if a Merchant has no credit card data stored the scope of PCI DSS is reduced.

For the majority of Merchants reducing the scope of PCI DSS by not storing Credit Card Data can mean the difference between a relatively simple Self Assessment Questionnaire (SAQ) e.g. SAQ A and the highly complex and extremely difficult SAQ D.

The PCI SSC Tokenization Information Supplement can be downloaded here.


Create a free website or blog at

Up ↑

%d bloggers like this: