+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

SQL Server TDE vs Cell-Level Encryption: A Brief Comparison

Posted by Ken Mafli on May 31, 2017 2:21:18 PM

In 2008, Microsoft introduced Transparent Data Encryption (TDE) to its Enterprise and Datacenter Editions of SQL Server. Billed as a way to seamlessly deploy SQL Server encryption, users now had the choice of full database-level encryption, instead of just the previous choices of cell-level encryption (CLE), Encrypting File System (EFS), or Bitlocker. With its rapid deployment, ease-of-use, and enhanced security TDE has been a staple for every version of SQL Server Enterprise Edition (and Developer Edition) ever since.

Versions of SQL Server Enterprise with TDE:
2008, 2008 R2, 2012, 2014, 2016

Encryption & Key Management for SQL Server - Definitive GuideTDE has become a favorite for bulk encryption in meeting regulatory compliance (like PCI DSS) or internal corporate data security initiatives. But while TDE has it’s advantages, it is not a cure-all. Sung Hsueh did a great job explaining the advantages and disadvantages of TDE as compared to CLE. The following is a curated look at that whitepaper. Let’s take a quick look:

What is Transparent Data Encryption?

TDE fundamentally is full database-level encryption. It functions at the Input/Output (I/O) level. Any data written into the database is automatically encrypted. Backups are also automatically encrypted. Data in use is decrypted by TDE as they are read by a user or application and stored, in clear text, in memory. Since the data-in-flight is decrypted; TLS or SSH (or now, “Always Encrypted”) should be enabled to protect the data while in motion.

What is Cell-Level Encryption?

Introduced in 2005, CLE is implemented as a series of built-ins. It is a manual process “that requires a re-architecture of the application to call the encryption and decryption functions.” Hsueh also notes that “the traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques [of TDE] can be used.” 

CLE vs. TDE

The advantages of CLE:
  • Since it is column level encryption, it encrypts only the sensitive information in a table.
  • With CLE, the data is still encrypted even when it is loaded into memory.
    CLE allows for “explicit key management” giving you greater control over the keys and who has access to them.
  • CLE is highly configurable, giving you a high degree of customization (especially when your applications require it).
  • Queries may be faster with CLE if the encrypted column(s) is not referenced in the query. TDE will always decrypt the entire row in the table. CLE will decrypt the column value only IF it is a part of the data that is returned. So in some cases CLE implementations provide much better overall performance.

The disadvantages of CLE:

  • One of the main disadvantages of CLE is the high degree of fully manual application changes needed to use it. TDE, on the other hand, can be very simple to deploy with no changes to the database, tables or columns required.
  • CLE can also have high performance penalties if search queries cannot be optimized to avoid encrypted data. “As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse [than TDE].”

The whitepaper goes on to note that with CLE performance impacts “are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted.” TDE, on the other hand, only had a 3-5% average performance impact compared to a non-encrypted database.

Final Thoughts

A case could be made for using CLE in conjunction with TDE as a defense-in-depth strategy. By selectively encrypting columns with CLE, encrypting the full database with TDE, and then managing the separate keys with a centralized key manager; it would ensure that crucial data was protected, even while loaded into memory.

But, in general, TDE and CLE are used for different purposes. If you are looking to encrypt a small amount of data, if your application “has custom design requirements,” or if performance is not a much of a concern, CLE may have advantages over TDE. But, if performance is a concern or you would like to avoid manually implementing encryption (normally a time-consuming process) then TDE is the way to go.

For more information on both types of encryption and how they relate to Extensible Key Management, visit our Definitive Guide to SQL Server Encryption & Key Management.

Encryption

Topics: SQL Server, Cell Level Encryption, Transparent Data Encryption (TDE), SQL Server encryption

SQL Server Column Level Encryption

Posted by Patrick Townsend on Feb 28, 2017 9:11:00 AM

Microsoft customers attempting to meet security best practices, compliance regulations, and protection of organization’s digital assets turn to encryption of sensitive data in Microsoft SQL Server databases. The easiest way to encrypt data in SQL Server is through Transparent Data Encryption (TDE) which is a supported feature in SQL Server Enterprise Edition. For a variety of reasons, TDE may not be the optimal solution. Microsoft customers using SQL Server Standard, Web, and Express Editions do not have access to the TDE feature. And even when using SQL Server Enterprise Edition, TDE may not be the best choice for very large databases.

Encryption & Key Management for SQL Server - Definitive GuideLet’s look at some approaches to column level encryption in SQL Server. The following discussion assumes that you want to meet encryption key management best practices by storing encryption keys away from the protected data, and retain full and exclusive control of your encryption keys.

Column Level Encryption (aka Cell Level Encryption) 
Starting with the release of SQL Server 2008, all Enterprise editions of the database have supported the Extensible Key Management (EKM) architecture. The EKM architecture allows for two encryption options: Transparent Data Encryption (TDE) and Column Level Encryption (CLE). Cell Level Encryption is the term Microsoft uses for column level encryption. SQL Server Enterprise edition customers automatically have access to column level encryption through the EKM architecture.

Encryption Key Management solution providers can support both TDE and Column Level Encryption through their EKM Provider software. However, not all key management providers support both - some only support TDE encryption. If your key management vendor supports Cell Level Encryption this provides a path to column level encryption in SQL Server Enterprise editions.

Application Layer Encryption
Another approach to column level encryption that works well for SQL Server Standard, Web, and Express editions is to implement encryption and decryption at the application layer. This means that your application performs encryption on a column’s content before inserting or updating the database, and performs decryption on a column’s content after reading a value from the database. Almost all modern application languages support the industry standard AES encryption algorithm. Implementing encryption in languages such as C#, Java, Perl, Python, and other programming languages is now efficient and relatively painless.

The challenge that developers face when implementing encryption at the application layer is the proper protection of encryption keys. Security best practices and compliance regulations require a high level of protection of encryption keys. This is best accomplished through the use of an encryption key management system specifically designed to create, securely store, and manage strong encryption keys. For developers, the primary challenge in a SQL Server encryption project is integrating the application with the key manager. Many vendors of key management systems make this easier by providing Software Development Kits (SDKs) and sample code to help the developer accomplish this task easily.

SQL Views and Triggers with User Defined Functions (UDFs)
Another approach to column level encryption involves the use of SQL Views and Triggers. Leveraging the use of User Defined Functions (UDFs) the database administrator and application developer can implement column level encryption by creating SQL Views over existing tables, then implementing SQL Triggers to invoke user defined functions that retrieve encryption keys and perform encryption and decryption tasks. This approach has the advantage of minimizing the amount of application programming that is required, but does require analysis of the SQL database and the use of User Defined Functions. Database administrators and application developers may be able to leverage the SDKs provided by an encryption key management solution to make this process easier.

SQL Server Always Encrypted
One promising new technology recently implemented by Microsoft is SQL Server Always Encrypted. This feature is new with SQL Server 2016 and can work with any edition of SQL Server. It is a client-side architecture which means that column data is encrypted before it is sent to the database, and decrypted after it is retrieved from the database. While there are many constraints in how you can put and get data from SQL Server, it is a promising new technology that will help some customers protect data at the column level. You can expect to see support for Always Encrypted being announced by encryption key management vendors in the near future.

SQL Server in the Azure Cloud
As Microsoft customers and ISVs move to the Azure cloud they are taking their SQL Server applications with them. And it is very common that they take full implementations of SQL Server into their Azure virtual cloud instances. When SQL Server applications run in a virtual machine in Azure they support the same options for column level encryption as described above. This includes support for Cell Level Encryption through the EKM Provider architecture as well as application layer encryption. As in traditional IT infrastructure the challenge of encryption key management follows you into the Azure cloud. Azure customers should look to their encryption key management vendors to provide guidance on support for their key management solution and SDKs in Azure. Not all key management solutions run in Azure and Azure is not a supported platform for all vendor SDKs.

Azure SQL Database
In the Azure cloud Microsoft offers the SQL Server database as a cloud service. That is, Microsoft hosts the SQL Server database in the cloud and your applications can use this service rather than a full instance of SQL Server in your cloud instance. Unfortunately, Azure SQL Database only supports Transparent Data Encryption through the EKM Provider interface and does not yet support Cell Level Encryption. It also restricts encryption key management to only the Azure Key Vault facility requiring you to share key custody with Microsoft.

Column level encryption at the application layer is fully supported for Azure SQL Database. As in the traditional IT infrastructure your C#, Java, and other applications can encrypt and decrypt sensitive data above the database level. Again, check with your key management solution provider to insure that application level SDKs are supported in the Azure cloud.

AWS Cloud and SQL Server
The Amazon Web Service (AWS) implementation of cloud workloads parallels that of Microsoft Azure. You can deploy a full instance of SQL Server in an AWS EC2 instance and use the features of SQL Server as in traditional IT infrastructure. Amazon also overs a database service called Amazon Relational Database Service, or RDS. The RDS service offers multiple relational databases including SQL Server. As with Azure there is no support for key management solutions other than the Amazon Key Management Service (KMS) requiring a shared implementation of key custody.

As you can see there are many ways to implement column level encryption in SQL Server and use good encryption key management practices. I hope this helps you on our journey to more secure data in SQL Server.

Patrick

Encryption

Topics: Encryption, SQL Server, Cell Level Encryption

Fixing the TDE Key Management Problem in Microsoft SQL Server

Posted by Patrick Townsend on Jan 10, 2017 7:31:56 AM

Many Microsoft SQL Server users have taken the first step to protect sensitive data such as Personally Identifiable Information (PII), Protected Health Information (PHI), Primary Account numbers (PAN) and Non-Public Information (NPI) by encrypting their databases with Transparent Data Encryption (TDE). It is extremely easy to implement TDE encryption as it does not require program changes.

White Paper: Key Management in a Multi-Platform EnvironmentA common cause of audit failures might not be so obvious and that is the failure to properly protect the SQL Server key encryption key once you activate encryption in SQL Server. With Transparent Data Encryption you have the choice of storing the service master key within the SQL Server context itself, or protecting the master key with a key management system using the SQL Server Extensible Key Management (EKM) interface. Why is it important to do this?

It turns out that it is easy for cyber criminals to recover the SQL Server master key when it is stored within SQL Server itself. (Examples: https://blog.netspi.com/decrypting-mssql-credential-passwords/ and http://simonmcauliffe.com/technology/tde/#hardware)

Simon McAuliffe provides the clearest explanation I’ve seen on the insecurity of locally stored TDE keys in SQL Server. I don’t agree with him on the question of using a key manager to improve security. Given that there is no perfect security, I believe that you can get significant security advantages through a properly implemented key management interface.

If your TDE keys are stored locally, don’t panic. It turns out to be very easy to migrate to a key management solution. Assuming you’ve installed our SQL Server EKM Provider called Key Connection on your SQL Server instance, here are the steps to migrate your Service Master Key to key management protection using our Alliance Key Manager solution. You don’t even need to bring down SQL server to do this (from the Alliance Key Manager Key Connection manual):

Protecting an existing TDE key with Alliance Key Manager

First create a new asymmetric key pair within the AKM Administrative Console using the “Create EKM Key” and the “Enable Key for EKM” commands.

Then return to SQL Server and call the following command to create the asymmetric key alias for the new KEK that you created on the AKM server:

use master;

create asymmetric key my_new_kek from provider KeyConnection with provider_key_name = ’NEW_TDE_KEK’, creation_disposition = open_existing;

In this example, NEW_TDE_KEK is the name of the new key on AKM, and my_new_kek is the key alias.

Then use the ALTER DATABASE statement to re-encrypt the DEK with the new KEK alias assigned in the previous statement:

ALTER DATABASE ENCRYPTION KEY

ENCRYPTION BY SERVER

   {  ASYMMETRIC KEY my_new_kek}

Note that you do not have to take the database offline to perform this action.

Of course, there are other steps that you should take to secure your environment, but I wanted to demonstrate how easy it is to make the change.

The SQL Server DBA and the network administrator will have lots of other considerations in relation to SQL Server encryption. This includes support for clustering and high availability, automatic failover to secondary key servers, adequate support for separation of duties (SOD) and compliance, and the security of the credentials needed to validate SQL Server to the key manager. All of these concerns need to be addressed in a key management deployment.

For SQL Server users who deploy within a VMware or cloud infrastructure (AWS, Azure), Alliance Key Manager can run natively in your environment, too. It does not require a hardware security module (HSM) to achieve good key management with SQL Server. You have lots of choices in how you deploy your key management solution.

It turns out not to be difficult at all to address your SQL Server encryption key insecurities!

Patrick

Encryption and key management for SQL Server

Topics: SQL Server, Transparent Data Encryption (TDE)

Encryption & Key Management for SQL Server

Posted by Luke Probasco on Jul 22, 2016 3:27:11 PM

Excerpt from the eBook "Encryption & Key Management for Microsoft SQL Server."


Microsoft SQL Server has become a ubiquitous storage mechanism for all types of digital assets. Protecting these data assets in SQL Server is a top priority for business executives, security specialists, and IT professionals.  The loss of sensitive data can be devastating to the organization and in some cases represents a catastrophic loss. There is no alternative to a digital existence and cybercriminals, political activists, and state actors have become more and more adept at stealing this information.  To properly protect this information, businesses are turning to encryption and key management.

Encryption

Encryption and key management for SQL ServerEncryption in the broadest sense means obscuring information to make it inaccessible to un- authorized access. But here we will use the term in its more precise and common use – the use of well accepted encryption algorithms based on mathematical proofs and which have been embodied and approved as international standards.

Many approaches to encryption do not meet minimal requirements for security and compliance. Our definition of encryption excludes:

  • Homegrown methods developed by even experienced and talented programmers.
  • Emerging encryption methods that are not yet widely accepted.
  • Encryption methods that are widely accepted as secure, but which have not been adopted by standards organizations.
  • Data substitution and masking methods not based on encryption.

An example of an encryption method that does meet our criteria would include the Advanced Encryption Standard (AES) which is sometimes knows as Rijndael, Triple Data Encryption Standard (3DES), RSA, and Elliptic Curve encryption methods.

In the context of protecting data in a SQL Server data- base, the most common encryption method protecting whole databases or an individual column in a table is AES. All key sizes of AES (128-bit, 192-bit, and 256-bit) are considered secure and are appropriate for protecting digital assets. Many organizations chose 256- bit AES for this purpose due to the larger key size and stronger security.

One major additional benefit of using an industry standard such as AES is that it meets many compliance requirements or recommendations for the use of industry standard encryption. This includes the PCI Data Security Standard (PCI-DSS), HIPAA, FFIEC, and the EU General Data Protection Regulation (EU GDPR).

Key Management

It is not possible to discuss an encryption strategy without discussing the protection of encryption keys. An encryption strategy is only as good as the method used to protect the encryption keys. Encryption algorithms such as AES and Triple DES are public and readily available to any attacker. The protection of the encryption key is the core to the security of the encrypted data. This is why security professionals consider the loss of the encryption key as equivalent to the loss of the digital assets. Once an attacker has the encryption key it is trivial to decrypt and steal the data.

Generating strong encryption keys and protecting them is harder that it might at first appear. The generation of strong encryption keys depends on the use of random number generation schemes, and modern computers do not excel at doing things randomly. Specialized software routines are needed to generate strong encryption keys. Encryption keys must also be securely stored away from the data they protect, and yet must be readily available to users and applications that are authorized to access the sensitive data. Authenticating that a user or application is authorized to an encryption key is a large focus of key management systems.

Over the years standards and best practices have emerged for encryption key management and these have been embodied in specialized security applications called Key Management Systems (KMS), or Enterprise Key Management (EKM) systems. The National Institute of Standards and Technology (NIST) has taken a lead in this area with the creation of Special Publication 800-57 entitled “Recommendation for Key Management”. In addition to this important NIST guidance, the organization publishes the Federal Information Processing Standard (FIPS) 140-2 “Security Requirements for Cryptographic Modules”. To serve the needs of organizations needing independent certification that a key management application meets this standard, NIST provides a validation program for FIPS 140-2 compliant systems. All professional key management systems have been validated to FIPS 140-2.

When protecting sensitive SQL Server data with encryption, look for these core principles of key management:

  • Encryption keys are stored away from the data they protect, usually on specially designed security devices or dedicated virtual servers.
  • Encryption keys are managed by individuals who do not have access to the data stored in the SQL Server database (Separation of Duties).
  • Encryption key management requires more than one security administrator to authenticate before performing any critical work on keys (Dual control).
  • Key retrieval requests from users and applications are authenticated using industry standard methods.
  • Encryption management and key usage are logged in real time and logs are stored on secure log collection servers.
  • Encryption key management systems have been validated to FIPS 140-2 and the Key Management Interoperability Protocol (KMIP).

These are just a few of the core requirements for deploying a professional key management solution to protect your SQL Server data.

Encryption and key management for SQL Server

 

Topics: Encryption, SQL Server

When Encrypting Databases, Does Key Connection for SQL Server Cache the Encryption Key?

Posted by Patrick Townsend on Jul 22, 2016 8:46:30 AM

Customers who need to encrypt data in Microsoft SQL Server databases know that they must protect the encryption key with appropriate controls to meet compliance regulations and to achieve safe harbor in the event of a data breach. Townsend Security's Alliance Key Manager solution provides the Extensible Key Management (EKM) software to make proper key management a breeze. Called Key Connection for SQL Server, this EKM Provider software is installed on the server hosting the SQL Server database and it talks seamlessly to one or more Alliance Key Manager servers running in a separate server instance. Customers get proper key management that meets compliance regulations such as PCI-DSS in an easy-to-deploy solution.

Encryption-Key-Management-SQL-ServerPerformance is always a consideration when it comes to enabling encryption, so customers naturally ask us about key caching. Does Key Connection for SQL Server cache the encryption keys to enable better performance?

The short answer is Yes, it does.

How it does key caching depends on whether you use Transparent Data Encryption (TDE) or Cell Level Encryption (CLE). Let’s drill into each of these cases.

Transparent Data Encryption (TDE)
The implementation of TDE by Microsoft involves encrypting the entire table space and the database logs. It is the easiest type of encryption to deploy as it requires no changes to the actual application that uses the SQL Server database. You can implement TDE encryption by installing the Key Connection For SQL Server software and issuing four commands through the SQL Server management console. Restart logging to insure that it is encrypted and you are done.

So with TDE, how are keys managed? The TDE architecture involves SQL Server generating a symmetric key (usually a 256-bit AES key) and then asking Alliance Key Manager to encrypt it with an RSA key. This encrypted symmetric key is then stored on the server that hosts the SQL Server database. When you start SQL Server (or restart it, as the case may be) the SQL Server instance asks Alliance Key Manager to use RSA decryption to decrypt the symmetric key. Once that is complete the SQL Server instance has the key it needs and no longer needs to communicate with Alliance Key Manager. There is no need for key caching and the key will be decrypted the next time that SQL Server starts.

Cell Level Encryption (CLE)
The implementation of CLE by Microsoft SQL Server is quite different than for TDE. The EKM Provider software is still responsible for managing the symmetric encryption key, but it is accomplished in a different way. You must make small changes to your application SQL statements to request encryption and decryption of the cell contents. When CLE is activated the Key Connection for SQL Server software is called for each column and row that needs to be encrypted or decrypted. This means a lot more calls to the EKM Provider software and this is where key caching is very important.

The Key Connection for SQL Server software in this case does cache the symmetric encryption key (usually a 256-bit AES key) in order to improve performance. The key is cached using an equally strong RSA key to prevent key capture by malware. When SQL Server calls the Townsend Security EKM provider the software retrieves the key from the key server and will cache it locally for a 24 hour period. For the next 24 hours all subsequent requests for encryption or decryption are satisfied locally without the need to retrieve the key again. After 24 hours, the key is discarded and a fresh key is retrieved from the key server. If the connection to the key server is not available error messages are written to the Windows Event Log, but encryption processes will continue using the locally cached key, once the 24 hour period expires, network connectivity will need to be restored for a fresh key to be retrieved and operations restored. With key caching database encryption, performance is much better.

The architecture of the Alliance Key Manager EKM provider implements other core features needed to help protect your database. These include:

  • Separation of Duties between Key Administrators and Database Administrators
  • Dual Control for key management operations
  • Built-in logging to the Windows Event Manager
  • High availability failover to one or more secondary key servers
  • Automatic recovery of failed EKM Provider services
  • Security of credentials through Windows Certificate Store
  • Easy key rollover using native SQL Server commands

Key caching is important for performance, but this is just one part of an overall key management strategy for Microsoft SQL Server.

As customers move to virtualized and cloud environments, Alliance Key Manager and the Key Connection for SQL Server EKM Provider software will move with you. In addition to traditional IT data centers, all Townsend Security encryption and key management solutions run in VMware (vSphere, ESXi, etc.), Microsoft Azure, Amazon Web Services, and in any cloud service provider vCloud environment.

Encryption and Key Management for Microsoft SQL Server

Topics: Alliance Key Manager, SQL Server

Encryption & Key Management in Microsoft SQL Server

Posted by Luke Probasco on Aug 21, 2015 9:27:00 AM

NIck Trenc - CoalfireThis is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP.  Nick is an IT Security Architect at Coalfire Labs.


In any environment where potentially sensitive data is stored using Microsoft’s SQL Server, one of the key issues is how to best protect that data. Microsoft SQL Server does offer several security controls natively, but almost all of them require some sort of extensive configuration and management in order to be done according to security best practices. Additionally, SQL Server’s own security controls do face some shortcomings.

VMware Encryption Key Management PCIIf using SQL Server’s own encryption tools, database encryption keys are stored right next to the data they are used to protect. This makes it easier for would be malicious users to capture both the protected data and the keys used to protect that data.

This is where Townsend Security’s Alliance Key Manager (AKM) comes in to play. Utilizing the built-in SQL support, IT administrators can generate, store, and manage keys within AKM away from the data those keys are used to protect. This enables separation of duties and dual control which are both best practices and requirements of several compliance frameworks.

Alliance Key Manager utilizes the Extensible Key Management (EKM) functionality of SQL Server (Enterprise Edition 2008 and newer) to centrally manage encryption keys. In addition, AKM also includes native support for SQL Server Transparent Data Encryption (TDE) which can be used to encrypt all of the tables within SQL Server. Finally, AKM includes support for SQL Server Cell Level Encryption (sometimes called Column Level Encryption), integrates directly with the Windows Certificate store, and includes features for key caching and mirroring for high availability.

For more information on using AKM to specifically meet PCI DSS compliance within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.

VMware Encryption Key Management PCI DSS

Topics: Encryption Key Management, SQL Server

Securing SQL Server in the Cloud

Posted by Liz Townsend on Dec 19, 2014 10:21:00 AM

Organizations running SQL Server Enterprise edition gain the added benefit of SQL Server transparent data encryption (TDE) and extensible key management (EKM). The encryption capabilities of Enterprise edition enable users to easily encrypt data at the column level of a database, and EKM allows users to store encryption keys using a third-party encryption key management solution. These streamlined capabilities of SQL Server Enterprise Edition have made SQL Server one of the easiest databases to encrypt, and therefore it’s popularity hasn’t waned.SQL Server Resource Kit on Encryption & Key Management

One of the biggest issues facing SQL Server users today is maintaining security as users move their SQL databases to the cloud. While Microsoft Azure remains a popular cloud service provider (CSP) for SQL users, Amazon Web Services (AWS) and VMware are also common amongst organizations moving to the cloud, especially those migrating a multi-platform environment. Each of these top-tier CSPs offer security solutions to help you protect your cloud environment; however, when considering security in the cloud there are two important things to remember: The security offered by your CSP won’t provide you with a complete security solution, and the security solutions you bring to protect your data in the cloud can fail if not implemented correctly.

Don’t rely on the cloud for complete security!

Your CSP should provide your business with some security, but their solutions are likely limited. Most CSPs will offer firewall protection, for example. Top-tier CSPs have also undergone some certifications such as Payment Card Industry (PCI) and FedRAMP compliance. It is important to remember, however, that relying on firewalls alone is not enough to prevent intruders, and cloud certifications never mean that your company will automatically meet these compliance regulations as well. A comprehensive data security plan is required for any business operating in the cloud, and this typically requires using third-party security solutions to ensure your business meets compliance and is adequately protecting data.

Remember these two things when protecting data in the cloud:

  • The security solutions offered by your cloud vendor are rarely enough to prevent a data breach.
  • Just because your cloud service provider is compliant, doesn’t mean you are.

Storing data in SQL Server in the cloud presents new security challenges. Hackers or malicious users can gain access to sensitive data easily through common hacks. Easy hacking of SQL Server is a result from:

  • Incorrect configuration of cloud provider’s firewall
  • Attacks through weaknesses that could have been addressed by updating and patching SQL Server
  • Missing or weak passwords
  • social engineering and account hacking
  • Lax administrative access

When it comes to securing SQL Server in the cloud, you should also always consult your legal and auditing team (or consultants) before assuming that your data is safe and you are compliant with any industry security regulations. On a general level, it’s important to include these security measures in your holistic security plan:

  • Intrusion prevention
  • System logging and monitoring
  • Encryption & key management
  • SSH in place of passwords
  • Limited access to sensitive data
  • Separation of duties and split knowledge when accessing encryption keys and sensitive data.

It’s important to remember that your business continuity relies on your own security plan. Regardless of the environment, when your organization experience a data breach, ultimately the responsibility is yours. Your customers, as well as your employees, rely on you to protect their data, and if you fail to do so, the consequences may include loss of customer loyalty and a severely damaged brand. The ultimate way to prevent access to sensitive data is using encryption and encryption key management.

To learn more about how Microsoft SQL Server Enterprise Edition can easily be secured in the cloud, download:

Resource Kit: Encrypting Data on SQL Server

 

Topics: Encryption, Encryption Key Management, Resource Kit, SQL Server, Cloud Security

VMware and SQL Server Encryption

Posted by Michelle Larson on Dec 12, 2014 9:38:00 AM

Questions and Answers on Encryption and Key Management Projects

VMware® is hands-down the virtualization choice of large and small organizations, and it is easy to see why. Not only is it a highly reliable and scalable platform, VMware also provides a complete set of tools you need to deploy, manage, monitor, and protect virtual machines.

Earlier this month, Paul Taylor with Security Insider - Podcast Edition spoke with our founder, Patrick Townsend about encrypting data on Microsoft SQL Server in VMware environments, steps to encrypting data on SQL Server (with and without TDE), as well as talk about Townsend Security’s Alliance Key Manager for VMware. Here are a few highlights (download the podcast for the whole conversation):Podcast: VMware and SQL Server Encryption

Paul Taylor: We’ve talked about the Townsend Security encryption and key management solutions for VMware. Today let’s put the focus on Microsoft SQL Server and encryption in the VMware customer environment. Can you give us an overview of how VMware customers can protect data in SQL Server databases?

Patrick Townsend: Just to recap, we really need two things to get encryption right: A key management solution to protect the critical encryption keys, and an encryption solution for the SQL Server database. And they have to talk to each other.

For the first part, our Alliance Key Manager for VMware solution provides a fully functional, enterprise key management solution that protects SQL Server databases as well as other databases and other operating systems.

For encrypting SQL Server, our Alliance Key Manager solution comes with a full Microsoft SQL Server Extensible Key Management Provider. We call this Key Connection for SQL Server and it is one of the modules that our key management customers receive without paying additional license fees. Key Connection for SQL Server provides the encryption and integration with our key server to provide a complete, end-to-end solution for encrypting data in the SQL Server database.

Paul Taylor: Can you talk a little about how Microsoft enables encryption in SQL Server?

Patrick Townsend: If you are running SQL Server Enterprise Edition or higher, you have access to Microsoft’s automatic, full database encryption facility called Transparent Data Encryption, or TDE. You also have access to Microsoft’s automatic, column level encryption facility which Microsoft calls Cell Level Encryption. Both of these options, TDE and Cell Level Encryption,  are implemented without any programming work at all. And both are fully supported by Alliance Key Manager and the Key Connection for SQL Server software from Townsend Security.

Paul Taylor: What about Microsoft customers who aren’t using the Enterprise Edition of SQL Server? Can they encrypt their data with the Townsend Security solution?

Patrick Townsend:  With SQL Server Standard and Web Editions we provide two paths to encrypt data. The first is to use SQL Views and Triggers along with our .NET DLL to provide automatic encryption without any changes to applications. And the second path is to modify your C# or Java applications to use our .NET DLL to perform encryption at the application level.

Both approaches leverage our Microsoft .NET DLLs to perform encryption with integrated key management. Both are very simple to implement. And there are no additional license fees to deploy and use our Microsoft .NET DLLs to accomplish this.

Paul Taylor: So, walk me through the steps for encrypting data in my SQL Server Enterprise Edition database. How difficult is it?

Patrick Townsend: Encrypting data in Enterprise SQL Server is really very easy. The first step is to install our Alliance Key Manager for VMware solution. It launches like any other virtual machine using the normal VMware applications and you can have a key management solution up and running very quickly.

The second step is to install the Key Connection for SQL Server application on the virtual machine running SQL Server in Windows. This is a normal install process with an MSI file. You answer some questions, install a certificate and private key in the Windows Certificate Store, and run a handful of commands to start SQL Server TDE encryption or Cell Level Encryption. You also restart the log file to be sure that it is encrypted as well. That’s about it.

Of course, you will want to follow the instructions on how to set up a high availability key server, and point your Key Connection for SQL Server configuration to it as failover. That is a normal configuration process and also very easy to do. We find that VMware customers can deploy SQL Server encryption very quickly.

Paul and Patrick also cover which versions of SQL Server are supported, the availability of Alliance Key Manager in other platforms (hint: it’s quite versatile), and our 30-day evaluation program (you can do a full proof-of-concept in your own environment at no charge). Be sure to download the podcast to hear the rest of their conversation:

Podcast: VMware and SQL Server Encryption

Topics: Data Security, Encryption, Security Insider Podcast, Encryption Key Management, VMware, SQL Server

VMware and SQL Server Encryption – We Can Do That

Posted by Patrick Townsend on Dec 2, 2014 9:44:00 AM

VMware is hands-down the virtualization choice of large and small organizations. And it is easy to see why. Not only is it a highly reliable and scalable platform, but VMware provides a complete set of tools you need to deploy, manage, monitor, and protect virtual machines. And did I mention that it totally rocks the scalability challenge?

SQL Server Resource Kit on Encryption & Key ManagementLet’s look at how VMware customers who run Microsoft SQL Server applications can enable encryption and key management to protect sensitive data and meet compliance regulations.

First Step:

We have to solve the encryption key management challenge. As we like to say around here, the hardest part of security is encryption, and the hardest part of encryption is key management. We have to store the encryption keys separate from the protected data, and use industry standard practices to protect them. With our Alliance Key Manager for VMware solution we make this problem easy to solve. Our key manager comes in a ready-to-deploy OVA format and VMware customers can just launch the key manager with standard VMware tools. Of course, there are some security best practices on how to properly deploy a security application like a key manager in VMware (see the resources section below). With Alliance Key Manager’s Ready-To-Use options you can have your VMware key management problem solved in just SECONDS.

Of course, some of our VMware customers want to protect encryption keys in traditional Hardware Security Modules (HSMs). No problem, Alliance Key Manager can be deployed as a rack-mounted HSM or as a vCloud instance.

The Second Step:

Now we want to enable encryption in SQL Server and protect the encryption keys with Alliance Key Manager. Thanks to Microsoft’s Extensible Key Management (EKM) interface, this is incredibly easy. Alliance Key Manager comes with EKM Provider software that plugs right into SQL Server to enable encryption and protect your encryption keys. We call this our Key Connection for SQL Server application and it installs on your SQL Server VMware instance using a standard MSI install process. Key Connection for SQL Server runs in all SQL Server environments including VMware, hardware, vCloud, and cloud platforms so hybrid environments are fully supported. Install the credentials, select the SQL Server instances you want to protect, answer some questions, type a few commands and you have a fully protected SQL Server database using Transparent Data Encryption (TDE). Again, this takes just minutes to accomplish.

SQL Server also supports column level encryption, which Microsoft calls Cell Level Encryption. It can provide better performance for some SQL Server databases. Yes, that’s also supported through the same Key Connection for SQL Server software.

The beauty of the Microsoft EKM architecture is that you don’t need to modify your SQL Server applications to deploy encryption. Your DBA and security team can get your data protected very quickly without a development project. Anybody got budget for that these days?

Hint

Already encrypting SQL Server but aren’t protecting your encryption key? That’s easy – you can install Key Connection for SQL Server, issue a few commands, and the problem is solved!

The Third Step:

What about high availability, business recovery, clustered configurations, and system logs? We’ve got all of that covered, too. Using the same Key Connection for SQL Server EKM Provider (did I mention that it’s free?) you can configure one or more secondary key servers that function as high availability failover servers for business recovery? Key Connection for SQL Server will automatically failover to secondary key servers if the primary key server is unavailable.

Alliance Key Manager also fits nicely into your active monitoring strategy. You can easily enable forwarding of all key access, key management, encryption, and system activity logs to your log collection server or SIEM solution.

Celebrate Victory and Do It Again!

Alliance Key Manager protects Oracle, IBM, MySQL and other databases as well as web applications and unstructured data. You get to deploy one key management solution to protect everything. And do you know how much it will cost you to do your next project? Nothing, zilch, zed, nada! Alliance Key Manager does not force you to license and pay for client-side applications.

Hint

I’ll talk more in future posts about how to protect other databases and applications in VMware environments. Stay tuned if you run SharePoint, Microsoft CRM or ERP applications, Oracle, or open source databases like MySQL and SQLite.

How Much Better Can This Get?

You can evaluate Alliance Key Manager and Key Connection for SQL Server in your own VMware environment free of charge. Just visit our Alliance Key Manager for SQL Server page and request a free 30-day evaluation.

Encryption and key management? We can get this done right!

Resources:

PCI SSC Virtualization Guidelines

VMware Solution Guide for Payment Card Industry (PCI)

Securing Alliance Key Manager for VMwar

Alliance Key Manager for VMware Solution Brief

Resource Kit: Encrypting Data on SQL Server

 

 

Topics: Alliance Key Manager, Encryption, VMware, SQL Server

Encryption Key Management in SQL Server

Posted by Michelle Larson on Nov 12, 2014 11:32:00 AM

Beyond meeting compliance regulations, it is the right thing to do!

In the past, encryption has had a reputation for being difficult to do, complex, and time consuming, we hope to show you how that has changed. If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project.  Download the Webinar - Just Click! 

Since it wasn’t thought of as something that improved the “Bottom line” by increasing revenue or decreasing expenses, encryption has historically been a project solely driven by the need to meet compliance regulations. There are a large variety of compliance regulations that most, if not all, businesses fall under. One common misconception about compliance regulations is that they don’t equally apply to both private and public companies. To clarify, these regulations apply to all companies, of all sizes, whether they are privately-held or publicly-owned. 

For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

  • HIPAA Data Security & HITECH Act of 2009 which applies to Medical Providers and the healthcare industry.
  • GLBA/FFIEC apply to banks, credit unions, credit reporting agencies, and anyone in the financial industry.
  • FISMA is for Federal US Government Agencies.
  • The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.

More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… and what is it anyways? First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Hackers and data thieves are targeting mid-sized companies because, as larger companies get better at securing sensitive information, the hackers see smaller companies as better targets. Financial fraud and data breaches become more common in those businesses that might not be as prepared without the resources to have an internal security team. Data loss can have a big impact on a company's reputation as well as their financial health.

AES encryption is a mathematical formula for protecting data.  It is based on a proven, well-known algorithm and standards published by NIST. Since that formula is a open and vetted standard use, it is not the mathematical algorithm that is the big secret. It is what happens with the “Key” that locks and unlocks the data that all the fuss is about.

Key management is so important because the encryption keys are THE secret that must be protected. Without access to the key, a hacker that accesses encrypted data has no way to read it. Industry standards and best practices for encryption key management, as well as compliance regulations that require proper encryption key management, all state that storing encryption keys on the server with the protected data is a poor security practice. Encryption keys are unique and cryptographically secure, and once created, protecting the key is the core practice that will protect the sensitive data. It will not be defensible in the event of a data breach if the keys were stored in the same server as the data. This would be like leaving the key to your house in the door lock and being surprised that someone entered uninvited!

Our solutions help Microsoft SQL Server customers really protect their data. Alliance Key Manager, our encryption key management solution, is NIST FIPS 140-2 compliant. This means it meets Federal standards that private enterprises expect around key management. We provide encryption key management solutions for every version and edition of SQL Server starting with SQL Server 2005. In addition, you can choose between a hardware security module (HSM), Cloud HSM, VMware virtual appliance, or a cloud instance in AWS or Azure. Easy. Efficient. Cost-Effective.

Please join our founder and data security expert, Patrick Townsend, in this 30-minute webinar that will cover encryption and key management best practices with Microsoft SQL Server!

Encryption Key Management for Microsoft SQL Server

As always, your comments and feedback are appreciated! 

Topics: Alliance Key Manager, Microsoft, Encryption Key Management, SQL Server, Webinar

 

 

Subscribe to Email Updates

Posts by Topic

see all