Entries tagged with “tokenization”.


“The times are tough now, just getting tougher  - This old world is rough, it’s just getting rougher - Cover me, come on baby, cover me” – Bruce Springsteen 1984

Businesses work very hard to build their brand.   Small businesses are no different.  Establishing trust and loyalty among the customer base is essential to the longevity of any business.  Many companies focus on marketing and sales relationships to ensure that connection between customer and company continues to grow.  Social media, direct mailings, radio and tv advertising, print advertising, and data security and privacy policies all contribute to the growth of brand trust.  What a minute!  Did I say data security and privacy policies?  You betcha!  This is what I like to refer to as “brand security.”  Businesses spend an inordinate amount of time and money on establishing a brand that customers trust.  One of the fastest ways to lose that trust is to suffer a data security breach or to violate customer privacy.  For that reason, I often refer to data security and privacy programs as “brand cover.”

I’m going to borrow heavily, and probably poorly, from law enforcement and military actions here.  When you go into action, you generally have a forward team and then you have a team that provides “cover.”  This team keeps an eye out for threats that may not be visible or apparent to the forward team, but pose significant risk.  In the business world, one can think of your sales and marketing efforts as the forward team, while data security and privacy programs provide the cover.  You marketing and sales efforts move the company forward and increase awareness.  Your data security and privacy programs help to mitigate unseen, and sometimes unknown, risks to your brand’s integrity.  In fact, some larger organizations, particularly not-for-profits, are more concerned about brand damage in the event of a security or privacy compromise, than they are the fines that may be associated.

For small businesses, implementing and enforcing data security and privacy policies can seem daunting.  The Better Business Bureau, though, has put together a primer for businesses to help them develop these programs.  If you accept debit and credit card transactions, you can look for services to help minimize how much of that sensitive payment data your business stores.  You can also undertake an inventory to see just what data you are collecting and storing and how you are protecting it.  You can also evaluate the partners that you use and how you share data with them. Understanding your data can ultimately serve as a very effective means of protecting your company, your brand, and your customers.

When we talk about the protection of data, particularly sensitive personal information like credit card or social security numbers, we often focus on “digital data.”  By digital data, I mean that data that is stored in our networks and computers, our POS systems and other “networked” appliances.  It’s easy to lose sight of the fact that copiers, printers, and fax machines are often “networked appliances,” complete with memory.  That means that it is conceivable that when you send a fax or make a copy, that appliance could retain that data in its memory.  As a result, that appliance now represents a point of vulnerability for the network.

The ability of these devices to store data should also be a consideration with looking to lease or buy previously used equipment, particularly when buying or leasing used POS equipment.  You may be introducing someone else’s liability into your secure environment.  This is where having proper policies and procedures becomes vitally important.  Merchants should have a process for evaluating security options on the device or equipment (does it allow for overwriting or encrypting the data in memory?); security procedures should also be in place to ensure that the device memory is regularly overwritten to avoid data leakage.

The PCI DSS specifically requires that companies “Protect Stored Cardholder Data Wherever it is Stored.”  Unfortunately, as our businesses grow, that often means that our cardholder data environment grows along with it.  Information security policies and processes become more and more important.  It can also be helpful to find strategies for limiting the size of the cardholder data environment.

“When good people…cease their vigilance and struggle, then evil men prevail.” - Pearl S. Buck

When I was learning to ride a motorcycle my instructor gave me one piece of advice that always stayed with me.  He said “keep your head on a swivel.”  In other words, while I had to make sure that I was doing everything I should be doing, I also had to make sure that I was constantly looking out for what other people may be doing.  That way I could correct my course, or at least take some action to ensure that what the other people were doing wouldn’t put me in danger.  While this is certainly good advice for riding motorcycles, it is also good advice for data security.  It may seem like a stretch, but bear with me.

In securing our customers’ payment data, we have a guideline (actually a set of fairly stringent requirements) in the form of the Payment Card Industry Data Security Standards (PCI DSS).  To learn more about these standards visit this site.  Following these guidelines ensures that we are doing what we “should” in terms of protecting the data.  But that doesn’t mean that others won’t be taking action to put you (and your data) in danger – in the form of data compromise.  That means that you have to stay vigilant for what others might be doing – “keep your head on a swivel” –  to ensure that you are addressing newly identified risks and vulnerabilities that may not be addressed by the guidelines.

Recent trends indicate that small merchants are increasingly becoming targets of data thieves.  In a recent interview, Vantiv Vice President David Mattei stated, “…now we’re seeing an increase in the number of breaches in which smaller numbers of cards are compromised. Small, independent merchants are being targeted because of the ease with which fraudsters can compromise those payment systems.” That means that as small merchants, even if we are PCI DSS compliant, we must remain vigilant against potential attack.  One way to foil the fraudsters in this case is with the use of a P2P Encryption and tokenization solution. In this instance, the data is removed from the merchant system and replaced with “tokens,” or abstract representations of the cardholder data.  While merchants can still use the data to run reports, issue refunds or fight chargebacks, data thieves would find the tokens to be worthless.

The lesson in all of this is that we must remain on guard against new threats, even if we are doing everything “by the book.”  Leveraging secure technologies like tokenization can help ease the burden of compliance and render you and your customers more secure in the long run.

We spend a lot of time talking about what to do to prevent a breach of networks or computer systems.  This discussion has been, and continues to be, very valuable.  It is discussions like this that have allowed the payments industry to develop solutions like ProtectPay, ProPay’s secure payment solution.  ProtectPay, for instance, allows merchants to accept payment card transactions without storing, processing, or transmitting payment card data.  The benefit of such a system is tremendous.  Not only does it allow companies to significantly reduce the costs and resources necessary to achieve PCI DSS compliance, but it also reduces the risk associated with a breach.  If a merchant using a properly configured tokenization solution is breached, there is no data there to be stolen.  The merchant has only value-less tokens, not valuable cardholder data.  Unfortunately, tokenization isn’t yet universally employed.  That means that there are quite a few merchants operating today that still have cardholder data in their systems.  And while the conversation about preventing a data compromise is important, an important question still remains: What happens after the breach?

Experian and the Ponemon Institute teamed to answer that question.  The results can be found in “The Aftermath of a Data Breach.” (Registration is required to download the study.)  Of the companies studied, 45% indicated that the company lost bank or credit card information, and 60% of respondents indicated that the data that was stolen was unencrypted.  Additionally, the study found that 34% of breaches studies were the result of a “negligent insider.” This seems to support the notion of using a tokenization solution.    It should be noted that 19% of responding companies suggested that “outsourcing data” was the cause of their breach.  Most tokenization solutions do require the outsourcing of data, so how can these two findings be reconciled?  There are two important concepts that readers should keep in mind.  The first are the statistics and the second is due diligence.

The statistics are interesting.  The findings tell us that 60% of respondents lost unencrypted data.  That likely means that at least some of the outsourced providers that were cited as a cause of the breach were not securely storing the data.  Another interesting finding is that a full 50% of breaches were caused by insiders (negligent insiders 34% and malicious insiders 16%).  The other concept that one should keep in mind when reading the study is the concept of due diligence.  Outsourcing data is a big decision for any company.  It is advisable to do a significant amount of research into the potential vendor.  For example in the payments industry, companies that store, process or transmit cardholder data on behalf of a merchant is called a service provider or a data storage entity.  Regardless of the terminology, the company must be compliant with the PCI DSS and be registered with the card brands.  Ensuring that potential partners meet these requirements can substantially mitigate potential risk on behalf of the merchant.

The study is a very interesting read and has important lessons for those companies that store sensitive data.  Perhaps the most important lesson is this: If you don’t need the data, don’t store it!

Dr. Heather Mark, PhD; Sr. Vice President Market Strategy

It’s been a busy month for the Payment Card Industry Security Standards Council (PCI SSC).  In August the PCI SSC, the organization charged with managing and disseminating security standards related to cardholder data, released two new guidance documents.  One of the documents provided guidance on selecting or building tokenization solutions while the other was concerned with wireless networking security.  While the wireless guidelines document is an updated version of the existing document, the industry has been awaiting the tokenization guidelines for some time.  In this post, the PCI DSS Tokenization Guidelines will be discussed.  The Wireless Guidelines will be discussed in a subsequent post.

Since its introduction to the payments industry, tokenization has been heralded as one of the most effective ways to meet compliance with the PCI DSS.  This has led to a long debate among security professionals about the proper implementation of tokenization solutions for the purpose of achieving and maintaining compliance.  Without the voice of the PCI SSC, there was some trepidation about just how much reduction of the compliance effort could be achieved with tokenization solutions.

The new guidance document for tokenization offers “Key Considerations for Tokenization Operations.”  Among these considerations is the ability to retrieve cardholder account numbers from the Primary Account Number (PAN). If the organization still has the ability to recreate the PAN using the token then no benefit with respect to reduction of PCI scope will be achieved.

Another important clarification introduced in the guidance documents is that there must be a way to distinguish between the token and an actual card number.  This is particularly important as an increasing number of tokenization providers offer tokens that are virtually indistinguishable from card numbers.  They are 16 digits and will bass the Luhn test, which is a signifier of valid card number.  The PCI SSC offers several reasons for this guidance.  According to the document, “Without the ability to distinguish between a PAN and a token, the merchant or service provider may not realize that the tokenization system isn’t functioning as intended.  Additionally, PANs could be mistakenly identified as tokens, which can lead to mis-scoping of the CDE [cardholder data environment] and the possibility that the PANs are left unprotected and open to compromise.”

The document further outlines the differences between an “on-premises” solution and an outsourced solution.  An on-premises solution is one in which the merchant maintains control over the entire tokenization solution, including the system that creates the tokens.  The responsibility in this case rests solely on the merchant to maintain the security and compliance of the system, as the tokenization system, and the systems connected to it, are always in scope for PCI DSS.  An outsourced solution, on the other hand, significantly reduces the merchant’s scope.  The document then goes on to detail the responsibilities of the various parties relative to the tokenization system.

The tokenization document should prove extremely helpful for merchants that are in process of evaluating a tokenization solution.  It will allow merchants to develop their own metrics for determining the correct solution for their environment and for their abilities and resources.

Dr. Heather Mark, PhD; SVP of Market Strategy