+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

Fixing Encryption Key Management Audit Failures in Microsoft Windows C# Applications

Posted by Patrick Townsend on Dec 23, 2015 11:00:00 AM

It seems like every week I talk to a new Microsoft Windows customer who has just failed a security audit because they are not handling encryption keys correctly in their Microsoft applications. I hear an assortment of descriptions like this:

Encryption Key Management for Microsoft .NET We’re doing encryption, but the encryption key is stored in a table in the database.

We’re doing encryption, but the key is burned in our C# code.

We’re doing encryption, but the key is stored in a flat file protected with a password.

We’re doing encryption, but our encryption key is weak - it’s just a password

These Microsoft customers are trying to do the right thing when it comes to encrypting sensitive data, they just did not get the proper security controls in place for the encryption keys. And this is understandable, Microsoft does not provide very good guidance in this area, and it is probably the area where most organizations fail to get encryption right. When you do encryption, using strong encryption keys and protecting them properly is the hardest part.

You’ve made a big investment in your application built on the Microsoft C# .NET architecture, so what do you do now?

It turns out that it is not difficult to remediate this problem. You need a few things:

  • A good key manager built and certified to industry standards.
  • A Windows software library that is friendly to your C# application.
  • A developer who can implement some simple methods for key management.

Let’s look at how we help our customers solve these three challenges:

1) A key manager is easy. Our Alliance Key Manager solution is an easy-to-install and configure key management solution that runs as a Cloud instance (AWS, Azure), as a VMware virtual machine, as a network-attached hardware security module (HSM), or as a dedicated Cloud HSM. It configures in a few seconds and you have a fully functional, dedicated, FIPS 140-2 compliant key management solution. It even automatically creates unique encryption keys for you on the first boot.

2) The second thing you need is a good Windows .NET software library that makes retrieving the encryption key seamless. We provide that at no charge in the form of our Windows .NET Client. It installs on Windows in the usual way and is ready to add to your Visual Studio project. The Windows .NET Client software DLL handles all of the complexities for you. It makes the authenticated connection to the key server, audits all key retrieval activity, and caches the key for the best performance. Sample C# code shows you exactly how to do key retrieval from your code and is easy to implement.

3) The third thing you need is a good developer. With over 2 million Windows developers out there it is not hard to find one. Maybe this is you? Making the code change to incorporate key retrieval with Alliance Key Manager’s Windows .NET Client is really simple in C#. You just remove the logic of the burned in key or the logic to retrieve it from a file, add the Alliance Key Manager Windows .NET Client to your Visual Studio project, and put in code that looks something like this (see the sample code for the complete picture):

// Load the data to be encrypted
plaintext = Encoding.UTF8.GetBytes(data);
// Initialize for the client configuration file
SetClientConfiguration(keyService.ClientConfiguration);
// Retrieve the encryption key from the key server
key = keyService.GetSymmetricKey(keyName, instance);
// Perform encryption
using (var algorithm = new RijndaelManaged())
{
algorithm.Key = key.KeyBytes();
using (var encryptor = algorithm.CreateEncryptor())
{
ciphertext = encryptor.TransformFinalBlock(plaintext, 0,
plaintext.Length);
}
}
// Display the ciphertext (you would probably save it in a database)
Console.WriteLine("ciphertext: " + BitConverter.ToString(ciphertext));

The Alliance Key Manager Windows .NET Client code handles a lot of issues for you. Here are just a few:

Authentication
The Windows .NET Client performs the TLS connection to Alliance Key Manager and handles the full authentication sequence. You get a secure, mutually authenticated TLS connection without needing to handle that in your C# code.

High Availability Failover
You can define one or more Alliance Key Managers in a high availability failover group. If one key manager is not available due to a network failure or a key server failure, the client-side code will automatically use the next available key server. You can define a primary and multiple failover key servers, and you can mix and match cloud, virtual, and HSMs in your key management topology.

Performance
The Alliance Key Manager Windows .NET Client is designed for high performance. It will automatically securely cache encryption keys so that you don’t need to retrieve the keys more than one. If the key has been retrieved before in your current process it will be returned to you without a round-trip communications session with the key server. That gives you maximum performance.

PCI Compliance - Coalfire and PAG
Alliance Key Manager is FIPS 140-2 compliant (certificate 1449) and has been PCI validated by Coalfire, a top-tier QSA auditor. This means that you can achieve very rapid compliance with PCI and other compliance regulations without a lot of fuss. If you are under the gun to fix a compliance failure, you should start with a solution that provably meets the compliance regulation. Alliance Key Manager does exactly that. The PCI Product Applicability Guide is here.

Most C# applications that we see are well-modularized and the encryption logic is in one place, or a very small number of locations in the code. This makes the change to your code easy to make and easy to test. The complexity is handled for you in the Alliance Key Manager Windows .NET Client software.

You can find the Alliance Key Manager Windows .NET Client application on the supplemental download for the product. It is available at no charge and there are no client-side license fees. In addition to the installation package you will find full sample code and documentation.  For interested developers, we also offer a free developer program.  As always, let us know if you have any questions.

Enjoy.

Patrick

Encryption Key Management for Microsoft .NET

Topics: C#, Microsoft, .NET, Encryption Key Management

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

Encrypting Data with .NET Libraries

Posted by Michelle Larson on Jul 18, 2014 11:40:00 AM

Encryption and key management continue to be perceived as challenges for .NET developers as more compliance regulations and state laws require the physical separation of encryption keys from the data they protect.

White Paper: Key Management in a Multi-Platform Environment In the past, .NET developers might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach does not meet the requirements for dual control, separation of duties, and split knowledge required by security best practices and compliance regulations such as PCI DSS, HIPAA/HITECH, GLBA/FFIEC, and others.

Historically, Microsoft .NET developers expected to experience some heartburn with an encryption key manager because:

  • Key management vendors were historically not responsive to the needs of a .NET developer and failed to provide interfaces that work naturally in this environment
  • Complex DLL implementations required special .NET wrapper code
  • Poor integration with the existing .NET encryption APIs
  • The absence of quality sample code which made life difficult for the Microsoft  .NET developer or slowed down application development

There have been a lot of changes that now make it easier on Microsoft .NET developers to approach encryption and key management. A key manager solution should:

  • Provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages.
  • 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, you decide the best approach to encryption once an encryption key is retrieved to the application (this approach also supports Microsoft’s Managed Code architecture)
  • Offer vetted sample code to help speed development! 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
  • Integration of encryption key retrieval routines with the Windows certificate store and native Windows communications facility.
    • When a Windows application authenticates, the certificates used for the secure TLS connection are under Windows security and control. 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.

As a developer, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data. These technical hurdles should not stop you from using an encryption key manager to meet compliance requirements for protecting encryption keys.

  • Look for 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# or VB.NET code and you are retrieving the encryption key from the HSM.
  • Make sure sample code is provided on the product CD to get you up and running quickly. There should be sample applications with source code that you can use as a starting point in your projects.
  • The .NET Assembly should work with any .NET language. It should also work with the Common Language Runtime (CLR) environment, and with Stored Procedures. Make sure you can mix and match your .NET languages, databases, and OS platforms.

The combination of NIST validated encryption and an affordable FIPS 140-2 compliant key management solution with solid support for the Microsoft .NET developer makes our Alliance Key Manager a great option for users who need to meet security best practices and compliance regulations for key management. It is time to change your encryption strategy to incorporate solid encryption and an external key manager, whether that is an HSM, Cloud HSM, or virtual environment.

Download our white paper, Key Management in the Multi-Platform Environment, for more information on securing your encryption keys.

White P

Topics: Alliance Key Manager, Microsoft, .NET, Encryption Key Management, White Paper

PASS Summit 2013 - We’ll Be There! Will You?

Posted by Liz Townsend on Oct 8, 2013 3:00:00 PM

Townsend Security, an industry leader in data security and encryption key management, will be exhibiting at the PASS Summit in Charlotte, North Carolina this year on October 15-18. We will feature our FIPS 140-2 compliant encryption key management hardware security module (HSM), along with our new hosting option for managing your encryption keys in the cloud.

Encryption-Key-Management-SQL-Server

Will you be attending PASS this year? The Professional Association of SQL Server (PASS) hosts this summit every year and is the largest conference for SQL users and professionals worldwide. Look for us in booth #322 to learn more about how easy encryption and encryption key management can be with your SQL Server. Whether you are using a legacy version of SQL Server or SQL Server 2012 with Transparent Data Encryption (TDE) and Extensible Key Management (EKM), Alliance Key Manager can manage your encryption keys.

How Alliance Key Manager for SQL Server protects your data:

  • Automation of all key management tasks including rotation, retrieval, and generation in a central location
  • Uses Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008/2012
  • Works with all versions of SQL Server

Key Management Hosted in the Cloud
Townsend Security's new Alliance Key Manager Hosted HSM solution allows customers to own a dedicated key manager HSM in a hosted environment consisting. The solutions consists of a production and high availability (HA) HSM in geographically dispersed data centers under an ITIL-based control environment independently validated for compliance against PCI DSS and SOC frameworks. Unlike other hosted encryption key management offerings, only the customer has administrative and security access to the HSMs.

Encrypting Data in Microsoft SharePoint
Since Microsoft SharePoint runs on top of a SQL Server environment, protecting data in SharePoint is easier than ever. Many SQL administrators are fearful that their users are storing sensitive, unencrypted data in SharePoint, and they rightly should be. Alliance Key Manager for SQL Server can help to secure this data.

Encryption Key Management for SQL Server Enterprise Edition
Alliance Key Manager for SQL Server integrates seamlessly with TDE and EKM technologies to enable automatic encryption in SQL Server 2008/2012 Enterprise Edition and above. Additionally, Alliance Key Manager for SQL Server supports cell level encryption, which allows database administrators to select the columns they wish to encrypt in a database - a benefit for many administrators with larger databases.

Encryption Key Management for SQL Server 2005
Many SQL users are still running earlier editions of SQL Server that don’t support EKM & TDE. However, running older versions of SQL Server does not limit your ability to encrypt data and manage encryption keys! Townsend Security supports cell level encryption for SQL Server 2005.

Multi-Platform Environments
Alliance Key Manager isn’t exclusive to the Microsoft SQL suite. In fact, our key management server integrates easily into complex, multi platform environments with many types of databases, operating systems, and programming languages. Our encryption key manager can protect data on the IBM i (AS/400), DB2, Oracle, Linux, Windows, and in the cloud.

To learn more, download our white paper "Encryption Key Management for Microsoft SQL Server 2008/2012."

Click me

Topics: Microsoft, Encryption Key Management, White Paper, Trade Shows, SQL Server

SQL Server Data Protection: Setting Up TDE or Cell Level Encryption

Posted by Michelle Larson on Jun 5, 2013 3:00:00 PM

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.

SQL Server Encryption Key Management Resources

Users select from one of the two methods of 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:

Download Resources

As always, we welcome your comments and question.

Topics: Extensible Key Management (EKM), Microsoft, Encryption Key Management, SQL Server, Cell Level Encryption, Transparent Data Encryption (TDE)

4 Ways to Encrypt Data in Microsoft SQL Server

Posted by Patrick Townsend on May 6, 2013 4:29:00 PM

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

Encryption-Key-Management-SQL-Server 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, or GLBA/FFIEC, 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 harware security moule 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 SQL Server 2008-2016 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 Microsoft has supported automatic encryption with TDE and cell 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 management HSM.
  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 managemer 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.

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

Encryption and Key Management for Microsoft SQL Server

 

Topics: Extensible Key Management (EKM), Microsoft, Encryption Key Management, White Paper, SQL Server, SQL Server encryption

.NET Encryption and Key Management

Posted by Patrick Townsend on Aug 13, 2012 10:29:00 AM

Key Management in the Multi-Platform Environment

encryption key management white paper

Download the white paper "Key Management in the Multi-Platform Environment"

Click Here to Download Now

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

Click me

Topics: Alliance Key Manager, Encryption, Key Management, Extensible Key Management (EKM), C#, Microsoft, .NET, SQL Server

Securing SharePoint 2010 Content with Encryption and Key Management

Posted by Patrick Townsend on Sep 20, 2011 12:00:00 AM

share point encryptionMicrosoft has a great hit in the SharePoint suite of products. I am guessing that this might have taken them at bit by surprise, but SharePoint turns out to be very popular with organizations large and small. In the early days it was a free component that tagged along with Windows Server. Now there are many varieties of SharePoint that include flavors for Office, web portals, collaboration, Customer Relationship Management, and on and on. And a whole ecology of Microsoft partners and ISVs are building solutions on top of SharePoint, or incorporating support for SharePoint in their business applications.

What a great success story!

Download White Paper on EKM for SQL Server Securing SharePoint is now a big focus for those same Microsoft customers. Once you have a user friendly collaboration tool in place, it’s hard to know what those pesky users are going to put in there. Are they storing credit card numbers or social security numbers? Perhaps bank account numbers? Could our users be uploading spreadsheets with thousands or even millions of records with sensitive data?

You bet they are!

And this is keeping security administrators and compliance auditors awake at night.

What you might not know is that SharePoint is built on top of Microsoft SQL Server as its data store. And in SharePoint 2010 you can now deploy SQL Server 2008 R2 with Extensible Key Management (EKM) and Transparent Data Encryption (TDE) to get data-at-rest protection for your SharePoint content. This is a great step forward in content protection, and many security administrators are now using this facility.

Of course, our Alliance Key Manager for SQL Server solution works naturally with SharePoint 2010 built on SQL Server EKM. You get full support for a compliant and best practice approach for separating encryption keys from sensitive data as required by PCI DSS and other regulations. If you are already running our key manager to protect SQL Server database applications, you have what you need to protect SharePoint.

Many SharePoint customers are rightfully concerned about the performance impacts of encryption. I think Microsoft has done a good job in this area, too. Microsoft will tell you that the likely performance impact with SQL Server Transparent Data Encryption (TDE) is from 2 to 4 percent. Our own performance tests have similar results, and in some cases are below 2 percent. This is really astounding performance when you consider that the entire table space is being protected by strong encryption. Of course, customer environments vary a great deal, and you should always model your environment to determine the likely impacts. But I think that the large majority of SharePoint 2010 installations will benefit from SQL Server TDE encryption.

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.  Additionally, I’ve added some resource links below if you want to explore SharePoint 2010 and SQL Server encryption in more detail.

Patrick

  Click me

 

Resources

Here is a blog by Margo Crandell of Microsoft on SharePoint and SQL Server.  It’s a good entry point for a discussion of SharePoint with SQL Server.

This TechNet article talks about planning and deploying SharePoint with SQL Server, including how to migrate to newer versions of SQL server.

I’ve found this Microsoft Whitepaper very informative on security and SharePoint. You will find a good, basic discussion about SQL Server TDE in this document.

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

Microsoft SQL Server EKM – Should I use TDE or Cell Level Encryption?

Posted by Patrick Townsend on Sep 15, 2011 8:24:00 AM

SQL TDE or Cell Level EncryptionAs 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.

Click me

Topics: Alliance Key Manager, Extensible Key Management (EKM), Microsoft, Encryption Key Management, SQL Server, Cell Level Encryption, Transparent Data Encryption (TDE)

SQL Server Extensible Key Management (EKM) and Certificates

Posted by Patrick Townsend on Sep 8, 2011 7:41:00 AM

encryption key management sqlMicrosoft 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.

Click me

Topics: Alliance Key Manager, Extensible Key Management (EKM), Microsoft, Encryption Key Management, SQL Server


Subscribe to Email Updates

Posts by Topic

see all