Townsend Security Data Privacy Blog

I recently returned from 5th Annual PCI Security Standards Council vendor expo in Scottsdale, AZ.  And rather than returning with a sunburn - after all it was 106 degrees there - I returned with a much better appreciation of what companies are doing to help protect cardholder data.  Every major company that accepts credit cards was at this event.  As a consumer at many of these companies, it made me feel good to know that they take this job seriously and are doing everything they can to keep my information and all of their customers’ information secure.

This was my first time at the event and I enjoyed meeting new people and learned a lot of interesting things. I met with QSA audtiors, customers, potential customers  and vendors.   When asked who Townsend Security was,  I recited my elevator pitch and said “we provide certified encryption and key management solutions to help mid-market customers meet compliance requirements.”  That message was well received, however, as the expo continued, I discovered that people “get” encryption and were more interested in discussing encryption key management.  Many knew key management was something they needed to do and for those that said they were doing something, they wanted to know how they could automate the process.

I spoke with one QSA auditor and asked his opinion on why so many people might be inquiring on this topic and his response, “I have yet to see key management done correctly.” And for companies working on staying compliant,  I think one lady’s response about key management at her organization may sum it up best -- a long pause, accompanied with a rolling of her eyes and a heavy sign saying “it’s not good.”

We know encryption key management isn’t easy, but it is necessary for compliance and to be honest, it is really a best practice for protecting data.  If you are going to go through all the work of encrypting data, then you really should make sure the keys safeguarding the data are also secure.  I talked a lot about our encryption key management solution, Alliance Key Manager (Enterprise and SQL Server editions), at the Expo and thought it would be worth recapping some of the discussion for those who couldn’t be there and are facing encryption key management requirements of PCI DSS.

1) Manage and store encryption keys on a certified appliance.  Our encryption key management solution ensures encryption keys are stored away from the encrypted data, it allows you to satisfy PCI requirements for dual control and separation of duties.  QSA auditors will look to make sure the same person who has access to encrypted data doesn’t have access to encryption keys (dual control).   It is important to restrict access to certain keys by certain users or groups (separation of duties).  You don’t want the same person who has access to encrypted data to have have access to keys that unlock that data.

2) Rotate encryption keys. PCI DSS states that you need to periodically rotate the encryption key. This can be a very time consuming task if done manually and may even be overlooked because it can be a very complex project, depending upon your encryption code. Our encryption key management solution allows you to schedule regular key rotations and enforce your internal security policies while meeting PCI requirements.

3) Log all encryption key activity.  Alliance Key Manager has built in logging, which allows administrators to track all key retrieval, management, and system activity. Reports can be sent automatically to central log management, alerting facilities, or SIEM products for a timely and permanent record of activity.

4) Certification.  Our encryption key management solution is FIPS 140-2 Level 1 certified, ensuring you are effectively managing keys to industry standards.   

5) Don’t let cost be a barrier to meeting compliance requirements. If you have looked at key management solutions, you know they can be costly.  Alliance Key Manager (enterprise and SQL Server editions) are priced with the mid-market customer in mind. I think this was the fact that resonated with people I spoke with the most.  They were happy to hear about a solution that is easy to implement, as well as cost-effective.

We handed out this useful PCI DSS and Key Management matrix at the conference, several people found it useful. Download your copy to learn more about key management requirements. And if your company knows you need an encryption key management solution, give us a call. We are happy to spend a 15-minute technical overview with you and your team to find out how we can help you.

Last week we hosted a webinar titled “Encryption Key Management with Microsoft SQL Server 2008” and had excellent attendance!  The webinar covered meeting encryption key management compliance requirements on Microsoft SQL Server.  Patrick Townsend, Founder and CTO, discussed how our new hardware security module (HSM) is simplifying how organizations are meeting compliance requirements and how it removes cost as a barrier for a professional encryption key management solution. 

During the webinar we received some excellent questions that we would like to share.  As always, let us know if we can answer any further questions!

What are the performance impacts of encryption?

That’s a great question.  Encryption has a reputation for being very demanding from a performance point of view.  It doesn’t have to be that way.  We know from our own practice that encryption can be optimized and very efficient.  In the Microsoft SQL Server EKM environment, especially if you are using TDE, the SQL Server itself is doing the encryption of the entire table space and the encryption key manager is providing the vault and protection of the encryption keys.  Microsoft will tell you that TDE will impose about a 2-4% performance impact on your applications.  I think that is relatively accurate.  We have done our own testing with TDE and we come in closer to a 2% impact, and in some cases we come in even less.  Of course, you have to have the usual caveats.  Your applications and the size of your database may show you different results in terms of performance, but I think those are good numbers for guidance.  So, encryption is a pretty small impact on overall application environment for the protection that it provides.

Does your Enterprise Edition of Alliance Key Manager serve encryption keys to Oracle databases as well?

Yes!  We have customers today that are protecting data in Oracle databases using key retrieval libraries that we provide.  The same is true for MySQL, DB2, and other databases.  We provide a wide set of libraries to help customers protect data in any database.

How do you price your encryption key management for SQL Server solution?

The product is based on the number of key managers.  Depending on what customers need in the way of production and development environments, we provide a set of pricing plans to help them get into the technology in a very cost effective way.  If you would like formal pricing, let us know and we would be happy to schedule a call and see how we can meet your needs.

We are very focused on cost-effective solutions for our Microsoft mid-market customers.  We know that everyone’s resources are constrained these days.  We are philosophically committed to helping customers with cost-effective and FIPS-certified encryption key management solutions.

View our webinar "Encryption Key Management with Microsoft SQL Server" to learn more about utilizing Microsoft’s Extensible Key Management (EKM) interface in SQL Server 2008.

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.

Lately we are seeing an increase in questions around PCI requirements for encryption key management.  We are hearing from Level 2 merchants who are preparing for the June 30, 2012 deadline for companies that accept Mastercard. These companies are beginning to realize that they can’t just encrypt data to meet PCI requirements, they also need to securely manage their encryption keys.

To summarize the deadline, which is effective June 30, 2012, MasterCard Level 2 merchants have 2 choices for complying with PCI-DSS requirements.   

Option 1: They can complete an annual self-assessment questionnaire AND prove that a member of their organization has attended and successfully passed PCI SSC-offered merchant training program. 

Option 2: Businesses can elect to complete an annual onsite assessment conducted by a PCI SSC approved QSA.

Whether a business elects to certify a member of their team or undergo a PCI audit by a QSA auditor, they are becoming better educated about PCI-DSS requirements. Additionally, they are asking questions internally about how to meet requirements and seeking out answers to questions they can’t answer themselves. These Level 2 merchants are now starting to understand the NEED to be PCI complaint and realize how much they need to do. Townsend Security can help answer questions businesses have about data privacy and security because we focus on encryption and key management, which are discussed in section 3 and 3.5 of the PCI-DSS.

I talk to merchants on a daily basis around this topic and people understand the importance of encrypting data, but many don’t understand the need to securely manage their encryption keys. Storing your encryption keys on the same server as your data is problematic.  Before these new regulations Level 2 merchants weren't aware that PCI DSS requires separation of duties and dual control.  Quite simply, you don’t want the same person who has access to the encrypted data to have access to the encryption keys. Think of your encryption key as the figurative “key to the kingdom” - it unlocks the data that you have secured with encryption.  You wouldn’t lock your front door and leave a note saying the key is under the mat. You take your keys with you and only give keys to trusted people – the same philosophy should apply to the way you secure your encryption keys.

Level 2 merchants are realizing they need a secure server to protect their keys. They are researching encryption key management solutions and discovering our FIPS 140-2 certified Alliance Key Manager may be the solution they need.  

If your company is struggling with understanding PCI requirements for key management, download this whitepaper to learn more.  If you need a solution for key management and want to talk to a security advisor about the specifics in your IT environment, send us an email.  We are happy to answer your questions and schedule a 15 minute technical overview. 

I'll also be at the PCI Conference next week in Scottsdale, AZ so make sure to stop by our booth and say "hi".

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.

Welcome to our final installment in the "Data Privacy for the Non-Technical Person" series.  In case you missed the other two blogs in this series, here are the links to part one and part two.  This third and final blog will cover data privacy compliance regulations and how an organization would begin to develop a security policy.

We hope that these blogs have been informative and answered questions that you might have had about data privacy.  If you still have questions, please feel free to send us an email.  Additionally, download our podcast "Data Privacy for the Non-Technical Person" to hear my conversation with Patrick Townsend, Founder & CTO, in its entirety.

Are there are any laws or regulations requiring businesses to protect their sensitive data?

Yes.  There are quite a number of laws, and they cross over each other too.  Many find themselves having to work with several regulations when protecting data.  If you take credit cards, you fall under the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a private regulation promoted by the card brands (Visa, MasterCard, etc.).  If you are a bank or engaged in the banking industry you fall under the Gramm-Leach-Bliley Act (GLBA) and FFIEC regulations for protecting information.  Those are specific to the banking industry.  If you go to the doctor or are a doctor/medical clinic or any place in the medical industry, you fall under the HIPAA/HITECH Act to protect patient’s medical information.  There are also other regulations too.  The government is moving laws through congress to define protections for PII.  So there are a number of regulations affecting data that needs to be protected.

So how would an organization begin to develop a security policy?

This is a real challenge, particularly if you are starting for the first time.  It can seem overwhelming, especially when we read about the sophistication of data breaches and the attacks on companies.  Keep it simple to start – there are things that you can do to that are very effective upfront and know that you are vulnerable.  I think one think that sometimes inhibits people from taking action is thinking that they are not going to be subject to a data breach.  That is a dangerous attitude.  So, keeping it simple, taking simple steps, ranking where the vulnerabilities are and doing those things first are really important things.  There are really the obvious things like making sure you have good anti-virus software running on your computers and using good, strong passwords.  If you have a web site, there are scanning tools that will help you scan to see if your web site is secure.  And if your business is handling sensitive data, run background checks as part of your new employment procedures.  Finally, there is some online help that can be really useful for most people – sans.org is a place where you can go to get basic policy information and educated on threats.  For business that need to secure data, we have a lot of resources on our website to help you understand the various regulations and what encryption and key management tools you can use to begin protecting your data.

Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

This week brings part two of the "Data Privacy for the Non-Technical Person" series.  Last week we determined what constitutes personal information that needs to be protected.  This week Patrick Townsend, Founder & CTO, talks about how organizations are protecting sensitive information, how encryption and key management relate to each other, and what happens when encryption is not done correctly.  If you are jumping in mid-stream, you can read part one here.  Additionally, you can download our podcast titled "Data Privacy for the Non-Technical Person" to hear our conversation in its entirety.

How do organizations protect sensitive information?

They use a number of techniques.  Some of them are pretty obvious.  Businesses use anti-virus software and software to detect intrusions on their network, as well as making sure they have a secure web site if they are taking sensitive information from you over the internet.  And then they do some things that most people might not be aware of.  A business that is trying to protect your personal information will do some things that are procedural in nature – for example a lot of companies will now make sure all new employees have a background check.

Companies are also doing things that help make their data very difficult to steal.  Encryption, which is the process of taking a credit card or social security number and turning it into and encrypted value, makes stealing data near impossible.

Companies who are really trying hard to protect information of their customers and employees are deploying a variety of tools.  Encryption is probably one of the more important ones and it is one of the more difficult technologies to deploy, but certainly all of the major companies that you might do business with over the Internet will be using encryption to protect your data.

Encryption and key management have been talked about a lot lately.  How do they relate to each other?

Encryption and key management go together.  They are very complimentary technologies.  When you encrypt a credit card number, you have an encryption algorithm that takes your credit card number and turns it into something totally different.  But another important input into that process is a secret key.  Many people think that the encryption algorithm itself is some kind of secret mechanism, which isn’t the case.  Encryption is well understood.  There are standards for it and it is readily available.  What is really the secret that prevents losing data is the encryption key – just like the key to your front door is what protects your house.  An encryption key works very much in the same way.  Companies that use encryption really have to create a key that is very unique and very strong, and they have to protect it so that it doesn’t escape into the wild. Anyone that has the encrypted data and the encryption key, really can get the sensitive data back.  In the real world of protecting data with encryption, measures are taken to protect the encryption key – that is the real secret that people are trying to protect in a business environment. 

What happens when encryption is not done correctly?

There are many ways that encryption can be done poorly or incorrectly.  We see that sometimes around the area of encryption key management.  For example, storing an encryption key on the same platform where the data that it is protecting is just bad practice.  Sometimes you hear the term “integrated key management” or people say “we are storing the encryption key in a database file and we have locked that database file down.”  These are really poor practices and, in fact, cannot meet compliance regulations about encryption key management.  So, that is just one example of encryption that is done badly.

Other examples are just using non-standard or proprietary encryption.  The CUSP mode of AES encryption, for example, is not a standard mode and is a proprietary protocol that can’t be a part of true compliance.  It is just another example of running off the rails in terms of best practice for encryption.  A company that is purchasing encryption technologies should really examine their vendors carefully.  I always point back to NIST certification because it is the bottom-line indication you have that the encryption product is a good quality solution. 

Here is another interesting thing that I think people sometimes forget.  If you have a data loss, it is going to be your problem, not the vendors problem.  Even though you may have acquired a solution that is not right, it is still going to fall on you.  It is going to be your headache to solve, your customers that are upset, and your financial loss when data gets out.  The loss of trust from your customers and employees is also difficult too.  For all these reasons, I think paying attention to encryption technologies is a good idea.

Stay tuned for our next and final installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

Alliance Key Manager for SQL Server

Today we are excited to announce the availability of our new Alliance Key Manager for SQL Server (AKMSS). AKMSS is a certified Hardware Security Module (HSM) that manages and protects access to your encryption keys.

Our new HSM is focused on providing mid-market Microsoft SQL Server customers and their technology partners with an affordable, easy to deploy, solution for meeting data privacy compliance requirements in PCI-DSS, HIPAA/HITECH, FFIEC and other data privacy regulations. Unlike other HSMs on the market, AKMSS is built, tuned and priced specifically for small and mid-size SQL Server customers who need to protect sensitive data in their databases.  AKMSS comes with a standard Windows interface so it is easy to configure, deploy, and operate.  AKMSS is based on proven technology that is already successfully used by thousands of customers worldwide.

Townsend Security built this HSM with the idea that cost should not be a barrier to data privacy compliance.  We know that small and midsize companies are increasingly feeling the pressure to meet data privacy compliance requirements, and at the same time many are being targeted by data thieves.  Our AKMSS HSM will help small and medium-sized businesses meet data privacy requirements for encryption key management with FIPS 140-2 certified appliance.

Some of the features and benefits of our AKMSS HSM include:

• Out-of-the-box integration with SQL Server 2008
• Utilizes Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008
• Based on our FIPS 140-2 certified AKM software
• Reduces cost as a barrier for a professional data privacy compliance
• Built to be integrated - the product is ready for partner integration

If you need key management for the Microsoft SQL Server world, please take a moment to contact us and see how you can add industrial strength compliance to your encryption project.

You can learn more about the solution here.  Additionally, we have a webinar titled "Encryption Key Management with Microsoft SQL Server 2008" that shows just how easy encryption key management can be on your SQL server.

John Earl, President & CEO

Mid-size companies are under attack like never before, and breaches and financial losses are on the rise. The attacks are usually not that sophisticated - we are talking about the usual security weaknesses which include the lack of encryption and good encryption key management. So, if we know what the problems are, why are so many companies still vulnerable?

I think I know a big part of the answer: cost and complexity.

Mid–market companies are very sensitive to the cost of any IT project that does not contribute directly to the bottom line. And the more complex a project is, the higher the cost. For better or worse, encryption is viewed as a terribly complex, time-consuming, and costly project. Despite the obvious financial pain that a breach causes, and despite the fact that compliance regulations such as PCI DSS, HIPAA and the HITECH Act, GLBA and FFIEC, and state privacy laws encourage encryption and provide safe harbors when it is used, it just doesn’t get done.

Alliance Key Manager for SQL Server

That’s why I am really happy about our announcement today of an affordable and easy-to-deploy encryption key management HSM solution for Microsoft SQL Server. Building on our existing FIPS 140-2 certified Alliance Key Manager solution, our new encryption key management HSM offering for Microsoft SQL Server puts encrypting sensitive data within the reach of any company. With an affordable entry point, it can fit within the budget of most companies. And enabling encryption in the database does not require expensive programming resources. Your database administrator or your favorite solution integrator can get the job done very quickly. You can find out more about Alliance Key Manager for SQL Server here.

Microsoft deserves a lot of credit for opening the door to easier compliance. The SQL Server Extensible Key Management (EKM) architecture provides a straight-forward path to implementing encryption and key management. EKM is the strategic architecture for encryption in current and future releases of SQL Server.  With the Transparent Data Encryption (TDE) option of EKM, they even made the process simple to deploy. Microsoft created a door for third party vendors of key management HSMs to enter, but there have been few entries in this area. Our new Alliance Key Manager for SQL Server HSM will knock down those cost and complexity barriers for mid-market companies.

Independent Software Vendors and Solution Integrators are also a very important part of the Microsoft SQL Server ecology. Software developers have created thousands of applications on top of SQL Server, and mid size companies look to ISVs to solve difficult compliance issues for them. Along with our release of our HSM for SQL Server, we are inviting ISVs to join our partner program and realize the benefits of simple and cost effective data protection. We are making it easy for ISVs to integrate encryption and key management directly into their applications. Partners can get more information here.

Lastly, did you know that SQL Server is the data store technology for many of Microsoft’s products? For example, SQL Server is the underlying data store for Microsoft SharePoint and Microsoft Dynamics. With SharePoint 2010 you get full support for SQL Server EKM encryption. Worried about sensitive data in your SharePoint collaboration environments? There’s a solution for that!

I will be writing more about our new SQL Server HSM for encryption key management over the next few days. There are some really nice features in the product that deserve a deeper look. For more information on view our webinar "Encryption Key Mangagment with SQL Server".  This webinar is informative on just how easy it is to implement encryption key management on your SQL server. 

Patrick