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."

With the growing demand for regulatory compliance and concern for data privacy, organizations are taking advantage of encryption as a way to provide a "defense in depth" solution.  This approach is often impractical using only database encryption management tools alone.  Townsend Security has addressed this with their Alliance Key Manager Hardware Security Module (HSM).  Alliance Key Manager is a FIPS 140-2 certified solution that stores encryption keys on a hardware appliance.  This is a more secure approach and better meets compliance requirements because encryption keys do not reside with the encrypted data.

So what does an organization need to look for when selecting an encryption key management HSM?

1) Cost Effective
Cost should not be a barrier to compliance.  Townsend Security's encryption key management HSM is an affordable solution that can scale from small and medium sized organizations to the largest Enterprise.

2) Meet Compliance Requirements
Compliance regulations require encryption keys to be stored separately from the encrypted data to meet Separation of Duties and Dual Control best practices.  It is important to enforce separation of duties if you are trying to meet PCI-DSS.  This means preventing administrators from having access to both the encrypted data and the encryption keys.

3) Invest in a FIPS 140-Certified Solution
This gives you assurance that your encryption key management solution is certified to the highest standard for regulatory compliance.

4) Easy Integration
It is important that your encryption key management solution connects effortlessly to your applications and databases.

5) Automated Key Management Process
Your organization can save time and money when addressing compliance requirements by choosing an encryption key management HSM that automates all of your essential key management tasks - including rotation, retrieval, and generation - from one server or man, in a central location.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.

 

Encryption and tokenization are the two leading technologies used to protect sensitive data from loss and subsequent breach notification and legal liability. Organizations who try to meet compliance regulations struggle to understand when to use strong encryption and when to use tokenization to protect information. Many organizations will find both technologies helpful in different places in their IT infrastructure.

Encryption protects data by obscuring it with the use of an approved encryption algorithm such as AES and a secret key. Once encrypted, the original value can only be recovered if you have the secret key. The use of strong encryption keys makes it impossible, from a practical point of view, to guess the key and recover the data. Almost all compliance regulations provide a safe harbor from breach notification if sensitive data is encrypted.

Encryption - Protecting Sensitive Data Where It Lives

Encryption is a mature technology with a recognized body of standards, independent certification of vendor technologies, and it undergoes continual scrutiny by the professional cryptographic community. Organizations that deploy professional encryption solutions that have been independently certified (NIST certification) enjoy a high level of confidence in the protection of their data assets.

Tokenization - Protecting Sensitive Data with Subsitution

Tokenization works by substituting a surrogate value for the original sensitive data. This surrogate value is called a “token”. The token value does not contain sensitive information, it replaces it, maintaining the original value.  There is one and only one token value for any given original value. For example, a credit card number 4111-1111-1111-1111 might be assigned the token value of 1823-5877-9043-1002. Once this token is assigned it will always be used when the original value would have been used.

Combining Encryption and Tokenization

For most organizations there will be appropriate uses for both encryption and tokenization. Encryption will be the right solution for one set of applications and databases, and tokenization will be the right solution for others.  The appropriate technology will be decided by each organization’s technical, compliance, and end-user staff working together.

In order to ease the development and compliance burden, organizations may wish to source encryption and tokenization solutions from the same vendor. There are many overlapping technologies in both encryption and tokenization, and you will probably want a common approach to both.

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." 

Pretty Good Privacy (PGP) is the de facto standard for encrypted file exchange among the world’s largest financial, medical, industrial, and services companies. Based on open standards and tested by time, PGP has won the trust of governments and private enterprises to protect their sensitive data.  Here are the six key things to know about PGP encryption for your IBM i and IBM z platforms, and how to discuss them with your technology providers:

1) Always encrypt and decrypt sensitive data on the platform where it is created. This is the only way to satisfy regulatory audit and privacy notification requirements.

Moving data to a PC for encryption and decryption tasks greatly increases the chances of loss and puts your most sensitive data at risk.  In order not to defeat your data security goals it is important to encrypt and decrypt data directly on the IBM i or IBM z.

2) The best PGP encryption solutions manage PGP keys directly on the IBM i or IBM z without the need for an external PC system, or key generation on a PC.

Using a PC to generate or manage PGP keys exposes the keys on the most vulnerable system. The loss of PGP keys may trigger expensive and time-consuming privacy notification requirements and force the change of PGP keys with all of your trading partners.

3) The best data security solutions will provide you with IBM i and IBM z automation tools that help minimize additional programming and meet your integration requirements.

Most Enterprise customers find that the cost of the software for an encryption solution is small compared to the cost of integrating the solution into their business applications. Data must be extracted from business applications, encrypted using PGP, transmitted to a trading partner, archived for future access, and tracked for regulatory audit. When receiving an encrypted file from a trading partner the file must be decrypted, transferred to an IBM i or IBM z library, and processed into the business application. All of these operations have to be automated to avoid expensive and time-consuming manual intervention.

4) PGP is part of a comprehensive data security plan.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

5) PGP helps meet data privacy compliance regulations.

Even if your company is not directly subject to PCI and other similar regulations, you will soon find that your customers who are subject to these laws will require that you be in compliance, too. As the financial auditing profession matures, auditors realize that their customers cannot meet regulatory requirements unless their suppliers meet these requirements.

6) Choose the trusted leader in data security.

When PGP Corporation selected a partner to bring PGP version 9 to the IBM i, POWER Linux, and IBM System z platforms, they selected Townsend Security as their exclusive partner. PGP Corporation’s knowledge of Townsend’s history with PGP on the IBM i and IBM z platforms made Townsend Security the natural choice.

Click the button below to download a free trial of PGP for the IBM i or IBM z from Townsend Security.

Emerging Data Privacy Regulations

Organizations need to comply with an increasing number of data privacy regulations.  In addition to regulations such as PCI, HIPAA/HITECH, GLBA/FFIEC, and Sarbanes-Oxley, states are passing their own privacy laws.  For example, Massachusetts says that if you are doing business with anyone in their state, you must comply with their privacy law – even if your business is located across the country.  NIST-certified encryption and key management can help meet these emerging regulations.

I recently sat down with Patrick to discuss the emerging data privacy regulations - as well as how to meet them and what it is like to have an audit. 

There are lots of different data privacy regulations for people dealing with sensitive information.  Can you speak a little about each one?

You are right.  There are a lot of regulations and companies are finding themselves falling under more than just one.  Probably the one that most people know about is the PCI Data Security Standards (PCI DSS).  Any organization that accepts credit cards for payment falls under these regulations.  In the medical segment we have the HIPAA and HITECH Act, which sets the standards for protecting patient information.  In the banking and financial area we have the GLBA and FFIEC regulations which cover a broad set of financial institutions.  FERPA is for educational institutions.  Sarbanes-Oxley (SOX) covers any publicly traded company.  Finally, we have state privacy laws on the books and there are about 44 or 45 of them.  So you are right, there are a lot of different privacy regulations and there are over-lapping and different requirements for each regulation.

So, an organization can be faced with several different compliance regulations, is there any common solution?

You need to be aware of each one, though there are some overlapping definitions of what constitutes Personally Identifiable Information (PII).  It is important to follow proper encryption and key management best practices and make sure your solutions are NIST certified.  State Privacy Laws are starting to follow PCI guidance.  It is important to note that State Privacy Laws are now starting to extend beyond the boundaries of the state.

Do any of these regulations have any real “teeth”?

Oh, yes!  A data breach can have lasting financial and business impacts.  Just ask the companies who have had major data breaches.  One credible study by the Ponemon Institute estimates that TJ Maxx may eventually spend a total of about 9 billion dollars (yes, that’s billion with a “B”) as a result of their data breach.  There have been numerous fines levied against merchants, medical providers, and businesses related to data security breaches.  There are real financial penalties for these breaches.

Less well known is the fact that an embarrassing data security breach can sink your business.  If a big part of your business is based on Internet sales, for example, you can find your business disappearing in the event you have a data breach.

What is the process of undergoing an audit like?

Don’t panic.  It can be painful, but in most cases and audit involves a routine set of questions.  You can actually prepare for that experience.  It is good to know the configuration of your network and where things stand in terms of data protection.  Having good documentation on your policies, procedures, your network, and your business applications is going to be very helpful in an audit.  Also, you should see your auditor as an important partner in compliance.  A good relationship with an auditor will help get you through the process.  You can see your auditor as someone who can really advise you on best practices for securing data.

Also, your software supplier can be an important partner.  For example, we offer a lot of questions about compliance regulations and best practices when we work with our customers and prospective customers – trying to get them educated on what really is best practice.

Are there any emerging regulations that our listeners should be aware of?

Congress is working on a Federal Privacy law that would replace the 44 or 45 state privacy regulations. Businesses struggle to keep up with the differences between all of the state laws, and there is business support for passing a federal law. A version has passed the House of Representatives, and there are two or three versions pending in the Senate. These will have to get consolidated into a single law, and then rationalized with the House bill. But eventually I think this will happen.

I think we can make some predictions about how a new federal law will affect businesses. We already have a template in the HITECH Act of 2009. I suspect that the FTC or some other federal agency will be tasked with defining the data security regulations. It is highly likely that the National Institute of Standards and Technology (NIST) will be the basis for standards and certification of solutions. Then there will be published rules and guidelines on how to implement data protection.

If I am right about this, it will prompt businesses to be sure that their data protection solutions meet NIST standards. And I don’t mean sorta, kinda, maybe. You need to find solutions are NIST certified to FIPS-140-2 or similar standards with the paper certificates to prove it.

Download a 30-day evaluation of NIST-certified AES database encryption from Townsend Security

Last week we presented a webinar on PCI requirements for encryption key management.  Many of the people who attended were encrypting data on the System i and curious about how to manage their encryption keys according to new PCI requirements. 

The way organizations are managing encryption keys is falling under more scrutiny by QSA auditors.  Companies must demonstrate they are enforcing dual control and separation of duties.  

How is this achieved on the System i? Is it still effective to use an integrated key management solution that is store encryption keys in the same partition as the encrypted data?  The answer, quite simply,  is "no" PCI DSS requirement states the following requirements for key management:

 

• Dual Control means that at least two people should be required toauthenticate before performing critical key management tasks.
• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

Now here is an uncomfortable truth.  On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the System i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Let us know about the key management strategy at your company. Is your organization encrypting data on the System i?  How are you managing the encryption keys? If you store them on a separate partition, have you had a recent PCI audit?  What did your auditor say?

2014 UPDATE:
No Significant Changes around Key Management in PCI DSS v3.0

The new PCI Data Security Standards (PCI DSS v2.0) are here and I’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys.  The clear trend is to require that encryption keys be stored separately from the data they protect, and to make sure that the people who manage encryption keys are not the people who manage the protected data. Let’s look at why this is happening.

While most of the largest merchants in the Level 1 category are already using professional key management solutions to protect encryption keys, the trend over the last 12 months is to require smaller merchants in the Level 2 and Level 3 categories to also use better key management practices, too. So, what are the parts of PCI DSS that are driving this change?  It all has to do with industry best practices for encryption key management, and the concepts of Dual Control, Separation of Duties, and Split Knowledge. These best practices and concepts work together to form the basis for determining if your approach to key management will pass muster.

First, what is the source of industry best practices for key management? Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the concepts in PCI DSS 2.0 Section 3.

Next, it is important to understand Dual Control, Separation of Duties, and Split Knowledge. These are all clearly defined in the PCI DSS standard and in the accompanying PCI DSS glossary. I’ve extracted the exact definitions below, but I’ll recap them here from the point of view of key management.

Dual Control means that no one person should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.

Separation of Duties means that different people should control different aspects of your key management strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.

Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

What are the practical implications of these best practices and core concepts?  One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System I (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM System i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this level of authority!

That’s why storing encryption keys on the same system where the protected data resides violates all of the core principles of data protection, and that’s why we are seeing auditors and payment networks reject this approach. If you haven’t faced this issue yet, your day is probably coming. Now is the time to start planning on how to deal with the problem.

Over two years ago we saw this trend developing and took action to help merchants be prepared for proper key management. We created the Alliance Key Manager solution and released it to our partner channel in 2009. This year we released it for direct sale, and last week we received our FIPS-140-2 certification from NIST. Over 1,000 customers are now using AKM to protect their encryption keys with a solution that provably meets industry standards.  Our encryption products have been updated to use this new key management solution, and we are moving customers forward to compliance. It’s been a long, hard slog to NIST FIPS-140 certification, but I think our customers will benefit from the effort.

I hope this has been helpful in clarifying key management best practices. For more information on PCI and key management, download our podcast titled "Key Management Best Practices: What New PCI Regulations Say." Please let us know if you have any questions.

---

From the PCI DSS version 2.0 Glossary:

Dual control
“Process of using two or more separate entities (usually persons) operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of materials involved in vulnerable transactions. No single person is permitted to access or use the materials (for example, the cryptographic key). For manual key generation, conveyance, loading, storage, and retrieval, dual control requires dividing knowledge of the key among the entities. (See also Split Knowledge).”

Separation of Duties
“Practice of dividing steps in a function among different individuals, so as to keep a single individual from being able to subvert the process.”

Split knowledge
“Condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptographic key.”

Source documents are available online at www.pcisecuritystandards.org