Any way you look at it, 2011 was a very bad year for database security. From the high-profile (and highly embarrassing) series of attacks on Sony's PlayStation Network, to the less-publicized Epsilon breach which was described by the Privacy Clearinghouse as the worst data breach in history, there was a huge upswing in attacks targeting private user data. In fact, according to a recent Verizon PCI Compliance Report (PCIR), "about 42 percent of organizations have trouble implementing a proper encryption key management strategy to keep information safe."

In short, hacking has become a goldmine for criminals looking to steal and exploit personal information, and you need to be doing everything you can to avoid being their next victim. For database administrators, this means making sure your encryption keys are as secure as possible.

Key Management in SQL Server 2008/2012

In previous years, encryption security was difficult because the keys were almost always stored locally on the same computer as the data. However, with the SQL Server 2008/2012 Enterprise Edition encryption key management became much more robust thanks to the introduction of Extensible Key Management (EKM).

EKM works alongside the Microsoft Cryptographic API to create a system where SQL server key management is significantly more secure. They can now easily be stored in an external Hardware Security Modules (HSM) that store the encryption keys securely, away from the data they protect. This makes it far more difficult for hackers to gain access to your secure private information.

The Advantages of a Hardware Security Module (HSM)

Alliance Key Manager, Townsend Security's encryption key management HSM provides a number of significant benefits for secure encryption key management.

• Direct Integration With SQL 2008/2012: SQL Server 2008/2012 natively supports HSMs, requiring only a small tweak to the configuration files to enable their usage and disable local key storage.
• True Key Security: With TDE, the key to your encryption never actually leaves the HSM. It cannot be captured through packet-sniffing or at the end user's machine.
• Robust Standards Compliance: A properly-configured HSM setup gives you robust compliance with most of the major public and private security standards, including PCI DSS, HIPAA, SOX, and the Gramm-Leach-Bliley Act.
• End User Simplicity with TDE: EKM also allows for Transparent Data Encryption (TDE), meaning that it's invisible to the end user. Your employees can continue to use their applications as they normally did, with the Hardware Security Module being queried as necessary, behind the scenes.
• Cell Level Encryption: Through EKM, each individual column of cells can be encrypted separately, making large-scale data breaches far more difficult to pull off.
• Easy Implementation: Once the hardware is installed, the key management software only needs to be installed on your server machine. End user access to it is managed through software licenses rather than requiring time-consuming individual installations.

A Smart Choice for Server Security

While encryption and key management are not the only elements necessary for robust data security, they are a major component of it. By implementing a HSM, your business can quickly and easily give its security a shot in the arm, telling your customers and investors that you're serious about protecting private personal information on your servers.

Don't let 2011 be a sign of things to come; take steps now to make 2012 the year of data protection.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

As a company that provides NIST-certified encryption and FIPS 140-2 encryption key management, we need to secure data on a number of different platforms. Lately we have been coming into several cases where a customer needs encryption and key management on both Microsoft SQL Server and Oracle databases. Below is an email exchange with a customer who came to us “looking for a product to store, generate and manage keys that we use to encrypt/decrypt credit card information inside both SQL Server and Oracle Databases on Windows and UNIX.” We hope this discussion helps with your encryption project.

Customers Environment:

1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.

2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).

3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table.  It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number.  So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.

Questions Addressed:

Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.

SQL Server:

Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.

The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.

Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.

Oracle:

Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.

Key Generation:

Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.

Encryption on HSM:

Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.

We hope that this case study can help you with your encryption project.  Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.

In our final installment of questions from “Encryption Key Management with Microsoft SQL Server 2008” we tackle the topics of encryption key management in High Availability (HA) and disaster recover scenarios.  If you missed the first two blogs in the series, you can always go back and read about “The Performance Impacts of TDE on Microsoft SQL Server” and “How often do I need to rotate encryption keys on my SQL Server?”  If you still have any questions about encryption or encryption key management on your Microsoft SQL Server, feel free to send them our way.  It is always a pleasure to hear from members of the data privacy community.  Here is the last question in this series:

Can you speak to how encryption key management works in High Availability (HA) and disaster recovery scenarios?

An encryption key management solution becomes a part of your critical infrastructure if you are properly protecting keys.  If your key manager goes down, your applications stop functioning until you have key management back up.  We really address those concerns in a number of ways.  One way is that our key manager is built for redundancy.  We know it is hardware, and if it is hardware it can fail, so we implement a hardware platform that is resilient and has a lot of redundancy built in.  The first layer of keeping an encryption key manager up and running consistently is to have a good hardware platform.

Secondly, we build real-time mirroring of keys and policy around keys directly into the product.  You can actually deploy a high-availability failover key server with all key activity and access controls mirrored in real-time to a fail-over key server.  If you use SQL Server, you can define right in our software one or more fail-over servers.  For example, in SQL Server, through the configuration panels you can define multiple key servers for fail-over.  If you have a failed server, a hardware problem, or network outage, you can actually define fail-over servers and that will take place in real time.

Furthermore, there is a lot of resilience in the EKM provider software that we install on the Windows server so that if there is a software failure, there are some self-healing mechanisms there too.  If our module were to be killed off by the security administrator, it will get re-started automatically.  So there are a lot of redundancy and self-healing components built in to both the software and configuration components on the key server.

We have done a lot to help customers deal with the concern about resilience of a key manager because it is critical infrastructure, and we fully support that through real-time mirroring.  It is not an operating system feature.  The key server itself has implemented this mirroring capability.  It is itself self-healing.  So if two key servers are mirroring to each other and the network goes down, they will queue up those mirroring transactions, and when the network comes back, it will re-commit those changes.  Alliance Key Manager is a robust facility for making sure you have good backups of your encryption keys.

This concludes our series of questions from the recent webinar “Encryption Key Management with Microsoft SQL Server 2008.”  We encourage you to view the webcast and learn even more about how easily and affordably you can begin meeting data privacy compliance requirements with encryption and encryption key management.

Last week we began a series of blogs with questions from our recent webinar titled “Encryption Key Management with Microsoft SQL Server 2008”.  If you missed part one, you can view it now.  We talked about the performance impacts of TDE (Transparent Data Encryption) on Microsoft SQL Server 2008.  This time we will talk about how often you need to rotate your encryption keys on your SQL Server and whether your database gets locked during Cell Level or Column Level encryption during the re-encryption process.  Additionally, we will touch on how we can help users that have both Microsoft SQL and Oracle environments.  Without further delay, here are the questions:

How often do keys need to be changed?  During Cell Level or Column Level encryption, will the database be locked during the re-encryption process? 

With Cell Level encryption you can roll keys without bringing down your database.  When you establish a symmetric key in Alliance Key Manager, our encryption key management appliance, you can establish how frequently you want that key to be rolled over, rotated, or changed (which all mean generate a new key) for use by the database.  Alliance Key Manager implements support for both automated and manual key rollover, and if you are using Cell Level encryption in Microsoft SQL Server, you can take advantage of that.  The broader question about how often you should change keys in your database is a really interesting one.  There is no simple answer to that.  If you are familiar with PCI DSS you know that particular question got a little more complicated in version 2.0.  Basically, you have to establish a crypto-period for your keys.  I think NIST would say two years is probably the maximum for the usage period of a key.  Five years on the outside for a key to be used, even for the decryption of previously protected data.  The bottom line is you have to establish a crypto-period for your keys and then implement that as policy.  We support that process by letting you define how frequently keys should be changed and then managing that process for you automatically.

With TDE, the answer is a little bit different.  TDE requires some manual steps to roll keys, but we fully support multiple keys and rolling keys with our encryption key management appliance. 

Does your Alliance Key Manager Enterprise Edition serve keys to Oracle databases as well?

Yes.  We provide encryption keys across a wide set of databases, applications, and servers.  We have customers today who are protecting Oracle databases using our Alliance Key Manager to store encryption keys.  We provide sample code that shows how to do that - same thing with MySQL, DB2 from IBM, and almost every standard database that you might run into.  We also make it easy for customers who are using a variety of development languages to implement encryption. 

If you are using SQL Server EKM, you really get a big win because it doesn’t take any programming at all to implement TDE.  So that is the “easy button” in terms of encryption.  Additionally, if you have written applications in Java that use SQL Server, Oracle, or MySQL, we provide Java examples - full applications in fact - on how to use them.  If you programmed in C#,  VBNET, Perl, Python, or PHP, we have sample code that really helps customers get up and running very quickly with our key management solution.

Stay tuned for our next post on encryption key management in High Availability (HA) and disaster recovery scenarios.  In the meantime, you can view a recording of “Encryption Key Management with Microsoft SQL Server 2008”

Townsend Security hosts a monthly webinar on a wide variety of topics ranging from encryption and key management best practices to what’s new with compliance regulations such as PCI DSS.  If you haven’t had a chance to attend any of our webinars yet, sign up for our newsletter and we’ll make sure you know what is coming up next.

During our recent packed webinar, “Encryption Key Management with Microsoft SQL Server” we were asked some great questions from the audience and would like to share them with you on our blog.  Upcoming questions include “How often do I need to rotate encryption keys on my SQL Server?” and “How does encryption key management work in High Availability (HA) and disaster recovery scenarios?”

Here is part one in our series of questions from this webinar.  As always, if you still have any questions, send them our way and we will promptly get back to you.

What are the performance impacts of TDE encryption on Microsoft SQL Server?

Encryption really has a reputation for being CPU intensive.  There is good news on this front for Microsoft customers because I think the people in the SQL Server group did a really great job at performance tuning data encryption within the SQL Server environment.  If you look at what Microsoft says about turning on TDE (Transparent Data Encryption), they say you will pay a 2-4% performance penalty when encryption is enabled.  That is actually very excellent performance.  In our experience, it is actually closer to 2%.  More complex environments may get a little higher than that.

Microsoft will tell you that there is a little more performance penalty around Cell Level or Column Level encryption.  I think that is probably true too, but still I think they have done a great job of making a good solution that performs quite well.

Stay tuned for our next post on “How often do I need to rotate encryption keys on my SQL Server?” and “During Cell Level or Column Level encryption, will the database be locked during the re-encryption process?”  In the meantime, view a recording of “Encryption Key Management with Microsoft SQL Server”.

As we wrap up our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, finishes the conversation by speaking on special requirements for an encryption key management HSM and how Townsend Security can help organizations running SQL Server 2008 with their encryption project.  If you are jumping in to the series right now, you can read part one and part two for the earlier parts of our conversation.  Here is the final part of our discussion:

Download Podcast Now

Are there any special requirements for an HSM?

HSMs are very specialized devices.  It takes a certain type of development approach to create systems that protect encryption keys.  There are well-defined processes by which encryption keys should be created, managed, stored, and protected by other encryption keys.  All of that is a very special security practice by vendors who create HSM solutions.  It is a very highly specialized practice.  Even the way you build and program for an HSM is quite different than you would build or develop a standard business application.  So, first off, there are really best practices on how HSMs get developed. 

Secondly, there are standards for HSM devices.  The National Institute of Standards and Technology, or NIST, produces a FIPS 140-2 certification and specification for cryptographic modules.  Vendors of HSM solutions can have their products certified to the FIPS 140-2 standard.  Any serious vendor will undergo FIPS 140-2 certification.  It is a requirement by the US government and any federal agency that is protecting encryption keys must use a FIPS 140-2 certified solution.  In private industry, it is a well-recognized standard.  I can tell you from personal experience that it is a very tough process.  There is a lot of scrutiny over how you have implemented key management, and as a result, only the best vendors attain a FIPS 140-2 certification.  We are proud to have achieved this status with our encryption key management appliance.

How does Townsend Security help organizations running SQL Server 2008 with their encryption project?

First, we do have an encryption key management appliance called Alliance Key Manager.  It is designed to be the Fort Knox for encryption keys.  It helps our customers meet encryption best practices with an HSM solution.  It carries the FIPS 140-2 certification that customers demand.

Secondly, it connects very easily to Microsoft SQL Server 2008 – including the upcoming SQL Server 2012 which was code named Denali.  It is easy to deploy and SQL Server customers will find it very straightforward to install.  It understands EKM configurations and automatically mirrors them and backs them up in a High-Availability (HA) environment.  All of that is done through very straight-forward GUI applications. 

Additionally, our encryption key management solution provably meets industry standards, is easy to deploy, and cost-effective.  We are really trying to help the Microsoft mid-market customer who may have one or two SQL Servers get into an HSM solution that really will fit their budget.  Our cost-effectiveness is one of the things we are bringing to the market that is brand new.  We look at key management HSMs as something that every organization should be able to deploy to protect their data. 

Finally, we do a lot to automate the entire key management process.  Keys can be generated and then automatically rolled to meet compliance regulations.  These components are core to our strategy of making encryption key management and the deployment of HSMs with the Microsoft EKM environment a straightforward and reasonable thing to do.  It really will help a whole range of customers meet encryption key management best practices quickly and with an affordable solution.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

As our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, resumes the conversation by speaking on who would need to use Extensible Key Management (EKM) and what part a Hardware Security Module (HSM) plays in this environment.  If you are jumping in to the series right now, can read “Encryption and Key Management on Microsoft SQL Server 2008- Part 1” by clicking on the link.  Here is part two of our conversation:

Who would need to use Extensible Key Management (EKM)? 

Download Podcast Now

Almost anyone who stores sensitive data in a SQL Server database should be considering encrypting that data to prevent its loss.  We are all familiar with the data breaches.  Some of them have been very well publicized – Sony and Citigroup, etc.  Losses happen to large and small companies alike, and it is quite damaging financially and to the reputation of a company to have a loss.  Anyone who is storing sensitive data in a database should be considering using EKM to protect that data.  If you are in a retail environment and are taking credit cards, you fall under PCI DSS rules and should be encrypting that database.  If you are in the medical segment you fall under HIPAA and HITECH Act rules.  Patient information that is stored on your SQL Server should be encrypted.  Finally, anybody who falls under a state privacy law – which is almost everyone – and are storing Personally Identifiable Information or PII, such as social security numbers, drivers license numbers, military IDs, etc. could benefit from using TDE and EKM.

So, any company who falls under compliance regulations and needs to protect sensitive information from loss and wants to minimize their risk should be using Encryption Key Management (EKM).  Microsoft, through their EKM architecture, makes it really easy to accomplish, it is relatively inexpensive and is very cheap insurance to help protect your data against loss.

What part does a Hardware Security Module (HSM) play in this environment?

HSMs are the Fort Knox for encryption keys.  Good security practice across all regulations requires that you take extra steps to protect your encryption keys.  The real secret that you are trying to protect is the key that you have used to encrypt that data.  Protecting encryption keys is the biggest challenge and most important part of an encryption strategy, and that is exactly what an HSM does.  HSMs create keys, protect them from loss, manage them through their lifecycle, and deliver them to applications that need them, such as EKM in the SQL Server environment.  HSMs are a very crucial part of your encryption strategy and that is why Microsoft and security professionals recommend using an HSM.

In the compliance arena, if you are undergoing PCI DSS assessment, there is not an explicit requirement for an HSM, but there are explicit requirements for “Separation of Duties” and “Dual Control” as applied encryption key management.  When you begin to look at requirements to achieve “Dual Control” and “Separation of Duties” you quickly come to the realization that you HAVE to separate the encryption keys into a separate environment and that is exactly what our encryption key management appliance does.  So to effectively meet security and compliance requirements you need to deploy an HSM to protect encryption keys.  It is a fundamental core principle in an encryption strategy.  Trying to bypass that by the local storage of keys, or storing them in the clear on another server, will not meet compliance regulations nor meet security best practices.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

I was recently able to sit down with Patrick Townsend, our Founder and CTO, to discuss Microsoft SQL Server 2008 and what Microsoft customers should be thinking about when using Transparent Data Encryption (TDE) and Extensible Key Management (EKM).  Additionally, we talked about the role of an encryption key management appliance in regards to meeting compliance regulations such as PCI DSS, HIPAA/HITECH, etc. and what to look for when selecting one for your organization.  Here are a few questions from our conversation:

What is Extensible Key Management (EKM) on Microsoft SQL Server 2008?

Download Podcast Now

Microsoft introduced a new architecture for database encryption with SQL Server 2008.  It was a new architecture and a new way of approaching integrated database encryption. SQL Server 2008 had the first implementation of Extensible Key Management (EKM), and it is implemented in SQL Server 2008 R2, and the just announced SQL Server 2012. 

The real significant part of this is that Microsoft understood that there was a need for a new architecture for encryption, that it had to be standardized, and that it had to integrate third-party Hardware Security Modules (HSM) for encryption key management and protection.  So that is what EKM is.  It really has two primary components.  The first one is Transparent Data Encryption (TDE) and the second component is Cell Level Encryption. 

So, TDE is a brand new type of implementation under EKM.  TDE automatically encrypts the entire table space in a SQL Server database and it doesn’t require any application modifications.  It is a really great and easy way to implement encryption in your database.  Cell Level Encryption or Column Level Encryption is the second component.  It gives you the ability to pick a particular column in a SQL Server database and encrypt that column.  Cell Level Encryption does require modifications to your SQL applications, so it has a little more of an impact from the point of view that it takes a developers time to implement it.

Both TDE and Cell Level Encryption, under EKM, give you the ability to plug in a Hardware Security Module (HSM) to protect the encryption keys.  Microsoft also recognized very clearly that proper encryption of a database requires protection of the encryption keys in an appliance or HSM. 

Now that we know what EKM is, how does it work? 

It is a facility within SQL Server 2008, Enterprise Edition and above.  It isn’t activated until you explicitly activate it.  When you decide that you want to place your database under encryption control you go into the standard database administrators console for managing SQL Server and you define that you want to implement encryption through an EKM provider and specify how you want to manage your encryption keys.  You then place the database under encryption control.  It is really a simple process for implementing TDE.  In fact, we recently created a video titled “Setting Up TDE & EKM on SQL Server 2008” showing how easy it is.

Cell Level Encryption requires a couple extra steps to modify your SQL code, but the basic architecture is pretty simple.  Once you decide how you want to do it, you create encryption keys and you turn on EKM through an EKM provider.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.