From the PASS Summit to the Worldwide User Group (SSWUG)

From Developers to Database Administrators, we have met another amazing group of people at the PASS Summit 2014. Over 5,000 members of the Professional Association for SQL Server converged on Seattle, WA and we got to talk about security with people from all over North America and from as far away as Norway, Spain, Australia, Colombia, Germany, and even Iceland.

We spent most of our time talking about the importance of encrypting sensitive data, and about using an encryption key management solution to protect encryption keys away from the database. There is a huge need to meet compliance regulations, and with all the options now available (Hardware appliance, Cloud HSM, VMware virtual environment, and cloud instances in AWS or Azure) there is a solution for each scenario we encountered.

If you are working with SQL Server, we hope you are familiar with the SQL Server Worldwide User Group (SSWUG).  If you don’t know about them, please allow me a moment to introduce you to Stephen Wynkoop who is the founder and editor for SSWUG.org. This website is a wealth of information about everything you would want to know about SQL Server (and they are even branching out to other database systems like Oracle and IBM DB2). The emphasis at SSWUG has been on SQL Server and you will find a large number of articles, blogs, videos and other content on wide variety of topics related to it. Stephen features weekly video programs about the database and IT world, webcasts, articles, online virtual community events and virtual conferences several times a year. He is a Microsoft SQL Server MVP and the author of more than 10 books, translated into at least 7 languages. Stephen has been working with SQL Server since the very first version, with a prior experience in database platforms that included dBase and Btrieve.

SSWUG has dedicated a section of their web site to the SSWUGtv Security Edition “Townsend Security Series” where they present videos of Stephen and our own industry expert, Patrick Townsend, discussing security topics ranging from securing data with encryption and key management on SQL Server (not just with EKM) to protecting data in the cloud. Additionally, they post a new security segment just about every week on their homepage, so there is always something fresh. A few of the sessions include topics such as What top industries do Hackers focus on and why? and Cross-platform security: How do you have a hybrid environment and keep it secure?  

Check out this one on: PCI Compliance and Security in the Cloud - (11 minutes) 

Stephen and Patrick have a great time recording these videos, and if you haven’t seen any yet, I urge you to check them out. In addition to all the great content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.

You are also invited to download this latest white paper, authored by Stephen Wynkoop, on understanding options and responsibilities for managing encryption in the Microsoft Azure Cloud.

Encrypting data in Microsoft SQL Server is easy to do, yet often difficult to understand because of the different encryption options offered in various versions.

It used to be said that “encryption is the hardest part of data security, and key management is the hardest part of encryption”. While that may have been true a few years ago, we are constantly working to make affordable, easy-to-use, defensible solutions that meet security best practices and industry compliance regulations. Separating and managing the encryption keys from the data they protect is still one of the biggest challenges in terms of doing an encryption project right, so let’s take a look at what encryption & key management options are available for SQL Server users.

If you are running the Enterprise Edition of SQL Server, version 2008 or newer, you have access to Microsoft’s architecture for encryption called Extensible Key Management (EKM). This provider interface allows for third-party key management systems to be easily incorporated in order to separate encryption keys from the encrypted data they protect. A key management solution should provide Windows client libraries, guidance, and sample code within the solution.

The SQL Server EKM architecture supports:

Transparent Data Encryption (TDE)
With TDE, the entire database table (including the logs you are collecting) is encrypted.  It is a very easy mechanism to use for encryption and since it is transparent, no application level changes are needed, it only takes a few commands to implement. TDE protects data at rest, including backups and log files.

Cell Level Encryption
Also known as column-level encryption, this allows for you to selectively encrypt certain columns of information in your database. This option makes sense if you have large databases of information, and only access encrypted columns periodically.

If you are running older versions of SQL Server (pre-2008), or using non-enterprise editions such as standard, web, or express; you do not have access to TDE or EKM. You still have good options for protecting your data with encryption, just remember the encryption key needs to be separated from the encrypted data it protects.

When you don’t have the EKM architecture, another option for encrypting data in your SQL Server database is to perform encryption and decryption at the application layer using .NET-based encryption. All editions of SQL Server support the ability to perform encryption from within the .NET framework with very straightforward code functions.

C# and VB.NET Application Encryption
If you are developing in .NET you only need to plug in the client side application and implement a few lines of code for your encryption and decryption calls.

Column Level Encryption
Another approach would be to combine User Described Functions (UDFs) with triggers and views to help automate the encryption and decryption at the column level.

Moving SQL Server Data to the Cloud

As more companies migrate their applications and data to the cloud, there are security issues to consider before making that move. Microsoft Azure SQL Database (MASD) -which has also been called SQL Azure, SQL Server Data Services, SQL Services, Windows Azure SQL Database- is a cloud-based service from Microsoft offering database capabilities as a part of the Azure Services Platform. The service is easy to use and readily available, just know that there are some constraints and some features of EKM that are not available when using MASD.  

Most businesses migrating to the cloud will choose to run virtual machines that contain the Windows OS and a full implementation of the SQL Server database. By using a virtual machine, encryption and key management, including EKM with TDE, can be fully supported and provide the level of security you expect and compliance regulations require!  

You have many options still available for your key management solution when your data has been moved to the cloud. Our NIST validated, FIPS 140-2 compliant Alliance Key Manager solutions are available as:

• Hardware Security Module (HSM) - a hardened appliance that you can rack up in your own data center
• Cloud HSM - dedicated hardware device in our hosted cloud environment
• VMware - deploy as a virtual appliance
• Cloud - deploy in Windows Azure, Amazon Web Services, or IBM Cloud as a standard cloud instance or virtual private cloud

To learn more about encrypting data on SQL Server, managing encryption keys, and how we are helping companies protect their data with Alliance Key Manager, download the podcast on Encryption Options on SQL Server.  

In Microsoft SQL Server 2008/2012 Enterprise edition users can enable Extensible Key Management (EKM) and use either TDE or cell level encryption to encrypt their sensitive data and to be selective about the data they encrypt.  EKM is an architecture that allows users to incorporate a third-party* encryption key management hardware security module (HSM) in order to truly secure their data using key management best practices and meet compliance regulations.

*Townsend Security is a Microsoft Silver partner and provider of encryption key management HSMs for Microsoft SQL Server, Microsoft SharePoint, Windows, and Microsoft Azure.

Users select from one of the two methods of SQL Server encryption available for the Microsoft SQL Server 2008/2012 Enterprise Edition and above:

1) Transparent Data Encryption (TDE): TDE encrypts the entire database and temporary files within that space with no additional programming.

On earlier versions of SQL Server deploying encryption had been a much larger and more complicated programming project.  With 2008/2012 Enterprise edition, TDE can be implemented fully without any programing at all. Once your administrator has DBA administrative rights, he or she can implement TDE through a straightforward process that requires no changes to coding, queries, or applications. TDE is a favored way to rapidly encrypt data and works well for small or medium sized databases because of its speed and ease of deployment.

2) Cell Level Encryption: Cell Level Encryption allows database administrators to select the columns they wish to encrypt in a database - a benefit for many administrators with larger databases; however, this process takes a little bit more effort to set up.

If you are leveraging EKM and using an external encryption key manager, the database administrator can encrypt data in the column (cell level) by adding a modifier on a particular fetch or update to the database. However, administrators will need to make small changes to their databases to enable their encryption key manager to do this. This is not a complicated step, however, and your encryption key management vendor should be able to help you through this. Cell level encryption works well for large databases where performance impacts must be kept to a minimum and only certain data needs to be encrypted.

Here is a very straightforward YouTube demonstration video where you can see just how easily TDE is set up.

Setting Up TDE & EKM on SQL Server 2008 / 2012 for Compliance

For a more in-depth look, we have compiled a selection of resources (webinar, white paper, podcast) that can provide additional information:

Almost every organization has at least one application built on Microsoft’s SQL Server database. Whether you build an application in-house using Microsoft’s development tools or you deploy a software package from a software vendor, chances are that your organizations has one or more SQL Server databases to help you manage information.

The Challenge: Protect Data with SQL Server’s Encryption

Today it is almost impossible to run a business without handling sensitive information and storing storing data such as customer names, credit card numbers, bank account numbers, passwords, email addresses, or other personally identifiable information (PII) or private health information (PHI) in your SQL Server database. If your organization must meet data security regulations such as PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, or GDPR, you probably already know that this data must be encrypted in order to protect your customers and prevent data loss in the event of a data breach.

What you may not know is that in order to truly protect your data, you must manage your encryption keys in adherence to key management best practices such as dual control and separation of duties using an external encryption key manager (key managers are available in VMware, Cloud, as a traditional hardware security module or HSM). Your company will only be able to avoid data breach notification if you are using these best practices.

The good news is that Microsoft SQL Server comes equipped with transparent data encryption (TDE) and extensible key management (EKM) to make encryption and key management using a third-party key manager easier than ever. Older versions of SQL Server can also be easily encrypted using different tactics, and you can manage those encryption keys just as easily with an encryption key manager as well.

Encrypting Data in SQL Server Depends on Your Version

If you’re currently looking into encrypting your SQL Server database or deploying a key management system, you may be concerned about how to protect your data depending on the version, code, and language used to build your database. To help ease your worries, here are 4 ways to encrypt your SQL Server database and protect your encryption keys:

1. Since SQL Server 2008 Enterprise and SQL Server 2019 Standard, Microsoft has supported automatic encryption with TDE and column-level encryption for Enterprise Edition users and above. Without any programming you can encrypt the SQL Server database or an individual column, and store the keys on an encryption key manager (commonly available as an HSM and in VMware or Cloud).
2. If you have an older version of SQL Server, or you have SQL Server Standard Edition or Web Edition, you don’t have access to TDE. But you can still automate encryption: Through the strategic use of SQL Views and Triggers, you can automate encryption of sensitive data on your SQL Server without extensive program modifications, and still use a secure key manager to protect the encryption keys.
3. Your developers might have written custom application code to implement your SQL Server database. But SQL Server encryption and key management is still within your reach. A good key management vendor should supply you with software libraries that easily add into your applications and implement SQL Server encryption.
4. You might have a SQL Server database, but not be using Microsoft programming languages. Perhaps your applications are written in Java, Perl, or PHP. Again, it is simple to deploy software libraries that encrypt the SQL Server data and which store the encryption keys on an external centralized key manager.

SQL Server encryption and good key management is not difficult to achieve. Although key management has a reputation for being difficult and costly, today key management for SQL Server is cost-effective, easy, has little to no performance impact, will get your company in compliance, and will keep your organization out of the headlines by helping to prevent a data breach.  Townsend Security's Alliance Key Manager is FIPS 140-2 compliant and in use by over 3,000 customers worldwide.

To learn more about key management for SQL Server, download the White Paper, “Encryption Key Management for Microsoft SQL Server.”

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick

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.