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

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.

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.

 

The new PCI Data Security Standards (PCI DSS v2.0) are here and we’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. I recently sat down with Patrick Townsend, Founder & CTO of Townsend Security, to discuss the new PCI regulations in regards to encryption key management.  To hear an expanded podcast of our conversation, click here.

 

What is the source of industry best practices for key management?

 

The NIST special publication SP-800-57 provides specific pointers on 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.

Also, key management solutions are certified to the FIPS-140-2 standard for cryptographic modules. So FIPS-140 is a source of best practices and standards.

 

Dual control, separation of duties, and split knowledge have been buzz topics in the key management world lately.  What do they mean?

 

Well, dual control means that at least two people should be required to authenticate 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.

 

Split knowledge is defined in the PCI DSS version 2.0 glossary as a “condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptography key.”

 

Are there any standards or best practices regarding “integrated key management?”

 

“Integrated key management” is a term of art, and not a standard.  If “integrated key management” means “we store our encryption keys on the server where the data is,” then that is a bad thing, from a compliance and security point of view. 

 

So, what are the best practices for encryption key management?

 

First you should follow the key life-cycle and be able to document it.  You should always separate the keys from the data.  If you follow the PCI guidelines, you are in excellent shape.  Finally, I would recommend only using a FIPS 140 certified key management solution.

 

What are the practical implications of these best practices and core concepts such as “dual control” and “separation of duties?”

 

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 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 high level of authority! You just can’t meet PCI and other industry standards for proper key management by storing the encryption keys on the same platform as the data you are trying to protect.

 

To download an expanded podcast of our conversation, click here.

 

As compliance regulations start mandating encryption and key management, we are seeing more and more companies stepping up their data security policies.  One important thing to realize is, that just because you are implementing encryption, it doesn’t necessarily mean that you are doing it correctly and will meet regulations such as PCI DSS, HIPAA/HITECH, State Privacy Laws, etc.

We have compiled a list of the top ten encryption pitfalls that your enterprise needs to be aware of.

 

1) Encryption Key Management

Encryption requires a proper key management strategy. This means protecting and isolating encryption keys from the data that they protect. For most companies this means using a proper key management solution across all of their servers and applications.  Townsend Security offers Alliance Key Manager to help meet key management and compliance regulations.

 

2) Completeness and Compatibility

It’s not uncommon for some encryption solutions to only implement a partial specification of AES encryption. There are nine encryption modes (five for business data) that can be used with AES encryption. An incomplete solution that encrypts with one mode — such as CBC — will leave you unable to decrypt with another mode like ECB. This incompatibility makes transferring encrypted data from one server to another difficult or impossible.  Townsend Security’s Alliance AES Encryption is NIST-certified on all five modes for business data.

 

3) NIST Certification

As regulators refine the requirements for encryption and key management, the certification of products to NIST standards is more important. The recent 2009 HITECH Act makes specific reference to the NIST standards for encryption and key management. Many vendors of encryption solutions ignore NIST certification leaving their customers exposed to these evolving regulations.

 

4) Performance

The impact of encryption on servers and applications is often an unpleasant surprise as companies implement their data security plans. There are large differences in the performance of vendor solutions. The performance impact of encryption can delay or derail data security efforts.

 

5) Application Modifications

Implementing encryption at the database level often involves some application redesign and modification. This requires work by companies and their vendors. This work is often unplanned and unbudgeted, causing financial and human resource problems.  It is important to make sure your application modifications are minimal.

 

6) Quality Assurance and UAT Testing

When applications and databases are modified to implement encryption, there is a need to re-certify them for accuracy, reliability and performance. Many companies find this effort larger than the effort to implement encryption.

 

7) Data Leakage to QA and Test Environments

Every company that maintains business applications must keep a set of data available to the developer and user acceptance teams so that changes can be adequately tested. Often the data used in these test environments contains sensitive information. Good practice requires proper protection of this information using encryption, masking, or tokenization.

 

8) System and Compliance Logging

A common question asked by auditors is “How do you know who decrypted a credit card number?” Unless your encryption solution has integrated compliance logging, you may not know who is viewing sensitive data in your database systems. Compliance logging is often overlooked by vendors of encryption systems, leaving companies perplexed in the event of a data loss.  Townsend Security offers Alliance LogAgent for the IBM i or Syslog-ng as both an application or appliance.

 

9) Key Access Controls

Encryption and key management access controls are essential to an encryption strategy. Can you specify who has access to the HR encryption key for payroll processing? The ability to restrict the use of encryption to specific users and groups is an essential security control.

 

10) Virtual and Cloud Platforms

Encryption and Key Management in VM and Cloud environments pose special challenges. The PCI SSC virtualization group indicates that security concerns are much higher in these environments.  Currently there is no standard for implementing key management in the cloud environment.

In conclusion, there are many factors involved when choosing the right encryption and key management solution for your enterprise.  Additionally, once chosen, it is also important to make sure that it is implemented correctly.  For more reading on encryption and PCI, we have written a white paper titled Encryption Key Management Requirements for PCI.

As day three of the RSA Conference 2011 begins, it marks the half-way point through the largest data security tradeshow that the industry has to offer. Walking into the show you would be hard pressed to tell whether you walked into a security show or a grown up play-yard. Look to left you see sumo wrestlers, looking ahead there are unicycles weaving the crowd, and to the right are pirates handing out candy. And to top it all off, each night ends with beer, wine, and appetizers for all attendees. Who wouldn’t want to attend the RSA Conference 2011??!!

As you look past all the gimmicks, the technology is still really what matters.

A noticeable change over the past two years is the increased awareness of FIPS-140 certification for key managers.

We believe this is largely driven by compliance auditors whose demands have evolved from "you must encrypt" to "you can't store your keys with your data" to "you need to use a key manager" and are now converging on "you need a FIPS-140 certified key manager."

As the auditing community matures we expect the requirements for formal government certifications to move from occasional to manditory.

In the past we usually only heard these concerns from sophisticated security architects with very large companies. Now we are seeing this awareness beginning to move through the SMB marketplace.

Prospective partners, future clients and current customers recognize that Townsend Security has done encryption and key management the way that it needs to be done – and proven by NIST and FIPS certifications. If your encryption offering hasn’t been reviewed and certified by NIST, you have no assurance that you aren’t implementing a less than secure product. “I wouldn’t consider an encryption solution that isn’t certified by NIST” is a common statement by attendees at our booth.

Would you like to see first hand how certified encryption and key management will work at your organization? Click on the links to request evaluation versions of AES encryption and Key Manager. One of our security specialists will be in contact with you to make sure you are up and running and answer any questions that you might have.

Or, if you just would like to learn more about encryption and key management, visit the resources section of our web site.

And if you read this while you are still at the RSA Conference 2011, stop by our booth and pick up a little somethin’ special that we have been saving you.