Merchant Link SecurityCents

A blog that comments on the latest developments in the world of payments, payment data security and technology, PCI compliance, and more.

Posts Tagged ‘ PCI Council ’

By Beth McGarrity

As the year comes to a close, and TV personalities from Oprah to Ellen to Barbara Walters highlight their favorite things and most fascinating stories in 2011,  I thought I’d take a moment to reflect on my favorite SecurityCents posts and industry news and share them with you.

PCI Announces Guidance for Merchants.

Merchants were provided with an abundance of guidance this year on emerging technologies that assist with compliance and securing sensitive data.  The first documents were released in late 2010 and focused on point-to-point encryption followed by tokenization and virtualization.  In the New Year, the Council will focus on three new areas including cloud, risk assessment and e-commerce security.

Validation from Coalfire Systems.

It’s easy for vendors to say that their product or solution is going to help merchants reduce the scope of PCI compliance.  In some cases, it’s really just unsubstantiated marketing hype.  At Merchant Link, we invest significantly in R&D to ensure that our solutions really do reduce PCI scope and we wanted to offer our customers a third-party validation of this fact.  Coalfire evaluated our TransactionVault™ and TransactionShield™ solutions for tokenization and encryption and confirmed our findings.

Avivah Litan Talks Tokenization.

We had the honor of featuring Avivah Litan on a podcast recently to discuss payment security.  As a renowned expert in this area, Avivah regularly publishes industry research and opinions on her own blog that we avidly follow here at Merchant Link.  For this podcast, Avivah focused on key trends in payment security, specifically as it relates to point-to-point encryption and tokenization.

Google Wallet Meets MasterCard and NFC.

Its here!  Finally…well…sort of.  The technology for mobile wallets has been around for awhile, but the concept hasn’t caught on very well. Then Google entered the market with the mobile wallet, using Near Field Communications (NFC) to allow for data exchange with point-of-sale (POS) technologies. From the payment side, the company partnered with MasterCard and Citi to allow users to pair credit cards to their phones.  It’s been an interesting progression to watch and something we will certainly keep an eye out for as the issues surrounding secure payment transactions will be top of mind for merchants.

What else is on your list of favorite things from 2011?  Share them with us by posting a comment below.

We are coming to the end of the year, when everyone takes a look back and reflects on the past 12 months and tries to determine the trends that will impact the coming year. Many industries are facing a sobering outlook for 2012 and looking to do more with less.

The hospitality sector in particular has struggled with the economic downturn the past few years. Steve Short, president of NetLink Resource Group, says that it is still possible for hospitality executives to achieve their goals by investing in smart IT projects to drive business growth.

By smart, I assume he means that these IT projects should help the company meet business objectives while simultaneously saving the company money. My guess is that many will look to implement cloud solutions that require less management and maintenance.

But specifically, the hospitality sector should focus on investment in projects that secure their sensitive customer data and by extension, their brand reputation. The potential return on investment includes simplified PCI compliance. Technology solutions such as point-to-point encryption and tokenization have been reviewed by the PCI Council, resulting in documents that guide executives on how to properly implement these solutions.

As budgets decrease and focus on ROI increases. making sense of the dollars and cents is more challenging ever. But given the cost of compliance, and the cost of a potential data breach, the hospitality sector should seriously consider and measure the ROI of protecting their data.

To read more from Steve Short and his predictions, check out his blog on HTFP Connect.

By Michael Ryan

This week, our team is down in Arizona for the North American PCI Community Meeting.  Each year we look forward to this event as it offers us a chance to network with Qualified Security Assessors (QSAs) and fellow Special Interest Group (SIG) members as well as others in the community and discuss the issues that are facing merchants both big and small.

In fact, the discussions are quite helpful as this is really the time for the PCI Council to outline programs, resources and goals for the coming year.  One of the most interesting aspects is to learn what the Council will provide guidance on next.

Merchant Link has been a part of the SIGs for both tokenization and point-to-point encryption (P2PE) and continues to offer our expertise in an effort to provide guidance to merchants.

We were excited to see that right before the meeting this year, the Council announced guidelines for P2PE focused on hardware-based implementations.  The 96-page document provides guidance on securing systems and devices, implementing monitoring and response processes, developing and maintaining secure applications, protecting sensitive data, and using secure cryptographic key management methodologies.  Interestingly enough, the Council has said that even with these guidelines, merchants should only use applications that have been validated to be PCI compliant.  This list is targeted to post on their website in spring 2012.

Perhaps, this delay, along with the delays for the tokenization guidelines and virtualization guidelines is why the Council is taking a new approach to SIGs.  For 2012, the SIGs will be manned by a Council member to ensure that the group stays on task and will only have a term of 12 months.

Over the last couple months, many proposals were made for what guidance should come next.  The proposals were short-listed and voting will take place on the PCI portal.  I’m looking forward to seeing what’s on the agenda for next year.

By Michael Ryan

Over the past month, there has been a great deal of discussion about tokenization.  The PCI Council released much awaited guidelines in early August and while many questions were answered both vendors and merchants asked for more clarity.

If you haven’t done so yet, take a look at the tokenization buyers guide that was developed by Walter Conway.  The guide provides an unbiased and technology-neutral look at tokenization.  It addresses how tokenization may reduce a merchant’s PCI scope and offers methods on how to evaluate alternative vendor products. Merchants can view this buyer’s guide along with the guidance from the PCI Council to determine what solution is best for their environment.

Now, there are certain areas within the guide that I didn’t necessarily agree with.  In particular, the subject of token collision or exhaustion that may exist with some format preserving tokenization solutions as well as processing delays that may arise from card-based tokenization methodologies.

Each of Merchant Link’s clients has tens of billions of tokens available to them to make the issue of collision or exhaustion near impossible. We also process billions of card-based tokenization transactions each year with no noticeable delay in processing speed. As Conway suggests merchants should be aware of these issues and discuss them with their prospective vendor.

Conway also offers an excellent checklist within the document that we believe every merchant should use when considering which solution to employ.  If you haven’t checked it out yet and you are considering a tokenization solution, I highly recommend it.

Originally published by SC Magazine, reported by

The use of a tokenization solution does not eliminate a merchant’s need to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS), the industry group responsible for managing payment security guidelines said in a new document released Friday.

“The misconception is that I can buy one of these [tokenization solutions] and be PCI compliant,” Bob Russo, general manager of the PCI Security Standards Council, told “That’s not the case.”

A mature and properly deployed tokenization solution can, however, simplify the requirements of PCI DSS by taking systems that no longer contain sensitive credit card numbers out of the scope of the standard, according to the 23-page supplement released by the PCI Council.

Meanwhile, Sue Zloth, product group manager at payment data security provider Merchant Link, a member of the PCI Council’s tokenization task force, told on Friday that she believes the document is a good first step, though it may lead to some confusion and deter adoption.

Zloth took issue with a section that discusses the need to evaluate whether a token itself could be used – in lieu of cardholder data – to perform a transaction.

The document states that so-called “high-value tokens,” which can be used as a form of payment, could be monetized by an attacker or used to generate fraudulent transactions.

The council introduced a valid concern –  that certain tokens could be valuable to attackers — but “fell down” by failing to describe how a tokenization system could adequately protect tokens from being fraudulently used, Zloth said.

“A properly implemented system will know who is sending transactions and will not allow anyone to send transactions with a token,” she added.

To read this full story go to

By Sue Zloth

When Google made the announcement that it was launching a new mobile wallet backed by MasterCard and Visa, we knew that the industry needed to get a better hold on mobile payment security standards.

So what has the PCI Council thought about all of this?

The Council has been evaluating mobile communication devices and the payment application landscape.  The current focus is on determining the need for advice, guidance or re-evaluation of existing PCI requirements for mobile payment transactions.

Recently, the Council issued a statement on PA-DSS and mobile payment acceptance applications that provides specific detail on the types of mobile payment acceptance applications that can meet PA-DSS requirements, and those that require additional examination from the Council.

The Council’s Mobile Working Group, which includes representatives of each payment brand, put mobile payment acceptance applications into three categories based on type of underlying platform [according to  guidance document]:

  • Mobile Payment Acceptance Application Category 1 – The category includes payment applications that operate only on a PTS-approved mobile device
  • Mobile Payment Acceptance Application Category 2 – Payment applications which meets all of the following criteria;
    • payment application is only provided as a complete solution ―bundled with a specific mobile device by the vendor;
    • underlying mobile device is purpose built (by design or by constraint) with a single function of performing payment acceptance; and
    • payment application, when installed on the ”bundled” mobile device [as assessed by the Payment Application Qualifed Security Assessor (PA-QSA) and explicitly documented in the payment application’s Report on Validation, provides an environment which allows the merchant to meet and maintain PCI DSS compliance.
  • Mobile Payment Acceptance Application Category 3 – Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing

Guidance in the third category is not being addressed by the Council at this time.  It is a very important category given the growing trend of mobile payments and it needs to be addressed.  However, in the meantime, the Council plans to release additional guidance on the other categories by the end of 2011.

By Sue Zloth


Last month a couple of us talked with John Kindervag at Forrester Research.  We spent a portion of the discussion on PCI standards, talking about the pressures that merchants feel to comply and providing updates on what we’ve been doing with the Council in their working groups.


So I, particularly, was interested when I saw John’s blog on PCI.  He points out that merchants should have knowledge of the industry in which they serve, but also recognize the connections with other verticals that may or may not be apparently linked directly to their line of business. So whether you sell ice cream or designer jeans, you fall into the category of payment security because you process financial transactions.

Here is what John said in his blog:

Companies often demand to know what their peers in a particular vertical market are doing within the realm of information security before making new decisions. “We’re in retail” or “healthcare” or “financial services” they will say, “and we want to do what everyone else in our industry is doing.” Why? The TCP/IP revolution has changed everything, including how vertical markets should be viewed. In the old analog world, you could define yourself by your product or service, but no longer. Today it doesn’t matter if your company sells plastic flowers or insurance — what defines you is your data and how you handle it.

When advising Forrester clients on InfoSec, the first question I ask is, “what compliance mandates are you under?” Like it or not, compliance determines how data is handled and that defines your vertical in our data-driven society. For example, I often say that, “PCI is the world’s largest vertical market.” It is a single global standard that affects more companies than not. You may think you are a hotel and your vertical is hospitality, but if you handle credit cards your real vertical — from a data perspective — is PCI.

Data defines markets. Look at your data, your transactions, and your process, and map them to your compliance initiatives. That will determine your digital — not analog — vertical. Using this measure, you can determine your security baseline and compare yourself to companies who must handle data in the same manner as you to help guide your security decisions.

By Troy Mechura

It is all too common—hackers accessing personal financial information on merchant payment systems.

Just this week, another quick service restaurant was hit with a data security breach leaving more than a dozen customers victim to credit theft. In Clive, Iowa, patrons of a local Qdoba Mexican Grill reported unauthorized banking transactions that range from several hundred to a thousand dollars.

Authorities suspect that the culprit somehow hacked into the financial clearing house used by Qdoba to process credit and debit cards. Fortunately, banks are recovering these victims’ losses. Instead of customers worrying about the taste of their food, they have to worry about the safety of their personal information.

So here is yet another example of a restaurant falling prey to a security breach. When valuable information is stored on POS systems, they become prime targets for hackers like the one in Iowa because they are less difficult than large scale attacks.

If merchants want to maintain the trust of their customers, they must take preventative measures to ensure the safety of personal financial data. Many cite that they meet the minimum standards set by the PCI Council, but that always isn’t enough. Merchants should utilize encryption or tokenization solutions that practically eliminate the opportunity for security breaches by taking valuable information off payment system’s network. These tools remove sensitive data that restaurateurs simply don’t need in the first place. If you get rid of the data, you get rid of the risk.

By Sue Zloth

Call it what you will – Tokenization in the Cloud or Tokenization as a Service.  No matter what you call it, the bottom line is removing sensitive cardholder data completely from the merchant’s IT environment and reducing the scope of PCI DSS.

It is an approach that we have been behind for nearly a decade, through the many variations of terminology.  Ultimately, we believe strongly that keeping card numbers within an enterprise is a security liability.

But don’t just take it from us.  Others in the industry are beginning to understand that need to take tokenization into the cloud and are beginning to offer solutions in this area and the analyst community is also nodding their heads in agreement.  It is expected that tokenization in the cloud will become a common strategy for enterprises.

We live and breathe tokenization and encryption so it is always a bright spot when we see the industry embracing this technology and the cloud approach to tokenization.

As part of the Special Interest Group (SIG) for the PCI Council, we expect to provide merchants with formal guidance on the technology shortly.  We hope that the documents will offer a better understanding for the types of tokenization and ways to implement the technology.  In the meantime, if you have questions about different approaches, feel free to drop me a comment below.

By Sue Zloth

As you may have read in my previous post, I’ve been working with the PCI Council Special Interest Group to provide recommendations on tokenization. While the PCI Council guidance on tokenization hasn’t been released yet, I decided to pursue the topic here on our blog to help educate merchants about it.  Last week, I discussed what tokenization is. This week, I’d like to talk about the different types of tokenization.

There are two main types of tokenization: transaction-based tokens and card-based tokens.

  • Transaction-based tokens relate to individual transactions. With transaction-based tokenization, a new token is created each time a transaction occurs.
  • Card-based tokens are generated for each card number. In this approach, the same token is reused every time that card number is used.

Is one approach better than the other? There really isn’t a simple answer to that question. In the end, it’s up to the merchant to evaluate how they would use token information and make the decision that is right for them.

Many merchants need to track customer purchases. They may use the credit card number as the “key” for that analysis. Once a merchant moves to tokenization, they will use the token instead.  Unfortunately, a merchant using a transaction-based tokenization system would lose the ability to track customer purchasing behavior because the token will be different for each transaction. Since the token is tied only to a single transaction, the merchant won’t know if a customer buys, for example, three items from a store over the course of a month using the same credit card.

With a card-based tokenization solution, merchants are given more insights into the purchasing decisions and activities of their customers. Card-based tokenization allows the merchant to see a customer’s activities across online and brick-and-mortar environments since the same token is always used for the same credit card.

Ultimately, both types of tokenization vastly reduce the risk of sensitive customer data being stolen should a data breach occur. Since these tokens have no value to the thief if ever stolen, the customer’s real data is kept secure.

Next up in the series: What to consider when implementing a tokenization solution