When encrypting data, the most widely accepted cryptographic standard is the Advanced Encryption Standard (AES).

AES is defined by the National Institute of Standards and Technology (NIST) in the FIPS-197 standards document. AES supports nine modes of encryption, each of them having been extensively tested and vetted for security, recovery, and durability. When compliance regulations make reference to “industry standard encryption”, they are referring to the encryption modes identified in the NIST documents on AES.

Other modes used in AES are not NIST certified and are not even certifiable. Some products offer only the CUSP mode of encryption, which is not NIST certified and not certifiable. CUSP mode encryption is only implemented on IBM i and IBM z platforms and is not interoperable with other encryption modes. The CUSP mode of encryption has not been proposed or adopted as a NIST standard, and has not been generally reviewed or accepted by the professional security community.

Modes of encryption are recommended by NIST after they have been extensively reviewed by the professional cryptographic community. This is an international group of cryptographers whose long experience and analytic work are important to the vetting of proposed modes of encryption. In some cases it takes years of work before a mode is approved by NIST; many mode submissions are never approved for use.

There are several potential problems related to the use of the CUSP mode of AES encryption.

The CUSP mode of encryption is not included in the NIST list of recommended modes, and has not been submitted to NIST for consideration. It is therefore not a part of the NIST standards, or of any other generally accepted body of standards, and has not been formally reviewed by the cryptographic community. Therefore, the use of CUSP mode would be outside the scope of most data security regulations.

Further, there is no NIST certification protocol for the CUSP mode of encryption. It is not possible to claim that an encryption product using CUSP has been certified by NIST, or that it is in anyway compliant with the NIST standard.

Organizations contemplating the CUSP mode of encryption should be aware that their data protection mechanism could fail to provide “safe harbor” from breach notification requirements, and may not limit their legal liability in the event of a data loss.

The solution?  Most software vendors choose to certify just one or two modes of encryption, and on one key size. The Townsend Security Alliance AES Encryption products are NIST-certified on the five commonly used modes for data encryption, and all three key sizes for all major Enterprise platforms (Windows, Linux, UNIX, IBM i, and IBM z).  Townend Security Alliance AES Encryption is certified, compatibile, and complete.

Download a free 30-day evaluation of our Alliance AES Encryption now.

I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.

A while back, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.

As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.

This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.

First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.

Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.

The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.

To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.

I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.

For more information, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and encryption key management work together to secure your data.

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.

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

Case Study

A large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.

The Importance of NIST Certification for AES Encryption

Download a Free Trial Now

All Encryption is Not Created Equal

The National Institute of Standards and Technology (NIST) defines the standard for AES encryption, and provides a rigorous testing process for software vendors. The certification process is carried out by independent testing labs who report the results to NIST for validation.  The AES certification process tests every aspect of encryption and involves millions of encryption and decryption operations. Only the most dedicated security vendors are able to pass the tests and achieve NIST certification.  Townsend Security has achieved AES Validation for all key sizes and modes of operation, on every major Enterprise platform. 

How important is NIST validation?

Steve Tenore, a Senior IBM i Consultant for Staples, says "Staples wouldn’t even consider a vendor solution that didn’t have NIST certification. The fact that Townsend Security has NIST certified solutions on the major Enterprise server platform was a big plus."

Need encryption done right?  Insist on NIST.

In a study of the certification program, NIST found nearly 50 percent of software vendors had errors in their encryption solutions. It isn’t easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do. Every time.

Certification Means Stronger 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 Reliability

The NIST testing process is designed to exercise a vendor’s encryption solution under stress conditions. Large numbers of repeated encryptions are performed with the output of one encryption used as input for the next encryption. Failures in memory management or reliability will be exposed in the testing process. Encryption software may work without errors for 100 or 1,000 encryptions, but will it work on 1 million encryptions? How about 100 million encryptions?

No one wants the unpleasant experience of a system failure due to unreliable software. NIST certification helps provide some assurance of a reliable implementation. 

Download a free trial of our AES Encryption (available for IBM i, IBM z, Windows, Linux, and UNIX) and be guaranteed that you are using the most secure and best performing encryption available.

5 Commonly Asked Questions About Data Privacy

The job to protect sensitive data often falls in the hands of IT security administrators and their teams because of their technical expertise. We feel data protection is everyone's responsibility because every employee has an invested interest in maintaining their organization's good reputation with customers and partners.

We have compiled questions from discussions over the years with  customers and prospects to help people understand the basics of data privacy and why responsibility of maintaining data integrity goes beyond the IT department.  In addition to this list, we have produced a podcast with more information - download it here.

1. What constitutes personal information that we have to protect and how do businesses protect this information?

The first things people think of are credit card or social security numbers.  However, other pieces of information are equally as important.  Think about the things your bank asks you when you call them to talk about your account. Can you verify your phone number? The last four digits of your social security number? Your birthdate? Maiden name? These pieces of information can be used to commit fraud. 

The banks are using that information to identify you. And the fraudsters will use that information to impersonate you. The technical term for this kind of information is Personally Identifiable Information, or PII.

Businesses can protect data with a few different techniques involving third-party software solutions and implementing internal policies around who has access to data.

Vendor solutions can provide the ability to control who has access to data inside the company and prevent potential hackers from gaining access to your network.   Companies can also use vendor solutions to encrypt their data. Encryption is a process that takes sensitive information and runs it through a scrambling process. Once encrypted, your data can only be deciphered with a special key.  The data is useless to the person that attempts to steal it, unless they they have the key.

2. We’ve been hearing a lot about encryption and key management. How do they relate to each other?

They go together, they are complementary technologies. In addition to the raw credit card number, another very important input to the encryption is the secret key.  Without the key, no one can read the encrypted data. Many people think that an encryption algorithm itself is a secret mechanism, but that’s not the case. Encryption is well understood, there are standards for it and they’re readily available.  The secret that prevents malicious users from stealing data is the encryption key.

At home, the key to your front door is what protects you. Companies that use encryption have to create a key that is unique and strong, and then protect it to ensure it doesn’t get into the wild. Anyone who has the key can get the data. In the real world of protecting data with encryption, the encryption key is what users are taking care to protect.

3. What happens when the encryption is not done correctly?

There are many ways that encryption can be done incorrectly or poorly. We see that particularly around the area of encryption key management. One big mistake many people make is storing an encryption key on the same platform where the data are stored. Sometimes you hear the term integrated key management to describe this practice. Even if you lock down the database, keeping it on the same partition as your data leaves it readily accessible for potential cracking.

Other examples are using nonstandard or proprietary encryption. It’s important that a company buying encryption technology should vet their vendors carefully. NIST certified encryption is the best assurance that a solution meets your compliance requirements.

4. Are there any laws or regulations requiring businesses to protect their sensitive data?

Yes, there are quite a few, and many companies find themselves complying with multiple regulations. If you take credit cards, you fall under the Payment Card Industry standard. That’s a private regulation promoted by the credit card vendors such as Visa and Mastercard. If you’re a bank or engaged in the banking industry, you fall under Gramm-Leach-Bliley Act and FFIEC regulation for protecting data. In the health care industry, you fall under the HIPAA/HITECH acts.  FIRPA is the regulatory environment around educational institutions.

Individual states have passed data privacy regulations and defined data breaches and the penalties for them. And the federal government is moving laws through Congress to define protections for personal information. There are quite a number of regulations that define data that needs to be protected.

5. How would my organization develop a data security policy?

It’s a real challenge especially if you’re starting for the first time, it’s easy to feel overwhelmed when hearing about data breaches on a daily basis. Keep it simple to start. There are some things you can do that are very effective up front.  Rank where the vulnerabilities are. Here are just a few to help get you started:

1. Make sure you have good antivirus software on Windows and Mac.
2. Use good strong passwords. “1234” or “admin” are not good passwords!
3. Understand where your data resides and who has access to it.

Here’s another interesting thing, if you have a problem, it’s going to be your problem, not the vendor’s problem. It’s going to be your headache, your upset customers, and your financial loss. So pay attention to your encryption solution! 

Something that inhibits people from taking action is just thinking they are not subject to a data breach.  That’s a dangerous attitude. We've been saying it for years beause it's true - Data Gets Out. Encrypt it! 

Download the complete podcast here.

The modern Enterprise deploys a variety of server platforms, operating systems, and programming languages.  A major barrier to deploying encryption has been the challenge of accessing encryption keys from these widely divergent environments.  Encryption key management solutions have the primary goal of managing and protecting encryption keys, and making them available to authorized applications in a secure fashion.

Key management solutions vary greatly in the complexity of the key retrieval process. The more complex the key retrieval interface, the greater the challenge for the Enterprise IT team in deploying key retrieval in applications. Understanding this fact can help IT decision makers assess different vendor solutions and the likely costs of deploying a solution in their enterprise.  Below is a list of questions that you should ask your key management vendor when assessing their solution.

Key Management Vendor Checklist

1.  Is your key manager FIPS 140 certified?  What is the certificate number?

2.  How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?

3.  Is there a common key retrieval application interface on all platforms?  What are the differences?

4.  What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)

5.  Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)

6.  Do you supply binary libraries for all Enterprise servers?

7.  Do you have a Java key retrieval class and examples? Is it standard Java or JNI?

8.  Do you charge separate license fees for each client operating system?

9.  Do you require that we purchase consulting services from you?  Why?

10.  I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?
 
Once you have the answer to the above questions, it should be easier to choose the right key management vendor for your Enterprise. If you have any questions, click here and we will call you right back.

 

In our encryption practice we often help customers integrate the exchange of encrypted data between different applications within the organization, and between their own applications and a vendor’s or customer’s application. It is truly amazing to me how often we encounter non-standard encryption that makes this integration very difficult. The problem is not the lack of standards for encryption. Most compliance regulations provide clear guidance and references to encryption standards. Here is what the PCI Data Security Standard (PCI DSS) Navigation Guide says about encryption (my emphasis):

The intent of strong cryptography (see definition and key lengths in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "home-grown" algorithm).

Strong Encryption:
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

The problem seems to be a general lack of knowledge about encryption. And this applies to some vendors of encryption solutions. Here are a couple of examples:

One of our customers was having trouble decrypting a field with our software that was encrypted on a Windows server with “256-bit AES using CBC mode”. That seemed to be a pretty straight-forward task. Yet we couldn’t get the data decrypted properly. The output just looked like garbage. We spent a fair about of time with the customer verifying that they had the right decryption key, that the initialization vectors for the decryption were specified correctly, and that our software was being used correctly. But nothing was working. We then asked the third party software vendor to share their AES source code with us.  In this case the vendor was very accommodating and let us review their source code implementation of AES encryption.

Voila! The source code showed that the implementation was using a 256-bit block size for the encryption algorithm. The AES standard (FIPS-197) requires the use of 128-bit block sizes. The use of the larger block size meant that this was not even AES encryption according to the industry standard. The vendor fixed their implementation and the project was successful. But our customer spent a lot of time and money resolving the problem.

Another example of getting into trouble occurred with a customer who deployed an AES encryption solution that used the CUSP mode of encryption. This rang alarm bells right away.  We knew that CUSP was not one of the NIST approved modes of encryption, and we had never encountered it before. We quickly learned that CUSP stood for “Cryptographic Unit Service Provider” and was implemented by IBM in a couple of their server products. This customer had a couple of problems. CUSP mode was not a standard mode of encryption, and data encrypted with CUSP was not going to be decrypted by any of the standard open source or commercial products in the market. So this customer was locked into an incompatible encryption strategy.

The second problem is that the CUSP mode of encryption is a proprietary protocol.  The PCI DSS clearly states that strong encryption must be based on industry standards and not proprietary protocols (see above).  As I interpret the PCI DDS requirements for encryption, a customer using CUSP mode would be out of compliance. That’s going to hurt the next time a QSA takes a hard look at your encryption implementation.  We recently published a white paper on the weaknesses of the CUSP mode of encryption.  Click here to download it.

One way to insure that your AES encryption software is compliant is to look for a NIST certification. A NIST AES Validation certificate, or a NIST FIPS-140 certificate, is pretty good assurance of compliance. The FIPS-140 certification process requires AES Validation, so that certification is incorporated by reference. That’s why either certification will give you the assurance that AES encryption is being done according to the standard. Lacking certification, you are relying on the promises of a vendor or developer who may be ignorant, or have a motivation to be less than forthcoming. Not a good situation to find yourself in.

Both of these customers spent a fair amount of money fixing the problem.  An entirely avoidable expense.

Patrick

The advent of faster and faster computers poses a never ending challenge for encryption methodologies. An excellent example of this is the demise of the DES encryption standard in 1999.  That was when a group of programmers was able to break the security of a DES key in about 22 hours using a brute force attack which simply tried every possible value of the key. Computers have gotten a lot faster since then! This exploit lead to the adoption of AES as the new standard for symmetric encryption.

This year marks another milestone regarding the use of RSA keys. These are the public-private key pairs that are used in the creation of the SSL/TLS connections that enable ecommerce to transactions to run over the Internet (for example when you engage in electronic banking or give a credit card number to an on-line merchant).

In the past the use of RSA keys with a length of 1024-bits was quite common. However, the official policy has changed. NIST (the National Institute for Standards in Technology) now recommends that 2048-bit keys be used to encrypt data through 2030. After that time 3072-bit keys will be required.

This is documented in NIST Special Publication 800-57, Recommendation for Key Management. See “Table 4: Recommended algorithms and minimum key sizes” for particulars.

Compliance regulations are moving inexorably towards requiring the protection of sensitive data. The private information of customers, employees, patients, vendors and all of the people we come into contact with as Enterprises, must be protected from loss and misuse. At the same time that regulations are getting more teeth, there is more consensus about the technologies to protect data in our applications and databases. Encryption and tokenization are now the accepted methods of protecting data, and encryption key management is central to both technologies.

How fast are regulations changing? Really fast. The Payment Card Industry Security Standards Council will update the PCI Data Security Standard (PCI DSS) this year, and will be on a three year cycle of updates. Merchants accepting credit cards will have about 18 months to implement the changes. State privacy laws are undergoing frequent changes, most of which make the rules more stringent. Minnesota, Nevada, and Washington State have made recent changes. The HITECH Act of 2009 and related guidance further tightens the rules around protecting patient data, and further guidance is expected this year. Last, but not least, the federal government is moving new legislation through Congress to enact a national privacy law.

These changes are coming fast, and they have one thing in common: data protection requirements are getting stronger, not weaker. Companies and organizations should be paying attention to their data protection strategies now in order to avoid expensive rip-and-tear operations in the future.

One other tendency of the evolving regulations is this: A clear reference to standards for data protection. All of the mentioned standards now make reference to widely accepts standards, usually those of the National Institute of Standards and Technology (NIST) which publishes standards and testing protocols for encryption and key management. Over the last two years PCI (and related guidance from Visa), the HITECH Act, state privacy laws, and other regulations have specifically referenced NIST for data encryption and key management standards.

Companies and organizations acquiring data protection technologies should look carefully at how solutions match up to the standards. And a word of warning here: There is still a lot of snake oil in the data protection industry. Be sure that your data protection vendor can prove that their solutions actually meet the NIST standards. This is actually not hard to independently verify – NIST publishes on-line lists of vendors who certify their solutions to the standard.

Encryption is a well defined technology to protect data through the use of an encryption algorithm and secret key. When combined with proper key management, encryption provides a well accepted method of protecting sensitive data. There is a long history of work by professional cryptographers and NIST on defining how good encryption and key management should work, and you can easily determine which vendors meet the standard through the certification process.

Tokenization is a new technology and lacks the history and standards of encryption, but which incorporates encryption technologies. Tokenization works by substituting a surrogate value (or “token”) for the original data. By itself the token does not tell you anything about the original value which might be a credit card number, patient ID, and so forth. But tokenization requires that you use good encryption practices to protect the sensitive data in the token database. This means you have to use a tokenization solution that meets the same stringent standards for encryption and key management. When acquiring a tokenization solution, you will want to use the same diligence about encryption and key management that you would use for a pure encryption solution – that is, the solution should be built to standards and the vendor should be able to prove it through the NIST certification process.

Remember, a tokenization solution will be IN SCOPE for a PCI audit!

Tokenization standards are still evolving. Bob Russo of the PCI Security Standards Council indicated that the council will be taking up work on this in 2010. Visa just released a best practices guide for tokenization (you can get it here), and you can probably expect the eventual standards to incorporate much of this guidance. Additionally, the X9 organization is also working on standards for tokenization.

In regards to tokenization standards, stay tuned ! Much more is coming our way.

Encryption, tokenization, and key management – this is the trifecta for protecting data at rest. I’ll have more comments in the future about tokenization as we analyze the best practice guidance from Visa and help you connect the dots with our encryption, tokenization, and key management solutions.

Patrick