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