Townsend Security Data Privacy Blog

IBM introduced FIELDPROC (Field Procedures) in V7R1 of the IBM i (AS/400, iSeries) operating system to provide for an automatic method of implementing encryption at the column level. While new to the IBM i platform, FIELDPROC is not actually a new technology. It was first implemented on the IBM System z mainframe platform about 20 years ago. But it is new to the IBM i and is now starting to get a lot of attention as customers start the upgrade process to V7R1.

The attraction of FIELDPROC is that it gives you a way to implement AES encryption on the IBM i without changing your application code. As long as you have an application that can perform key retrieval and encryption (IBM does not supply this) you are ready to implement FIELDPROC. 

But you should be aware of the one really big impact of FIELDPROC on your application – performance. A FIELDPROC program is called dynamically from the DB2 database engine. That is, it is not statically bound to the database, and it is not incorporated as a service program (dynamic ally linked library). The dynamic nature of the FIELDPROC invocation added on top of the encryption CPU load can lead to really bad surprises when you roll into production.

Before you deploy your own or your vendor’s FIELDPROC code, do some simple tests. I suggest that you do these simple tests on a database of 1 million records:

• Start FIELDPROC to place the entire table under encryption control.
• Read the entire database to force a decryption on every record.
• Update the encrypted field in every record to force a decryption and encryption for every record.

If you have multiple fields in a table under FIELDPROC control, you will want to do additional performance tests as well. If you encrypt 20 fields in the table, what will happen when FIELDPROC gets called 20 times with every database read?

We are a vendor of a FIELDPROC solution and I will share some results with you from one of our in-house systems. To line up with compliance regulations and encryption best practices, we used our FIPS-140-2 certified encryption key management appliance and our NIST certified AES encryption library. These results are not independently verified, but you can you can download the tests and try them on your system (always a good idea).

The Platform:

An entry level 9407 model 515 with a single POWER5+ processor, 1 Gigabyte of memory, two 70-Gigabyte model 4327 disk drives (no RAID), and a CPW rating of 3800. The latest V7R1 cumulative PTFs are installed. This is the slowest thing we have in the house.

The Database:

A simple, uniquely keyed DB2 database created with DDS and containing 5 character fields and one packed numeric field. One of the non-keyed character fields is encrypted with FIELDPROC. The file contains 1 million records.

Encryption Key Management:

Our FIPS-140-2 NIST certified Alliance Key Manager encryption key server installed on the local network. Our FIELDPROC application will automatically and securely retrieve the encryption key when needed.

Encryption Library:

Our NIST certified, optimized, 256-bit AES encryption software library.

The Application Environment:

No other applications running on the system at the same time; the system is in normal state (not dedicated); all applications are OPM model with no optimization; tests are run in batch.

The Results:

Start FIELDPROC to place the database under initial protection:

Read all records to force a decryption:

Update all records to force a decryption, an encryption, then an update:

I think this is a pretty good baseline of minimum performance our customers will see with our FIELDPROC solution. Most of our customers run with the more modern POWER6 or POWER7 processors which bring a lot more CPW power to the task (a new entry level POWER7 process has 10 times the CPW rating). More and faster disk drives and more memory will definitely help performance. So you should see substantially better performance in real-world environments.

I hope this provides some helpful guidelines for your FIELDPROC project.  Download an evaluation copy of our Alliance AES Encryption for FIELDPROC to see for yourself just how easy you can be protecting your sensitive data.

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."

HIPAA and the HITECH Act have been hot topics lately.  Why is that?  First, the U.S. Department of Health and Human Services has recently issued guidance stating “unsecure protected health information (PHI)” is essentially any PHI that isn’t encrypted or destroyed.  This means that no matter how much technology you throw at securing the data, if it isn’t encrypted, then it isn’t considered secure.  The second, and arguably more compelling reason, is that HIPAA-covered entities are required to send notification letters if there is a breach of unsecured PHI.  Only using proper encryption grants safe harbor in the event of a breach.

I recently sat down with Patrick Townsend, our Founder & CTO, to discuss HIPAA, the HITECH Act, and encryption key management.  Here is part 1 of 2 of his thoughts on this topic:

Download Podcast Now

With HIPAA and the HITECH Act, there seems to be an increased focus on encryption.

Yes, there really is.  The technology that everyone looks to for protecting PHI is encryption.  So, yes, there is a real focus on encryption.  It is important.  Everyone who is a covered entity within the definition of HIPAA and the HITECH Act really needs to focus on protecting their patient information.  Encryption is specifically called out in the rules for covered entities, whether you are a health provider, an HMO, or any organization that is within that arena of medical delivery.

Are there any specifications on what type of encryption an organization should use?

Yes.  The HIPAA and HITECH Act are pretty explicit in providing the standards that are the basis of the approach you should take.  If you read the rules, as they are today, which are due to be finalized this year, they point straight to industry standards in terms of the kind of encryption and the techniques you should use to protect data.  The basic recommendations, in terms of standards, are to look at the National Institute of Standards and Technology (NIST) for proper ways of doing encryption and key management.

While the regulations aren’t specific in saying “You must use XXX algorithm for your encryption” they say you must base your encryption approach on widely accepted standards.  Additionally, they make specific recommendations to NIST for those standards.  If you look at the NIST standards, which have been in place for a long time, they publish standards on encryption and key management.  The proper encryption for “data at rest” or database files is AES encryption.  So patient data, at rest, in any type, is typically protected with AES.

For “data in motion” or data that you are transmitting, like patient claim data or patient information, we have standard protocols.  PGP whole file encryption, for example, is a well-accepted mechanism for protecting whole files.  It has been FIPS 140-2 certified, which means it is provably based on NIST standards for encryption.  Also, using a SSL/TLS connection for protecting data that you transmit over a web site or a web connection is another standard that maps directly to NIST.  Customers who base their encryption on those particular technologies will line up with NIST recommendations and best practices, and therefore align up with HIPAA and the HITECH Act. 

There is also a set of standards around encryption key management.  NIST publishes the best practices standards for encryption key management.  You have Special Publication 800-57 and other Special Publications that go together that really talk about key management.  And you also have FIPS 140-2 certification.  So key management solutions that are FIPS 140-2 certified match up to these regulations. 

To summarize, you want to find technologies that are based on standards.  Certifications lend credibility to the claim that they are based on standards.  Any organization that needs to protect data should look for solutions that have FIPS 140-2 and NIST certifications to indicate they are properly based on standards.

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

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.

It was fascinating to read the headlines this week about the terrible flaw that was discovered in the Advanced Encryption Standard (AES). It sounded like the end of security as we know it. I read blogs and articles that headlined “AES Broken” and “Fatal Flaw in AES”. It was fun reading, but completely misleading. So, what really happened?

Three cryptographers (Andrey Bogdanov,  Dmitry Khovratovich, and Christian Rechberger) found a slight mathematical weakness in the AES encryption algorithm and published a paper on their findings. These aren’t hackers trying to break into systems. These are professionals in their field working on cryptanalysis projects. This is what the professional cryptographic community does, and we all benefit from their work. They are to be applauded for their findings as it advances our understanding of cryptography and cryptanalysis, and this leads to more secure systems.

What is the practical impact of their finding? Do we all need to bunker down in a newly insecure world?

No. There is no practical attack on encrypted data with these findings. The effect is to weaken 128-bit AES encryption to about 126-bit AES encryption. That is still plenty strong and we don’t have to worry about new attacks on encrypted data. Here is a really good description from William Hugh Murray in the SANS newsletter:

“While this is a significant analysis, worthy of a paper, perhaps even a headline, an attack using this information, begun at the Big Bang, would not have completed yet.  Kudos to the analysts.”

And I like this one from ScienceDaily.com (originally from a source at Katholieke Universiteit Leuven) even better:

“Even with the new attack, the effort to recover a key is still huge: the number of steps to find the key for AES-128 is an 8 followed by 37 zeros. To put this into perspective: on a trillion machines, that each could test a billion keys per second, it would take more than two billion years to recover an AES-128 key.”

The earth is due to burn up in about 500 million years, so we don’t have anything to worry about quite yet.

By the way, this work points directly at the value of using standards-based encryption. The cryptographic community does not work much on non-standard algorithms and propriety methods. If there is a weakness in an encryption method, we really want the good guys to find it. Weaknesses in non-standard algorithms and methods are likely to go undetected for a much longer period of time.

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Patrick

As I attend industry events, it is surprising how many times we hear questions like “what constitutes personal information that needs to be protected?”  I recently sat down with Patrick Townsend, our Founder and CTO to discuss data privacy for the non-technical person. 

When speaking about data privacy, the conversation often turns technical with common questions like “How do we implement encryption and encryption key management?”  This time, we intentionally kept our conversation focused on data privacy topics that can be understood from a high-level. 

I have created a series of blog posts from this conversation that will be posted in the next couple weeks.  Hopefully this blog series will answer any questions that you might have.  If you still have questions, feel free to send us an email.

What constitutes personal information that needs to be protected?

The first thing that everyone thinks of are credit cards numbers.  We know that we don’t want our credit card numbers escaping into the wild and having to go through the process of replacing them.  I think that by now, most people have experienced getting a call from their bank, being alerted to potential fraud, and going through the process of having to replace a card.  So credit card numbers are obviously personal information that people need to protect.

There are also other things that I think are important – financial bank account numbers.  We are all doing a little bit more now in terms of online banking.  Those bank account numbers carry value and we need to be very careful about that.  There are also some other items that tend to be used to commit financial fraud, such as social security numbers, driver’s license numbers, birthdate, etc.  In fact, information like your passport number, military ID, or health ID – all of those are examples of information that you should try and protect and make sure you are not sending them around or leaving them in places that can be easily picked up.

Other things like maiden name or previous addresses are also important.  Think about the types of questions your bank asks you when you give them a call.  They are using that information to identify you and the fraudsters will use that information to impersonate you.  These are all examples of sensitive information that we should be protecting.  For people who are interested, the technical term for this type if information is Personally Identifiable Information or PII.

Stay tuned for our next 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