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)?
 |
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.
