Townsend Security Data Privacy Blog

As we work with Microsoft customers who are implementing encryption with Extensible Key Management in SQL Server 2008 R2, the question inevitably arises about whether to use Transparent Data Encryption (TDE) or Cell Level Encryption.

As you might guess, this comes down to tradeoffs between ease of implementation, performance, and security.

Transparent Data Encryption (TDE) is very easy to implement. It doesn’t require any changes to your existing applications, and using TDE with Alliance Key Manager, our encryption key management solution,  is very straight-forward. It typically only takes a few minutes to get up and running with our encryption key manager and TDE. Cell level encryption, on the other hand, will take at least some changes to your SQL statements or .NET application code. These changes aren’t difficult at all, but you still need to make them. For some of our customers who don’t have the source code for the application, or who don’t have IT resources available, this can be a significant barrier. The good news is that the work to set up the Alliance Key Manager key server is the same for both Cell Level Encryption as for TDE. From an ease of implementation point of view, TDE is the easy winner.

The second difference between TDE and Cell Level Encryption is performance. You might think that Cell Level Encryption would perform better because there is actually less data being encrypted, but you would be wrong! TDE is the clear winner in the performance category. Microsoft estimates that there will be a 2% to 4% performance penalty with TDE. Our own tests using the publicly available SQL Stress tool (www.sqlstress.com) shows that for most databases the performance penalty is closer to the 2% value, and in some cases less than 2%. Cell Level Encryption almost always carries a bigger performance impact. So TDE is once again the winner in the performance category.

The security tradeoffs are more complex. As Microsoft has noted, TDE does not encrypt and decrypt in memory:

“Note that neither BitLocker nor TDE encrypt data in memory. This can provide a substantial performance benefit over the encryption offered in SQL Server 2005, including the use of indexed searches (discussed later). But this also means that a system administrator with access to this memory can read the unencrypted data. All users with database permissions to access data will see unencrypted data.”

Cell Level Encryption does do encryption and decryption in memory, and this provides an incremental improvement in security.  So Cell Level Encryption provides a slightly better security strategy. If you use TDE as your encryption strategy, you will want to be sure to use a number of other techniques to lock down your environment.  You can read more about this on the Microsoft MSDN web site here.

I think for most Microsoft customers the use of TDE will fit well with their tolerance for risk and their security strategy.  Whether you choose TDE or Cell Level Encryption, you end up with your data much better protected.

You need to combine encryption and good encryption key management with other steps to properly secure your Windows and SQL Server environment.  Encryption is not a magic bullet, but without it your data is exposed to loss.

For further information, download our white paper "Encryption Key Management for Microsoft SQL Server 2008" and learn about meeting encryption and key management challenges on your Microsoft SQL Server.

Microsoft defines an interface for external key management systems with their SQL Server Extensible Key Management (EKM) architecture, but does not define how encryption key management vendors should communicate between the Windows server and the encryption key manager. This is important because the communications over the TCP network must be secure, and access to the client side certificate credentials also has to be secure.

Our Alliance Key Manager uses the Transport Layer Security (TLS) communications protocol to provide for secure and authenticated connections between the Windows server running SQL Server, and the encryption key manager. TLS is the de facto standard for protecting communications between a client application and a server. Our SQL Server EKM provider software uses mutually authenticated TLS connections to ensure that all information exchanged between SQL Server EKM and the key manager is protected.

But how do you protect the client side X509 certificates and private keys needed for TLS security?

The best way to do this on a Windows platform is to leverage Microsoft’s certificate manager and certificate store. When you use this native Windows facility you also get a lot of native Microsoft security for certificates and private keys. For example, you can restrict access to the private key used for TLS communications to a small, defined set of users. You don’t need to rely on file permissions to implement this level of protection, and you can leverage Windows event management to report unauthorized access attempts.

The Alliance Key Manager EKM Provider for SQL Server fully integrates with Windows certificate management and .NET TLS services when establishing a TLS connection. This provides the most secure implementation for managing certificates and private keys for TLS negotiation.

For more information view our webinar "Encryption Key Management with Microsoft SQL Server."  We think this webinar is informative and shows just how easy it is to implement encryption key management on your SQL server.

Microsoft’s Worldwide Partner Conference just wrapped up and it was truly an International conference. There were partners from every corner of the world. Microsoft has invested a lot in this conference and they are doing a great job of helping companies meet new partners through the on-line WPC Connections web site.

It is clear to me that Microsoft is converging a wide range of products onto the SQL Server platform for data management. The many business applications under the Microsoft Dynamics label including Dynamics NAV (the ERP system), Dynamics CRM (customer relationship management), and Dynamics AX (global ERP management) are all based on the latest version of SQL Server.  The very popular SharePoint collaboration tool now fully supports and exposes SQL Server Enterprise edition. All of the Business Intelligence solutions have been based on SQL Server for some time. And this pattern repeats through other products.

Why is this important? In SQL Server 2008 Microsoft introduced a new database security architecture with Extensible Key Management (EKM). EKM enables database encryption and the use of Hardware Security Modules (HSM) to store and manage encryption keys. Encryption and good key management are crucial to regulatory compliance, and the EKM architecture makes this all possible. The EKM architecture extends forward to the new version of SQL Server code named Denali.

You will be hearing more from Townsend Security about Microsoft SQL Server encryption key management next month.

The Cloud is the other big topic at this conference. Microsoft is moving almost everything to the Cloud at full speed. Microsoft Dynamics, SharePoint, SQL Server, and many other products are getting Cloud-based versions. Microsoft may be a bit late to the game on the Cloud, but they are “all in” now. And they’ve made a lot of room for partners to play in this arena, too. There are a really large number of new and existing Cloud providers at WPC.

Of course, the biggest concern on the part of end customers is the security of the Cloud. After many discussions with Microsoft partners, I know that they have heard this concern. But there is still quite a bit of confusion and ignorance about how to mitigate risk in Cloud environments. I can see we have our work cut out for us in helping to educate the Microsoft partner community about how they can use our solutions to encrypt and protect customer data. It won’t be as hard, painful, and expensive as they think.

Be sure to follow us on Facebook, Twitter, and LinkedIn to hear more about what we are doing with Key Management for SQL Server 2008 and  stay up to date on the latest trends in data protection.

Patrick

Townsend Security is heading to LA in July to attend Microsoft’s Worldwide Partner Conference (WPC).   Our attendance at the conference will support the release of a new security appliance (coming later this summer) that seamlessly integrates with Microsoft SQL Server 2008 R2 to manage encryption keys.

While at WPC we will meet with Microsoft Business Partners who focus on selling and supporting Microsoft SQL Server to discuss an exciting revenue generating opportunity. We will introduce the companies to our Microsoft Business Partner Program and show how our new security appliance will help boost new sales and upgrades to SQL Server 2008 R2 and enable Microsoft Business Partners to help their customers comply with PCI-DSS, HIPAA/HITECH and other regulations.

Companies of all sizes feel the increasing pressure to comply with data security requirements and protect sensitive customer information.  We have listened to small and mid-size companies and heard from Microsoft that the biggest challenge these companies face is access to a cost-effective comprehensive solution. 

In August, we will release a hardware security module (HSM) that will enable Microsoft Business Partners to provide their mid-market SQL Server 2008 R2 customers with an external key management appliance that is cost-effective and comprehensive.  The HSM easily integrates with SQL Server 2008 R2 and leverages existing data protection functionality, transparent data encryption (TDE) and extensible key management (EKM).

We want to talk to partners who serve the SQL Server mid-market, so let us know if you are attending WPC this year and would like to schedule a meeting to discuss this opportunity.  If you aren’t going to be at the conference and this sounds like a business objective for your organization, let us know and we will arrange a time to discuss the opportunity in more detail.

Click here to learn more and contact us.

As we’ve developed more solutions for the Microsoft Windows platform I’ve come to appreciate the rich set of programming languages that Microsoft provides to developers, and the deep support they provide to both beginner and advanced programmers.  There is a large group of experts inside of Microsoft and in the outside developer community that generously supports Windows developers. Whether you develop in .NET, or C#, no one has done better than Microsoft and generating and supporting this developer community. At a recent SQL PASS conference I saw T-Shirts with the slogan:

    “2.7 Million Geeks Can’t Be Wrong”
    
What’s surprising about that 2.7 million number is that it is not surprising. There may actually be that many Microsoft developers out there.

Encryption and key management have become big challenges for Microsoft developers as various compliance regulations mature and require separation of encryption keys from the data they protect (see my previous blogs on this issue).  In the past a Microsoft developer might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach can’t meet the requirements for Dual Control, Separation of Duties, and Split Knowledge required by good security practice and compliance regulations such as PCI DSS. These .NET, and C# developers are now changing their encryption strategy to incorporate external key managers into their applications.

That’s where a Microsoft developer often encounters some friction. Key management vendors are generally not responsive to the needs of a Microsoft developer and fail to provide interfaces that work naturally in this environment. Complex DLL implementations that require special .NET wrapper code, poor integration with the existing .NET encryption APIs, and the absence of quality sample code makes life difficult for the Microsoft developer. And this means that application development slows down and gets more expensive. That’s bad news in a Windows developer world.

I think we’ve done a lot of things right for Microsoft developers with our Alliance Key Manager solution. We provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages. We also provide for key retrieval directly into .NET applications so that developers can use the native .NET encryption libraries. By not forcing server-based encryption or the use of special encryption libraries, the developer can decide for themselves the best approach to encryption once they have an encryption key retrieved to their application. This approach also supports Microsoft’s Managed Code architecture.

Developers also need some good example code to help speed development. So we’ve provided that with our Alliance Key Manager solution. You can install a working .NET GUI application that retrieves encryption keys from the server, and the install includes the Visual Studio project and source code.  And there are C# examples if you develop in that Microsoft language.

The last thing we’ve done to support the Microsoft Windows platform is integrate our encryption key retrieval routines with the Windows certificate store and native Windows communications facility. When a Windows application authenticates to the Alliance Key Manager server the certificates used for the secure TLS connection are under Windows security and control. And the TLS communications is done with native Windows communications APIs. This reduces the chance of loss of certificates and private keys, supports the MMC management of certificates, and integrates with Microsoft’s patch update strategy. That is just one less component to worry about.

The combination of an affordable FIPS-140-2 compliant key management solution with deep support for the Microsoft developer makes our Alliance Key Manager a great option for Windows users who need to meet security best practices and compliance regulations for key management.

You can get more information about Alliance Key Manager here.

And more information about support for the Microsoft .NET environment here.

Happy programming!

Patrick