“I’m scared to death about what my users are putting into SharePoint!”

This is what a Database Administrator said to me recently when I attended a SQL Saturday event on the Microsoft campus in Redmond, Washington. And I’m hearing that a lot from IT directors and CIOs in the financial and medical sectors. Microsoft SharePoint is a wonderful collaboration tool, and it supports a number of versions and deployment options. These options run the gamut from free versions that ship with Windows Server, to versions tailored to the Microsoft Office suite of applications, to web portals. And an industry has grown up around installing, customizing, and hosting SharePoint.

But IT managers are sweating about the risk of data loss. And they have reason to be afraid.

We know that users are creative about circumventing written policies about data security. Ever look at an audit of user passwords? It’s a good bet that “Password1” is the most common password on your network. It has upper and lower case letters, and at least one number. And even good employees can accidentally violate security policy. We ask a lot of our colleagues and security is often not on the top of their consciousness. So how likely is it that users are following your security policy requirement NOT storing sensitive data in SharePoint?

Somewhere close to zero.

And that’s why IT managers have good reason to be concerned. And that’s one reason why the uptake of SharePoint collaboration runs into resistance in the financial and medical segments.

Fortunately, Microsoft added some important security features to SharePoint 2010. One of those is support for Transparent Data Encryption (TDE) when you use SQL Server 2008 as the storage mechanism for SharePoint. The great thing about TDE is that it is easy to implement. You get good encryption performance, separated key management, and a high level of automation. Your IT staff can deliver it with a minimum of fuss and delay.

Will encryption with TDE solve all of the SharePoint security concerns? No. But it will protect you from data loss in the event of a lost backup or hard drive, and a server breach that just steals a copy of the database or log files won’t compromise your data. That’s one big step in the right direction.

Take a look at our encryption key management solution built for Microsoft SQL Server. You can start to build the confidence you and your management team needs to move forward with SharePoint collaboration, and at a reasonable cost and in a reasonable time frame.

For even more information, view our webinar “Encryption Key Management with Microsoft SQL Server.”  See how easy it can be to implement strong key management and hear what hundreds of attendees learned at PASS last week.

Patrick

As a company that provides NIST-certified encryption and FIPS 140-2 encryption key management, we need to secure data on a number of different platforms. Lately we have been coming into several cases where a customer needs encryption and key management on both Microsoft SQL Server and Oracle databases. Below is an email exchange with a customer who came to us “looking for a product to store, generate and manage keys that we use to encrypt/decrypt credit card information inside both SQL Server and Oracle Databases on Windows and UNIX.” We hope this discussion helps with your encryption project.

Customers Environment:

1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.

2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).

3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table.  It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number.  So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.

Questions Addressed:

Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.

SQL Server:

Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.

The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.

Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.

Oracle:

Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.

Key Generation:

Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.

Encryption on HSM:

Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.

We hope that this case study can help you with your encryption project.  Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.

Microsoft 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!

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

 

 

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.

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.

The modern Enterprise deploys a variety of server platforms, operating systems, and programming languages.  A major barrier to deploying encryption has been the challenge of accessing encryption keys from these widely divergent environments.  Encryption key management solutions have the primary goal of managing and protecting encryption keys, and making them available to authorized applications in a secure fashion.

Key management solutions vary greatly in the complexity of the key retrieval process. The more complex the key retrieval interface, the greater the challenge for the Enterprise IT team in deploying key retrieval in applications. Understanding this fact can help IT decision makers assess different vendor solutions and the likely costs of deploying a solution in their enterprise.  Below is a list of questions that you should ask your key management vendor when assessing their solution.

Key Management Vendor Checklist

1.  Is your key manager FIPS 140 certified?  What is the certificate number?

2.  How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?

3.  Is there a common key retrieval application interface on all platforms?  What are the differences?

4.  What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)

5.  Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)

6.  Do you supply binary libraries for all Enterprise servers?

7.  Do you have a Java key retrieval class and examples? Is it standard Java or JNI?

8.  Do you charge separate license fees for each client operating system?

9.  Do you require that we purchase consulting services from you?  Why?

10.  I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?
 
Once you have the answer to the above questions, it should be easier to choose the right key management vendor for your Enterprise. If you have any questions, click here and we will call you right back.

 

I invited a partner to come down from Seattle to learn about our key management appliance, Alliance Key Manager. It started innocently enough, we planned to meet on February 21st and discuss our encryption, key management and system logging solutions in the context of PCI compliance.  A week later, I received a call from an Australian partner asking to come by our office for training on Feb 21st. They were going to be in Seattle after the RSA Conference. I told them they were in luck, we were coincidentally conducting a training session on that very day, come to our office, we would love to host them. 

We had two partners confirmed, why not ask a few more? Turns out some others were available as well.  Voila! The first annual  Townsend Security Partner Training was underway!!

The day started with a tour of our new offices- a must-see when in the Seattle area!! Training began with an overview of FTP Manager and PGP encryption.  Our latest release of FTP Manager, our managed file transfer offering, brings support for encrypted PDF and encrypted ZIP files as well as PGP administrative enhancements. 

Break! After a fabulous lunch at a local Italian restaurant, we delved into the world of encryption key management, database encryption, and system logging.

Patrick Townsend, Founder & CTO, addressed the importance of encryption & key management as a means of protecting data and meeting PCI compliance. The renewed focus on "Dual Control" and "Separation of Duties" by QSA auditors is forcing many IBM i customers to move from homegrown key management to a better method of securing encryption keys.  He explained how compliance auditors requirements have evolved from "you must encrypt" to "don't store your keys with your encrypted data" to "protect keys with a key manager" and are now converging on the message "that key manager should be FIPS-140 certified."

Finally, partners were introduced to what an end-user sees when we work with them.  We took them through a pre-sales walkthrough and through a post-sales support ticket.  Eppy Thatcher, one of our senior support engineers, walked everyone through a demonstration of Alliance Key Manager and LogAgent.  A few of our partners were surprised to learn that some compliance regulations require collecting system logs. Eppy showed  them how Alliance LogAgent can communicate with any SIEM solution and help satisfy system log requirements.

By the end of the day, everyone walked away with a solid understanding of how our solutions work and how they can help meet compliance regulations.  Our partners saw the benefits of being able to offer their customers NIST and FIPS-140 certified encryption and key management solutions. They realize that these certifications will guarantee encryption and key management is done correctly.

If you are interested in becoming a partner or attending the next partner training session, please let us know.

Robbn Miller, Channel Manager

I just returned from a trip to Europe and Encryption Key Management was a very hot topic.  This is a topic I very much like to speak about, given our recent release of Alliance Key Manager.  It still surprises me how many conversations I had with technology companies who understood the need to have a proper key manager either embedded within or integrated from the outside of their program or appliance.  There are, I think, a couple of reasons for this phenomena.  

First, many organizations are taking the step to encrypt sensitive data that used to be stored in the clear.  Protecting data is an important IT initiative these days, and one of the absolute best ways to protect data is to encrypt that data.  But as IT teams take on their encryption initiatives, somewhere in the middle of their first encryption project an important realization dawns upon them: After you encrypt the data, the data is only safe if you protect the encryption key.  At this point some organizations will put a temporary fix in place and "hide" the keys as best they can on the same server as the data, but they know this is wholly unsuitable and that a more secure and more permanent solution must be found.

The second reason that I think key management has become such a hot topic on this trip is because of the increased number of compliance regulations around encryption key management.  In October of 2010 the PCI-DSS 2.0 standard was released and in it is call for organizations that store credit card information to use a certified key management solution that is separated from the data, includes robust auditing capability, and supports separation of duties and dual control (more on those topics perhaps in another blog post).

From my perspective then, we appear to have just the right solution at just the right time.  Having recently received our FIPS-140-2 certification for Alliance Key Manager in the U.S. Mail, we're in a celebratory mood here at Townsend Security and it is good to hear all our friends in Europe endorse the time and effort our team has put into this fabulous offering.

John Earl