Townsend Security Data Privacy Blog

DOWNLOAD WHITE PAPER Download our AES Encryption Strategies: A White Paper for the IT Executive and learn more about deploying an encryption solution. Click Here to Download Now

Many IT executives are now faced with the urgent need to secure sensitive data on their computing systems in a very short period of time.  Decisions need to be made on what data security solutions to use, which projects need priority, and how to make the best use of available resources. The need to deploy better data security has arisen quickly and many IT executives feel the need for more information.

The data security solutions you select now will be in use for many years to come.  Over time, these solutions will be integrated into almost every major application in your IT environment.  Selecting the right solution now is an important first decision, whether that decision is to develop data encryption capability in-house, or to work with a data security solutions provider.

Here are some key questions to consider when making this decision:

• Who will be able to provide us with mature guidance on the appropriate use and implementation of encryption?
• Encryption is a complex technology - do we have the expertise and resources to do this on our own?
• Data security is incorporated into a number of regulations that control our Enterprise, are we using the right technology to satisfy these regulations? And will our solution help us minimize legal liability?
• Will our data security solutions easily extend to new requirements? We need to secure credit card numbers today. What about tape encryption, spool file reports, and IFS files? Will our data security technology lend itself to new uses?
• We transfer data between diverse systems in our internal network, and between customers, suppliers, and employees. Will our solutions meet all of these needs?

For further information and strategies for beginning and encryption project, download our White Paper titled AES Encryption Strategies: A White Paper for the IT Executive.

Many of you have asked me about encryption and key management requirements for HIPAA and HITECH Act. I can understand why there is a fair amount of confusion about this. The US Department of Health and Human Services (HHS) has not issued the final rules, but they have indicated that the current Interim Final Rules are unlikely to change very much. The final rules are due to be published later this year, and may be updated on an annual basis.

The current IFRs indicate that encryption is an accepted method of protecting patient health information. However, there is no mandate for encryption, and medical providers (Covered Entities, in HHS regulatory speak) can use other methods to protect data. However, the guidance about breach notification is very explicit on the question of encryption. A medical provider can only avoid breach notification if the data is encrypted. In the event of a data loss where the data is not encrypted, the medical provider must report the breach to HHS and to the patients affected by the loss. The breach event is published on a public web site maintained by HHS. There may be penalties for the loss of unprotected information, and HHS has already started levying fines on medical providers. Here is what HHS says about encryption and breach notification:

“Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

1. Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.“

This is how proper key management is discussed in the HHS documentation. Note that it explicitly states that encryption keys must NOT be stored on the same device as the protected data. This is very similar to the PCI DSS requirement. The HHS documentation makes reference to NIST publications, and those publications recommend the use of FIPS 140-2 key management solutions.

It is important to note that tokenization is not mentioned by the HHS guidelines at all. Tokenization vendors will probably argue that tokenized data is not patient information, so can be used to avoid breach notification. But that is a vendor claim, and is not addressed by HHS. It should be noted that like PCI DSS, the tokenization solution must also meet the HHS guidelines for encryption and key management.

The bottom line?

The only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies. Encryption keys must not be stored on the same device (server) as the protected data. NIST best practices recommend that key management systems should be FIPS 140-2 certified. Our Alliance Key Manager solution meets these guidelines and will help you get to the land of HIPAA and HITECH Act Nirvana.

For more information, download our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification with NIST-Certified Data Encryption."

 

The color silver symbolizes glamor and distinction. This year, the color silver symbolizes accomplishment for those of us at Townsend.  We have recently obtained Silver Business Partner status in Microsoft’s business partner program and the company just celebrated its 25th Silver anniversary.

Earlier this month we announced that we became a silver level business intelligence partner with Microsoft.  This new alliance will help us with the launch of our encryption key management solution for Microsoft SQL Server 2008, later this quarter.   We just returned from Microsoft’s Worldwide Partner Conference where we met with several different partners about this opportunity.   We talked with many companies who had similar interests in compliance and data protection, it was a great introduction into a new community that is very important to us.

July 14, 2011 marked Townsend’s silver anniversary – what a milestone! We owe this accomplishment to our customers, partners and our dedicated team. The company has evolved a lot over the last 25 years; we have undergone a few name changes (Patrick Townsend & Associates, Patrick Townsend Security Solutions and now Townsend Security) and a few different logos.  Our name and our look may have changed over the years, however, our mission and vision have remained the same - Townsend Security creates, sells and supports professional encryption solutions that protect data and simplify compliance.

The solutions we have introduced into the market over the years, AES Encryption, FTP Manager, Key Manager, LogAgent, XML/400 and TokenManager align with our vision. Our commitment to provide world-class support to our hundreds of customers worldwide will always be our number one priority.  And we are proud to say that a few members of the Townsend team have been with the company for over 10 years and several more are quickly approaching their 10 year anniversary, not many companies can say that in today’s economy.  As we pour that glass of bubbly and toast our silver anniversary we will be sure to thank our customers, partners and ourselves for an incredible 25 year run and set our sights on the next 25 years.  I can’t wait to see what it holds!

Be a part of our next 25 years, follow us on Facebook, Twitter, and LinkedIn.

   

As I talk to Enterprise customers I’m finding a lot of confusion about when to use encryption or tokenization, and how to think about these two data protection technologies. Once you understand how each of these technologies work, you understand that there are no easy answers to which is best for you, or when one is better than another. I want to talk about some general guidelines I’ve developed to help with this conundrum.

Encryption is well known technology, has clear standards, and has been in use for data protection for a long time. Most of the compliance regulations (PCI, HIPAA/HITECH, state privacy regulations, etc.) make clear reference to encryption and widely accepted standards. So it is a no-brainer to use encryption. When done correctly, it is going to meet compliance regulations and your security goals.

But encryption has a nasty side-effect. When you encrypt fields in your database that are indexes or keys, you disrupt the indexing capability of the field and you introduce unacceptable performance burdens on your system. Encrypting an index or key field often means re-engineering the application and this is costly and time consuming.

Enter the new kid on the block – Tokenization.

When you tokenize data you replace the sensitive data with a surrogate, or token, value. The token itself is not sensitive data, but it maintains the characteristics of the original sensitive data. It walks like a duck, it quacks like a duck, but from a compliance point of view, it is NOT a duck. Tokenizing data lets you maintain those precious index and key relationships in your databases, and minimizes the number of changes you have to do to your applications.

So, why not use tokenization for everything? Is this the magic bullet we’ve been searching for?

Hold on there, Cowboy. There are some things you should think about.

Tokenization solutions typically work by creating a separate database to store the token and the relationship to the original sensitive data. This means that every time you need to register a new token, retrieve the attributes of the token, or recover the sensitive data, you have to make a request to the tokenization solution to do this work for you. Got 10 million records in your database? This is going to have a major impact on performance. Applications that need high performance may not be the best for a tokenization approach – you might really want to use encryption in this environment.

Then there is the question of compliance. Tokenization is new technology. At this point there are no standards for tokenization solutions, and no reference to tokenization in the published regulations. So, are you really compliant if you tokenize sensitive data? I think so, but you should be aware that this is an unsettled question.

When you tokenize data, you are creating a separate repository of information about the original sensitive data. In most cases you will probably be using a solution from a vendor. Since the tokenization solution contains sensitive data, it will itself be in scope for compliance. Has the vendor used encryption, key management, and secure communications that meet compliance regulations? How do you know? If you are going to deploy a tokenization solution you will want to see NIST certification of the solution’s encryption and key management so that you are not just relying on the claims of the vendor.

Most Enterprise customers will probably find uses for both encryption and tokenization. Encryption is great for those high-performance production applications. Tokenization is great for maintaining database relationships, and reducing risks in the development, test, QA and business intelligence databases. Both can help you protect your companies’ sensitive data!

For more information on tokenization, view our recorded webcast titled "Tokenization and Compliance - Five Ways to Reduce Costs and Increase Security."

Much like going to the gym, not many people wake up in the morning and say that they want to start an encryption project.  It can take a little knowledge and some hard work to be done correctly.  But the results of both provide benefits far beyond their initial investment.

First, like a proper workout, there are two parts.  There is the encryption process and the often after-thought of key management.  You need both for a successful and compliant data privacy solution.  This is much the same as hitting the gym.  You need to do your weights as well as run on the treadmill for a comprehensive workout.  Just because you are encrypting, doesn’t mean that you are doing it correctly, or will pass any sort of audit for that matter.

Next comes the personal trainer, or in the case of data privacy, regulatory compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC, etc). Privacy regulations show you proper form.  They spell out exactly what you need to be doing to meet compliance regulations.  Check out the concepts in PCI DSS Section 3 for encryption and key management requirements.  Not only are privacy regulations helpful for providing best practices, but also in most cases apply directly to your business (PCI DSS, state privacy laws, etc.). 

Sometimes difficult to meet, compliance regulations are a good thing.  They are what protect your and my personal information.  One good way to ensure you are going down the right path is to use NIST-certified AES encryption and FIPS 140-certified encryption key management.  These certifications assure that the solution is proven and validated by a third-party.  It is a very expensive and time intensive process, but ultimately assures the encryption and key management solutions can meet the most stringent privacy regulations.  Only the very best encryption and key management offerings can do this.

Why make your workout harder than it needs to be?  Start your workout right from the beginning and you won’t be throwing your back out later (did you know an average data loss costs a company over $200 per record?).  Believe it or not, there are still some “encryption” solutions that aren’t NIST-certified.  Some companies say “we meet the standards of NIST and FIPS regulations”, but have nothing to prove it.  If you dig a little deeper you’ll see NIST has no record of them.  It’s kind of like trusting an infomercial that says all you need to do is use their contraption for three minutes a day and you’ll look like a body-builder.  I’d rather spend my time and efforts sticking to a proven method for getting in shape.

For more information on encryption and key management, download our white paper titled “AES Encryption and Related Concepts.”

 

Companies of all sizes feel the increasing pressure to protect sensitive customer information to meet PCI-DSS Standards.  Here are five ways to help ensure your database meets PCI requirements: 

1) Use certified encryption solutions to protect cardholder data

A standards-based encryption solution safeguards information stored on databases. Encryption methods approved by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  

2) Encrypt cardholder data that is sent across open, public networks
Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP).

3) Store encryption keys from your encrypted data on a certified encryption key management appliance
The most important part of a data encryption strategy is the protection of the encryption keys you use. Encryption keys safeguard your encrypted data and represent the keys to the kingdom. If someone has access to your keys, they have access to your encrypted data.

4) Enforce dual controls and separation of duties for encrypted data and encryption keys
Make sure people who have access to your encrypted data are restricted from accessing the encryption keys and vice versa. If someone can access your encrypted data and access the keys, your data is compromised.  You shouldn’t lock your door and leave the key under the mat for easy access to your home, the same precautions should be taken with your sensitive data.

5) Use tokenization to take servers out of the scope of compliance
Tokenization replaces sensitive data with a token. The token maintains the original data characteristics but holds no value, reducing the risk associated sensitive data loss. When you store tokens on a separate token server it eliminates the need to store the original data in an encrypted format, and may take the server out of scope for compliance.

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

 

I believe that every individual or company that attempts to bring encryption products to market experiences an “Aha” moment. This is the moment when you realize how very difficult it is to get encryption right, and how many ways there are to get it wrong.

It’s not just that encryption is complicated (it is; to a non-mathematician the algorithms can be mind-boggling). It’s that there are so many aspects to doing an encryption implementation correctly that the likelihood of errors is high even for the best-intentioned and most knowledgeable developers. This “Aha” moment can be dramatic. It happens when you see all of your limitations clearly and you know that you are facing a crucial challenge.

However, what a person or company does after this “aha” moment says everything about their character and the quality of the products they bring to market.

When I had this “Aha” moment years ago, I realized that our company had to radically change how we approached the development of our encryption and key management products. I knew that we had to step up to much higher standards, and change how we looked at our own products. But where does one go to figure out how to do encryption right? Fortunately, our company had several good enterprise customers who helped point the way. Enterprise security architects directed us to the National Institute of Standards and Technology (NIST) web site and the FIPS-140 certification process. The NIST and FIPS-140 certification outline the proper standards and best practices for encryption, decryption, key management, and logging.  So began the complete transformation in how we bring Townsend Security encryption products to market.

It wasn’t long, however, before the “Aha” moment was followed by an “Oh no” moment.

It quickly became clear that there was a large body of published guidance on the standards and best practices for encryption and key management. This stuff would fill a small library. And it was intense reading. This was not “Dick and Jane” beginning level stuff. It assumed that you started at a pretty advanced point in your knowledge of encryption and cryptographic module implementation. Not only are there published standards, but there are well-defined test and certification protocols.  And these tests were not going to be easy to pass. These tests are only conducted by a small number of certified labs (See NVLAP), the tests are detailed, complex, and designed to detect even the most minute errors that could cause encryption algorithms to fail.  Certification also means that you must undergo a stringent review of the encryption source code and your development practices.

This was the “Oh no” moment. This process was going to hurt.  It was going to be expensive, time consuming, and mentally taxing. And (at least initially) it was going to slow down our release schedule and increase our time to market.  There was also the concern that some competitors would rush to market faster with whiz-bang features that impressed customers in the demonstration process, but were of less importance to encrypting data.

This was going to be a huge undertaking.  I huddled with our development team. I huddled with our sales and marketing team. I took a long walk.

It was clear to me that this was a decision that would define who Townsend Security would be as a company, and it would illuminate how we really feel about taking care of our customers.  Were we really committed to doing security right and providing complete solutions to our customers?  Or were we willing to scrape along the bottom with inferior products that could be sold to less sophisticated customers?

Well, you already know how this came out. In the end I could come to no other conclusion.  We would either do the right thing, or get out of the security market altogether. We’re still in, so you know that we made that commitment and investment in NIST certification of our correctly implemented encryption solutions. We did learn a lot about encryption development processes and best practices. And I must say our products are so much better for it.

As you know, we made a substantial investment in the certification effort (we still do), and we do have some competitors, especially in the IBM System i (AS/400) marketplace, who claim to have jumped ahead of us.  But I know how dramatically our certification efforts improve our products, and I know how much better off our customers are because of it. Customers who have a NIST certified solution will be protected from harsh regulations, those who put their trust in non-certified solutions will find themselves at the mercy of ever evolving regulating standards.  As these compliance regulations evolve and incorporate standards and independent assessment in their guidelines, our customers will benefit from our efforts. And as the attacks on our protected data get ever more sophisticated, we will see poorly crafted encryption and key management products easily broken with heartbreaking losses for the companies involved.

So, I am a converted believer in the independent certification process.  No one believes that independent NIST certification is a guarantee of perfect security. But no one who has been paying attention believes anymore that a security product should be trusted without it.  We believe the encryption and key management you trust to protect your entire Enterprise database should be equally (if not more stringently) proven and validated.  Click here download a free 30-day evaluation of our NIST-certified AES encryption - available for all Enterprise platforms (Windows, UNIX, Linux, IBM i, IBM z).

Patrick

For most organizations, the entire impetus to encrypt is closely tied to the need to be compliant with one regulation or another.  There is the PCI regulation, the HITECH act of 2009, HIPAA, Sarbanes-Oxley, and a whole host of state privacy laws.  If you are going through the due diligence of database encryption, you sure as heck want to get it right the first time.

A big part of getting it right is using the right encryption tool.  There are plenty of tools on the market that claim to do encryption, and you probably know a clever programmer or two who thinks he can come up with a nifty little data scrambling algorithm that no-one has ever seen before. But encryption — real encryption — demands that we reach for a higher standard.

The U.S. Department of Commerce publishes the definitive encryption standard on its National Institute of Standard and Technology (NIST) website and to date, hundreds of cryptographic providers have achieved this high standard.  As of this writing, NIST has certified over 1,300 AES encryption implementations.

A Fundamental Truth
Cryptographers do not suffer fools lightly.  Their science is mathematically based and their algorithms are well known and well vetted.  A fundamental truth of cryptography is that real encryption cannot rely on keeping the algorithm secret.  Instead the secret that protects the data is the encryption key, and only the encryption key.  Anyone who says different may find themselves on the receiving end of an extra-long mathematical dissertation on the mathematical correctness of accepted encryption algorithms.

When you stop to think about it, this makes perfect sense.  If the world used a secret algorithm to encrypt data, if that algorithm were ever to be discovered then all the world’s data would be at risk.  But if the key is the one-and-only secret that unlocks the data, then a compromised key only puts the data at risk that was encrypted with that particular key.  All the other data that has been encrypted with other keys is still safe.  This demonstrates both the wisdom of strong (and open) algorithms, but also the essential importance of strong key protection.

Another benefit of open algorithms is that they are peer reviewed and extremely well vetted.  The AES standard that is the de-facto standard for encrypting data at rest is well known in cryptography and mathematical circles and is recognized the world over as the most effective method for encrypting business data.  Its modes of encryption are well known and proven. And there is a strong body of knowledge about how to correctly implement the AES standard.  From the perspective of a cryptographic (encryption) provider, encryption libraries are not easy to write, but they are known to be solid when implemented according to accepted standards.

Homegrown Encryption
Unfortunately, some software providers seemed to have taken a different road. AES encryption must have seemed too difficult, or too cumbersome, so instead they found loopholes and/or shortcuts to simplify their implementation.  Some software providers use untested software, or unique and un-vetted methods of encryption.  These data scrambling methods aren’t (and never could be) NIST or FIPS certified, but if their customers never ask about certification or independent validation, those providers are not likely to raise the topic.

So we are seeing a raft of uncertified, and un-vetted cipher methods introduced in the market place.  Some, like OMAC, CS, and CWC have languished on the NIST list of “Proposed Modes” for years, while others like CUSP have never even been submitted as a proposed standard.  And while it is possible that one or more of these upstart modes could be better than one of the current, standard modes, there is no way to know this because these new modes have not been properly tested and crypto-analyzed.  Without testing and peer review, each of these modes is just another premature idea that is statistically more likely to be a bad encryption method than a good one.

Show Me the Cert!
Many software vendors are beginning to recognize the value of certifications.  Some claim certifications they don’t actually have (HINT: PCI does not certify encryption software) and some will use confusing language to infer they have achieved levels of certification they haven’t.  Recently I visited a website that claimed (I’m paraphrasing):

Our stuff uses FIPS 140-2 certified algorithms to ensure the highest level of data security.

The NIST AES website displays no record of this company ever having received a certification for any encryption software.  Clearly they recognize the value of certification, but have not yet knuckled down to do the hard work to make it so.  And if you don’t check their supposed “facts,” it’s likely that you’ll soon regret it.

My advice?  When someone claims to be certified for any type of encryption, ask a simple question: “Can you show me the cert?”  It ought to be available on the web, or in paper form that they can show to you so that you know this software has passed an independent evaluation.  If they have a cert, then you can dig down deeper and find out whether the software will fit your needs.  But if they are claiming a certification that they cannot prove, my advice is to keep your hand on your wallet and then run.

For more information on encryption and key management, download our white paper titled "AES Encryption and Related Concepts."

 

 

What is NIST?

The National Institute of Standards and Technology (NIST) is a US government agency that is a part of the Department of Commerce. The NIST sets non-military government standards for a wide variety of techn ologies including data encryption. Because the NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. The NIST is one of the most trusted sources for technology standards.

What is AES?

The Advanced Encryption Standard (AES) is the standard for data encryption adopted by the NIST in 2001. This encryption standard replaced the earlier Data Encryption Standard (DES). The DES encryption standard became weaker due to the advancing power of computer systems. The NIST began a process in the late 1990’s to find a replacement for DES. After a lengthy examination of several alternatives, the AES standard for encryption was adopted and codified as FIPS-197. AES encryption is now the de-facto standard for strong data encryption.

What is AES Validation Testing?

NIST sets the standard for AES encryption testing, and charters independent labs to administer and oversee the testing process. Through the National Voluntary Laboratory Accreditation Program (NVLAP) the NIST certifies independent testing labs for the Cryptographic Module Validation Program (CMVP). Data security software vendors administer the tests, validate the results, and submit the results to the NIST for acceptance. Software vendors work with an independent certification laboratory and not with the NIST directly.

The NIST established five methods, or modes, of encryption that can be used with AES. These are Electronic Code Book (ECB), Cipher Block Chaining (CBC), Counter (CTR), Output Feed Back (OFB), and Cipher Feed Back (CFB) modes. There are separate tests for each mode. A software vendor can choose to validate on only one mode, a subset of the five modes, or all modes of encryption. In addition, the NIST defines three key sizes for encryption: 128-bit, 192-bit, and 256-bit keys. A software vendor can choose from one to three key sizes to certify.

Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Alliance AES Encryption products are certified on ALL five modes of encryption, and all three key sizes.

Certification Means Strong Encryption

NIST certification is your assurance that a vendor’s AES encryption solution implements data encryption the right way. There are many ways to use encryption and a wide variety of modes of encryption. Improperly implemented solutions may work for one type of task, but fail under different application requirements. All software vendors claim they implement strong encryption. Can they prove it? Ask them for their NIST certification.

Certification Means Compatibility

One of the biggest challenges facing Enterprise customers is encrypting and decrypting data on a variety of platforms. Data may be encrypted in an Oracle database, then transferred to Microsoft SQL Server, then to an IBM i (AS/400) platform. Computer vendors use different methods of encryption, and different modes of encryption. How can you be sure that your encryption solution will be able to handle all of your requirements?

The NIST certification provides the assurance you need that your software is up to the task. Certified software must work the same way for all of the NIST defined encryption tasks.

The Alliance AES solutions provide even more assurance of compatibility – Alliance AES solutions are certified on all key sizes and all modes of encryption. No other data security vendor provides this level of certified support.

Alliance AES Encryption on Every Enterprise Platform

The modern Enterprise uses a wide variety of server platforms from a number of different vendors. In addition, data is exchanged with customers, vendors, and service provides outside the organization. To meet these challenges the Alliance AES Encryption products are certified and available on all Enterprise platforms including:

•  Microsoft Windows (2000/XP/2003)
•  Linux (SUSE and Red Hat, on Intel and POWER)
•  UNIX (AIX, Solaris)
•  IBM i (AS/400, iSeries)
•  IBM z (mainframe)

All of the certified Alliance AES encryption solutions work the same way on every platform.

Townsend Security is currently offering a free 30-day evaluation of the Alliance AES encryption solution for your platform.

As companies work to meet regulatory requirements to protect Personally Identifiable Information (PII), one option to minimize the risk of loss is to replace sensitive data with a non-sensitive replacement value, or “token.” 

Tokenization is the process of replacing sensitive information, such as a credit card or social security number, with a non-sensitive replacement value. The original value may be stored locally in a protected data warehouse, stored at a remote service provider, or not stored at all.  The goal of tokenization is to reduce or eliminate the risk of loss of sensitive data, and to avoid the expensive process of notification, loss re-imbursement, and legal action.

There are three primary approaches to tokenization:
    •  Tokens are recoverable and stored by external
       service providers
    •  Tokens are recoverable and stored locally
    •  Tokens are not recoverable

The first method of tokenization uses external storage of recoverable tokens and is implemented by a small number of credit card authorization networks.

The second approach to tokenization involves the creation and storage of the token on local IT servers. The token is protected by encryption and can be recovered by decryption when it is needed.

The third type of tokenization involves the creation of a token on local IT servers, but does not allow for the recovery of the original value.

If you do not need to store sensitive data in your database systems, tokenization can greatly reduce your risk of data loss. The original sensitive data can still be used to query a database or locate information in a business application. But by not storing the sensitive data, you will not be at risk of losing it.

It is important to note that if you use recoverable tokens you will still have the risk of data loss and will not be protected from any liability for a loss. You will also still be subject to all of the regulations  for protecting sensitive information.

Tokenization can be a powerful way to minimize risk in your development, QA, and UAT environments. When moving data to these environments you should always eliminate sensitive data to prevent its loss. Tokenization is an excellent way to do this.

Lastly, if you are a payment systems vendor you may wish to provide tokenization as a value added service to your merchant customers. Not only will you be helping them minimize their exposure to data loss, this can also be marketed as a competitive advantage for your business.

If you would like to learn more about tokenization, we recently presented a webinar titled "Tokenization & Compliance: 5 Ways to Reduce Costs and Increase Security."