Townsend Security Data Privacy Blog

As we wrap up our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, finishes the conversation by speaking on special requirements for an encryption key management HSM and how Townsend Security can help organizations running SQL Server 2008 with their encryption project.  If you are jumping in to the series right now, you can read part one and part two for the earlier parts of our conversation.  Here is the final part of our discussion:

Download Podcast Now

Are there any special requirements for an HSM?

HSMs are very specialized devices.  It takes a certain type of development approach to create systems that protect encryption keys.  There are well-defined processes by which encryption keys should be created, managed, stored, and protected by other encryption keys.  All of that is a very special security practice by vendors who create HSM solutions.  It is a very highly specialized practice.  Even the way you build and program for an HSM is quite different than you would build or develop a standard business application.  So, first off, there are really best practices on how HSMs get developed. 

Secondly, there are standards for HSM devices.  The National Institute of Standards and Technology, or NIST, produces a FIPS 140-2 certification and specification for cryptographic modules.  Vendors of HSM solutions can have their products certified to the FIPS 140-2 standard.  Any serious vendor will undergo FIPS 140-2 certification.  It is a requirement by the US government and any federal agency that is protecting encryption keys must use a FIPS 140-2 certified solution.  In private industry, it is a well-recognized standard.  I can tell you from personal experience that it is a very tough process.  There is a lot of scrutiny over how you have implemented key management, and as a result, only the best vendors attain a FIPS 140-2 certification.  We are proud to have achieved this status with our encryption key management appliance.

How does Townsend Security help organizations running SQL Server 2008 with their encryption project?

First, we do have an encryption key management appliance called Alliance Key Manager.  It is designed to be the Fort Knox for encryption keys.  It helps our customers meet encryption best practices with an HSM solution.  It carries the FIPS 140-2 certification that customers demand.

Secondly, it connects very easily to Microsoft SQL Server 2008 – including the upcoming SQL Server 2012 which was code named Denali.  It is easy to deploy and SQL Server customers will find it very straightforward to install.  It understands EKM configurations and automatically mirrors them and backs them up in a High-Availability (HA) environment.  All of that is done through very straight-forward GUI applications. 

Additionally, our encryption key management solution provably meets industry standards, is easy to deploy, and cost-effective.  We are really trying to help the Microsoft mid-market customer who may have one or two SQL Servers get into an HSM solution that really will fit their budget.  Our cost-effectiveness is one of the things we are bringing to the market that is brand new.  We look at key management HSMs as something that every organization should be able to deploy to protect their data. 

Finally, we do a lot to automate the entire key management process.  Keys can be generated and then automatically rolled to meet compliance regulations.  These components are core to our strategy of making encryption key management and the deployment of HSMs with the Microsoft EKM environment a straightforward and reasonable thing to do.  It really will help a whole range of customers meet encryption key management best practices quickly and with an affordable solution.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

As our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, resumes the conversation by speaking on who would need to use Extensible Key Management (EKM) and what part a Hardware Security Module (HSM) plays in this environment.  If you are jumping in to the series right now, can read “Encryption and Key Management on Microsoft SQL Server 2008- Part 1” by clicking on the link.  Here is part two of our conversation:

Who would need to use Extensible Key Management (EKM)? 

Download Podcast Now

Almost anyone who stores sensitive data in a SQL Server database should be considering encrypting that data to prevent its loss.  We are all familiar with the data breaches.  Some of them have been very well publicized – Sony and Citigroup, etc.  Losses happen to large and small companies alike, and it is quite damaging financially and to the reputation of a company to have a loss.  Anyone who is storing sensitive data in a database should be considering using EKM to protect that data.  If you are in a retail environment and are taking credit cards, you fall under PCI DSS rules and should be encrypting that database.  If you are in the medical segment you fall under HIPAA and HITECH Act rules.  Patient information that is stored on your SQL Server should be encrypted.  Finally, anybody who falls under a state privacy law – which is almost everyone – and are storing Personally Identifiable Information or PII, such as social security numbers, drivers license numbers, military IDs, etc. could benefit from using TDE and EKM.

So, any company who falls under compliance regulations and needs to protect sensitive information from loss and wants to minimize their risk should be using Encryption Key Management (EKM).  Microsoft, through their EKM architecture, makes it really easy to accomplish, it is relatively inexpensive and is very cheap insurance to help protect your data against loss.

What part does a Hardware Security Module (HSM) play in this environment?

HSMs are the Fort Knox for encryption keys.  Good security practice across all regulations requires that you take extra steps to protect your encryption keys.  The real secret that you are trying to protect is the key that you have used to encrypt that data.  Protecting encryption keys is the biggest challenge and most important part of an encryption strategy, and that is exactly what an HSM does.  HSMs create keys, protect them from loss, manage them through their lifecycle, and deliver them to applications that need them, such as EKM in the SQL Server environment.  HSMs are a very crucial part of your encryption strategy and that is why Microsoft and security professionals recommend using an HSM.

In the compliance arena, if you are undergoing PCI DSS assessment, there is not an explicit requirement for an HSM, but there are explicit requirements for “Separation of Duties” and “Dual Control” as applied encryption key management.  When you begin to look at requirements to achieve “Dual Control” and “Separation of Duties” you quickly come to the realization that you HAVE to separate the encryption keys into a separate environment and that is exactly what our encryption key management appliance does.  So to effectively meet security and compliance requirements you need to deploy an HSM to protect encryption keys.  It is a fundamental core principle in an encryption strategy.  Trying to bypass that by the local storage of keys, or storing them in the clear on another server, will not meet compliance regulations nor meet security best practices.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

I was recently able to sit down with Patrick Townsend, our Founder and CTO, to discuss Microsoft SQL Server 2008 and what Microsoft customers should be thinking about when using Transparent Data Encryption (TDE) and Extensible Key Management (EKM).  Additionally, we talked about the role of an encryption key management appliance in regards to meeting compliance regulations such as PCI DSS, HIPAA/HITECH, etc. and what to look for when selecting one for your organization.  Here are a few questions from our conversation:

What is Extensible Key Management (EKM) on Microsoft SQL Server 2008?

Download Podcast Now

Microsoft introduced a new architecture for database encryption with SQL Server 2008.  It was a new architecture and a new way of approaching integrated database encryption. SQL Server 2008 had the first implementation of Extensible Key Management (EKM), and it is implemented in SQL Server 2008 R2, and the just announced SQL Server 2012. 

The real significant part of this is that Microsoft understood that there was a need for a new architecture for encryption, that it had to be standardized, and that it had to integrate third-party Hardware Security Modules (HSM) for encryption key management and protection.  So that is what EKM is.  It really has two primary components.  The first one is Transparent Data Encryption (TDE) and the second component is Cell Level Encryption. 

So, TDE is a brand new type of implementation under EKM.  TDE automatically encrypts the entire table space in a SQL Server database and it doesn’t require any application modifications.  It is a really great and easy way to implement encryption in your database.  Cell Level Encryption or Column Level Encryption is the second component.  It gives you the ability to pick a particular column in a SQL Server database and encrypt that column.  Cell Level Encryption does require modifications to your SQL applications, so it has a little more of an impact from the point of view that it takes a developers time to implement it.

Both TDE and Cell Level Encryption, under EKM, give you the ability to plug in a Hardware Security Module (HSM) to protect the encryption keys.  Microsoft also recognized very clearly that proper encryption of a database requires protection of the encryption keys in an appliance or HSM. 

Now that we know what EKM is, how does it work? 

It is a facility within SQL Server 2008, Enterprise Edition and above.  It isn’t activated until you explicitly activate it.  When you decide that you want to place your database under encryption control you go into the standard database administrators console for managing SQL Server and you define that you want to implement encryption through an EKM provider and specify how you want to manage your encryption keys.  You then place the database under encryption control.  It is really a simple process for implementing TDE.  In fact, we recently created a video titled “Setting Up TDE & EKM on SQL Server 2008” showing how easy it is.

Cell Level Encryption requires a couple extra steps to modify your SQL code, but the basic architecture is pretty simple.  Once you decide how you want to do it, you create encryption keys and you turn on EKM through an EKM provider.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

As a security company, it always puts a smile on our face when we see people properly protecting their (our) data.  Microsoft made this much easier for organizations running Microsoft SQL Server 2008 with Transparent Data Encryption (TDE) and Extensible Key Management (EKM).  By using TDE, EKM, and an encryption key management appliance, proper encryption and key management is now affordable to even small and medium sized businesses.

As recently as last month I had a small organization tell me, “I just pay the PCI fines.  It is part of my monthly budget and cheaper than doing encryption.”  This sort of thinking is making less and less sense these days.  Today, we can tell these smaller organizations that encryption and key management is now affordable and that we have a solution that was built specifically for their SQL Server.

I recently sat down with Patrick Townsend, our Founder & CTO and asked him what Microsoft customers should be thinking about when they consider using TDE and EKM on Microsoft SQL Server 2008:

A number of questions pop up right away for Microsoft customers when they start thinking about SQL Server EKM.  The first question is usually, “What is the performance impact going to be?”  I think Microsoft has done a great job of minimizing the performance impact using TDE.  Microsoft says that you will see about a 2-4% additional load on servers when you implement encryption.  In a practical sense, and from our customers, I think those are pretty good numbers.  There is some impact on doing encryption, but it is probably much less than you might think.  The performance impact has been really minimized by Microsoft in this approach.  Cell Level Encryption will have a little bit higher performance impact, but most people will use TDE and that has a very good performance profile for encryption.

I think the other thing to think about, if you are going to implement encryption using EKM is to address the key server question right up front.  Even though Microsoft gives you the ability to store an encryption key on the local server, it is not considered good security practice and Microsoft recommends the use of an HSM to protect encryption keys.  You should be thinking about using an appliance or HSM as you go forward to protect your encryption keys and give you the best security practice from a compliance point of view.  You don’t want to go down the path of implementing encryption and not following security best practices.  If you have a data breach, you are going to have to defend the approach that you took if you are trying to avoid legal liability and the cost of breach notification.  Using a proper key server should really be a no-brainer.  It is the right thing to do and the right approach.

Finally, an organization needs to look at the affordability of an encryption key management appliance.  In the past, I think one of the real barriers for encryption has been the very high cost of acquiring HSM technology.  I am very proud of our company for really beating down those costs and making them much more reasonable in terms of creating affordable HSM solutions.  With our solution, every mid-market to large-enterprise customer now has HSM technology within their grasp that is affordable and easy to deploy. 

Download our podcast “Encryption Key Management with Microsoft SQL Server 2008” to listen to our complete discussion and learn even more about TDE and EKM.

IBM i (AS/400, iSeries) users send a lot of sensitive information to their customers, vendors, and employees which needs to be protected with strong encryption.  Our customers today are using our PGP encryption solution to protect files. But there has been a big need to generate and protect information in common PC formats. With our managed file transfer solution, Alliance FTP Manager for IBM i, we stepped up our support with encrypted Zip files and encrypted PDF files.

Zip compression is very commonly used to send files via email. Not only does Zip compression make our email attachments smaller, but the most popular Zip compression programs now support 256-bit AES encryption of the contents. The ability to encrypt Zip files with AES provides a much better level of security than older Zip protection methods.  Alliance FTP File Manager for IBM i fully supports Zip encryption to the WinZip standard. This means that you can create and protect Zip files on your IBM i platform, and then use a variety of delivery methods to get the Zip files in the hands of your customers, vendors, and employees. This functionality gives IBM i customers a powerful tool to meet compliance regulations.

Encrypted Zip support in Alliance FTP Manager provides rich capabilities to IBM i users. You can create encrypted or un-encrypted Zip archives, include sub-directories, and use wild cards to select files.  When uncompressing and decrypting, you can specify any directory as the target for the files. This capability integrates with our automation facilities for processing received files. Lastly, we provide a Windows command line Zip application to help our customers who don’t already have a Zip application.  I’m confident that this capability will help customers achieve a better level of security.

Another security technology in FTP Manager for IBM i is our encrypted PDF support. In this implementation, our customers are able to create encrypted PDFs with their own content, and then use the automation facilities to distribute the PDFs via email, FTP, and other distribution methods. Encrypted PDF support includes the ability to set fonts and colors, embed watermark and graphic images, set headers and footers, and create tables and lists. The resulting encrypted PDF file is compatible with any PDF reader that supports the AES encryption standard for PDF. We’ve tested with a wide variety of PDF readers on PCs, Apple Macs, Blackberry, Linux desktops, and so forth. This gives our customers an additional tool to secure their sensitive data.

These technologies for the IBM i customer increases their abilities to meet compliance regulations and secure sensitive data. I hope you get the idea that we are dedicated to helping you protect your sensitive data and corporate assets. You are going to see a lot more of these types of capabilities as we go forward.  For more information on our managed file transfer solution, view our webcast "Secure Managed File Transfers on the IBM i."

In V7R1 of the IBM i (iSeries, AS/400) operating system, IBM introduced support for automatic, column-level encryption in the DB2 database call FIELDPROC (short for “Field Procedure”). For customers who are familiar with other automatic database encryption implementations such as Microsoft SQL Server Extensible Key Management (EKM) and Oracle Transparent Data Encryption (TDE), the new DB2 database implementation can be confusing. The encryption implementation in DB2 is quite different from other vendor implementations. Here are a few highlights of those differences:

FIELDPROC is not encryption, it is an exit point. What IBM is providing with FIELDPROC is the opportunity for you, the customer, to implement encryption at the column level. You have to enable the option, provide the IBM i AES encryption software, and do the implementation yourself. This is different from SQL Server and Oracle TDE where the database does the encryption for you.

Operations are on encrypted data. In SQL Server and in Oracle, the database is decrypted and then the SQL operations take place on the plaintext values. Not so in DB2 FIELDPROC. The necessary information is first encrypted, and the operation takes place using the encrypted value. This can lead to some surprises if you are not careful about your approach to AES encryption and Initialization Vectors.

Decryption might not be called on a read operation.  Some IBM i customers are surprised that FIELDPROC may not be called when doing a “read equal” type of operation. In SQL this can happen in a SELECT clause with a WHERE statement. In the RPG language this can be a CHAIN operation with a key value. The DB2 database will call the FIELDPROC application to encrypt the search value, but not call the FIELDPROC application if the search is satisfied. That will defeat your attempt to do data masking on decryption!

Database joins need special care. Database joins take place on the encrypted values, not the decrypted values. This means that identical values in different tables need to have the same encrypted value. This runs counter to normal encryption thinking in database tables.

FIELDPROC applications are dynamic calls.  The FIELDPROC applications that you or your vendor creates are going to be called dynamically from the database engine. This means that when you develop the FIELDPROC application you have to take special care that they perform exceptionally well, and that your encryption library is optimized (see next item).

Not all AES encryption libraries are equal. There are big performance differences between AES encryption libraries and it can mean a really big difference to your FIELDPROC application performance. We’ve noted before that AES encryption library performance can vary by a factor of 116. That difference can mean a batch job that takes 10 hours or 10 minutes. Be careful!

For further information view our webinar "Automatic Encryption on IBM i V7R1" and learn how Automatic Encryption is now possible on IBM V7R1 with AES/400.

Patrick

Last week we held a well-attended webinar titled “Secure Managed File Transfers” Meeting Compliance Regulations.” The webinar covered meeting the data in motion requirements of PCI DSS, HIPAA/HITECH, and other regulatory compliance requirements with Alliance FTP Manager, our secure managed file transfer solution for the IBM i.  During the presentation we received several great questions that we’d like to share with you on our blog.  As always, if you have any additional questions, send them our way.

Is there a reason why I shouldn't use PGP on windows? I can just transfer my file from IBM i to windows and then PGP encrypt it there. Does this make sense?

Yes, I fully understand why customers would want to take that approach, however if you are under PCI DSS regulations you would be out of compliance. The transfer of sensitive data across a network and then landing unencrypted will take you out of compliance, even if you encrypt it later. There is no question about that. That is a situation we have been remedying for customers for a number of years. The security best practice standard is to encrypt at the source and decrypt at the destination. So you need to avoid the transfer of unprotected data through internal servers or across any network. You really want to make sure that the encryption is in place and that the data lands encrypted.

Can managed file transfer be used on just one side or do both sides of the transfer have to have the same software?

Good question, first off, I'd like to point out that managed file transfer is a term of art. There is no formal definition, no RFC, no NIST standard. So for this answer, you're going to get my opinion on this. In our managed file transfer solution there are absolutely no requirement that a recipient of an encrypted file or a secure transfer needs to have our software. Our solution is based on open standards and no customer ever needs to deploy software in order to process a transfer. Open standards give you many software choices and give your trading partners a lot of choices on what they want to use.

Regarding Open PGP implementation, which RFC or RFC's do you follow? 

Well there are a couple. There is an original RFC2448  and there is a later RFC4884. Our commercial PGP product from Symantec is compliant with all of those standards - so the original and newer PGP RFC's are fully supported in our commercial product. Therefore we stay well lined up with those particular standards. Of course, there are some capabilities in the commercial product that are not defined as a part of the open standard - they are an extension if you will. There are a number of capabilities in the commercial version that really help larger enterprises stay lined up with compliance requirements and meet best practices. Those are built on top of full compliance with open standards.

View a recording of our webinar Secure Managed File Transfers: Meeting Compliance Regulations for more information on meeting data in motion requirements of PCI DSS, HIPAA/HITECH, and other compliance requirements on your IBM i.

The recent news of SAIC being dinged for not protecting US military TRICARE medical information with standard AES encryption and suffering a data loss is interesting. While the details are still thin, it appears that the data was encrypted, but not with a standard AES encryption method. The HITECH Act proposed data security rules make specific reference to AES and other NIST standards.

We don’t know which encryption method was used to protect the data. It could have been a home grown method of encryption, or it may have been a widely accepted encryption method that was just not a part of NIST standards. But it apparently doesn’t matter. If you are not using a NIST standard method of encryption, you are in violation of the compliance requirements.

I think it is going to take some time for the implications of this to settle in. Here are some rather unorganized thoughts:

Over the last two years I’ve seen at least FOUR instances of vendor “AES” encryption solutions that actually weren’t AES encryption. In one case, a point-of-sale vendor implemented an AES encryption library with a 256-bit AES block size. The AES standard (FIPS-197) only allows the use of a 128-bit block size.  The company running this software had no idea that they weren’t actually running an industry standard method of encryption.

In another case a customer was running AES encryption with a non-approved mode of encryption. The underlying encryption library was AES, but the mode was not a NIST-approved mode of operation. This was a distinction lost on the company running this “AES” solution. But it seems likely to me that they were out of compliance and at risk in the same way SAIC was. This company is going to have to rip out the current solution and replace it with something that is actually compliant. That seems like such a waste of time and resources.

In one of these cases the software was provided by a “security” vendor. This vendor sells encryption and key management software specifically to meet encryption compliance regulations. That’s very sad.

With the best of intentions and with deep knowledge of encryption protocols, you can still make mistakes when developing an encryption solution. It is hard to get this right. And weak vendors without the commitment and passion to get it right represent a risk to everyone. So, if you are a vendor of encryption solutions, what do you do to insure that you are getting things right? You learn to not trust yourself so much, you invest in independent review of your solutions, and you invest in independent certification. Today we would never release an encryption product without subjecting it to NIST certification and independent review.

If you are a company facing an encryption project, how will you select a security vendor for your encryption libraries and encryption key management solution? How will you know that their AES encryption is really based on the NIST standard? Are you ready to trust the claims of a sales person? I wouldn’t, and I don’t think you should, either. If a security vendor can’t show you a formal NIST AES Validation certificate, or a FIPS-140-2 certification, you should run for the nearest exit. You just have way too much to lose.

If you think that the HITECH Act is unique in its reference to NIST standards, have a look at the proposed Federal Privacy Law (Senate Bill 1151) that passed out of the Senate Judiciary committee last week. It is likely to empower the FTC to propose standards for encryption and encryption key management, and the FTC is likely to look to NIST for these standards.

The writing is on the wall, or rather, it’s on the Internet at www.nist.gov.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Patrick

In part one of "HIPAA, HITECH Act, & Encryption Key Management" I sat down with Patrick Townsend, Founder & CTO, to discuss discuss the increased focus on HIPAA and the HITECH Act and the different types of encryption an organization could use to satisfy these requirements.  In part two, Patrick speaks on the benefits of encryption to organization in the health care industry, what the Department of Health and Human Services has to say, and finally how Townsend Security can help meet HIPAA and HITECH requirements for encryption and encryption key management.  Here is the second part of our conversation:

Download Podcast Now

Besides protecting patient information, does encryption provide any other benefits to the medical provider?

Yes, there is one particularly big benefit to anybody who is a covered entity, and that has to do with breach notification.  There is a breach notification requirement for anybody who loses patient data or thinks that patient data has been stolen from their system.  If you read the rules, there is no place where it says you must encrypt patient data – BUT- there is a section that says, if you have a breach, and if you have encrypted your data properly, there is a safe harbor from breach notification.  In other words, you don’t have to go through the expensive process of remediating the breach. 

So, there is a very, very positive practical benefit to any covered entity from using encryption, which is, if you have a breach, then that encryption will give you a safe harbor, or a way out from some of the more painful parts of breach notification.  Under breach notification, that information becomes public.  There can be fines levied around the loss of data.  Additionally, you must provide assistance to the patients whose information has been breached, which can be quite expensive.  In the credit card world, we know that the typical cost of remediating a breach is $214 per record, and now the average cost to an organization for having a breach is around $7 million.  So, the use of encryption and proper key management does have a very practical benefit to the covered entity itself in helping them avoid the more difficult and expensive costs of a breach notification.

What does the Department of Health and Human Services have to say about encryption key management?

Again, reading the rules, you will find references to NIST standards and best practices around key management.  It takes a lot of drilling down into the NIST best practices documents to really understand key management, but the information is there.  If I could boil it down to one really important concept, it is that managing encryption keys is the most important part of your strategy.  Protecting the keys is really what you do to protect the data.  So, implementing good key management is a core principle.  If you read the NIST standards, they talk about separation of duties, dual control, and split knowledge.  These are all concepts that have very real world implementations.

Dual control just says that when you are managing keys, you should have two people who must authenticate to manage encryption keys.  It makes sense if you want to avoid the potential for collusion around key management.  Separation of duties means that the people who manage data, or patient information, should NOT be the people who manage encryption keys.

These are the kind of concepts that auditors and others look for in a key management strategy.  In the real world, key management systems are very specialized appliances.  We are a vendor of general-purpose encryption key management solutions that implement these kinds of standards.  This is really how HIPAA and the HITECH Act approach the question about encryption key management.  Again, if you read the IFR’s, which become finalized later this year, they say to use encryption key management that is based on standards, such as NIST.

As a company that provides encryption and key management solutions, can you tell our listeners how these solutions can help them meet HIPAA and HITECH Act requirements? 

Traditionally, encryption key management has been the more difficult part of an encryption strategy, which we are now making easy.  It can be the most expensive part and most difficult to implement.  I think we have done a great job of creating affordable and cost-effective key management solutions, which are FIPS 140-2 certified and work well in a variety of environments across a lot of platforms.  So, the first thing that we have done that’s really beneficial in the medical segment, is creating an encryption key management solution that is affordable to customers and that works well with partners who distribute solutions in the medical environment.  Our encryption key management solutions really help drive down the cost of doing encryption the right way.  Again, the NIST certification on the key manager is important to provably meet the standards called out by the HITECH Act and the rules that they have been promoting.

Secondly, we do provide encryption libraries for customers who need them, so if you need to do AES encryption, for example, which is a NIST standard, we have encryption libraries that are very cost-effective, highly tuned for performance, and will work well in small and large organizations within the medical segment.

Lastly, we have some solutions around secure transfer of data, including PGP encryption and secure transport of data using SSL/TLS technologies.  Again, these match well with HIPAA and HITECH Act requirements for encrypting data.  I think this broad set of key management and encryption capabilities really help our partners and our customers meet these requirements.

To hear this conversation in it's entirety, download our podcast titled "HIPAA, HITECH Act, and Encryption Key Management."

Last week Townsend Security exhibited at the PASS Summit and showed off our new encryption key management appliance.  This was our first time attending this show, and if you aren’t familiar with the PASS Summit, it is the world’s largest, most-focused, and most intensive conference for Microsoft SQL Server and BI professionals.  This year's show was the biggest conference to date with over 4000 attendees.

This was a good show for us.  The SQL Server community really understands the importance of encryption and key management.  Microsoft made encryption much easier with the introduction of Transparent Data Encryption (TDE) in SQL Server 2008 and opened the doors for proper encryption key management with Extensible Key Management (EKM).  With this combination, it is now easier than ever for organizations to be encrypting their sensitive data with “best practices.”

It was encouraging to see how many people were encrypting their sensitive data using TDE.  When we told them about our encryption key management appliance, their eyes lit up and said, “I need that!  We need to meet PCI DSS and get our encryption keys off of our SQL Server.”  We were more than happy to tell them how easy it is to start properly managing their encryption keys – both technically and financially.  Our client installs easily - just like any other application on SQL Server and set up is a breeze.  When the average cost of a data breach to an organization is over $7 million dollars, it is getting easier to justify the business case for proper encryption and key management.

Of course not everyone was encrypting.  Some people just didn’t need to.  Others though, when asked about encryption, hung their head and said “No, but I probably should be.”  And these were people in the medical and financial industries!  (Note to self: don’t give these organizations my personal information.)

The concept of “leaving your keys under the mat” really resonated with this crowd.  If they didn’t know the importance of separating encryption keys from the encrypted data before they visited us, they certainly knew it well by the time they left.  We look forward to attending this show again next year and maybe the people who currently aren’t encrypting our private information will be first in line next year telling us about their “nightmare audit.”

For more information on our encryption key management appliance, built specifically for SQL Server, 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.