Townsend Security Data Privacy Blog

In our final installment of questions from “Encryption Key Management with Microsoft SQL Server 2008” we tackle the topics of encryption key management in High Availability (HA) and disaster recover scenarios.  If you missed the first two blogs in the series, you can always go back and read about “The Performance Impacts of TDE on Microsoft SQL Server” and “How often do I need to rotate encryption keys on my SQL Server?”  If you still have any questions about encryption or encryption key management on your Microsoft SQL Server, feel free to send them our way.  It is always a pleasure to hear from members of the data privacy community.  Here is the last question in this series:

Can you speak to how encryption key management works in High Availability (HA) and disaster recovery scenarios?

An encryption key management solution becomes a part of your critical infrastructure if you are properly protecting keys.  If your key manager goes down, your applications stop functioning until you have key management back up.  We really address those concerns in a number of ways.  One way is that our key manager is built for redundancy.  We know it is hardware, and if it is hardware it can fail, so we implement a hardware platform that is resilient and has a lot of redundancy built in.  The first layer of keeping an encryption key manager up and running consistently is to have a good hardware platform.

Secondly, we build real-time mirroring of keys and policy around keys directly into the product.  You can actually deploy a high-availability failover key server with all key activity and access controls mirrored in real-time to a fail-over key server.  If you use SQL Server, you can define right in our software one or more fail-over servers.  For example, in SQL Server, through the configuration panels you can define multiple key servers for fail-over.  If you have a failed server, a hardware problem, or network outage, you can actually define fail-over servers and that will take place in real time.

Furthermore, there is a lot of resilience in the EKM provider software that we install on the Windows server so that if there is a software failure, there are some self-healing mechanisms there too.  If our module were to be killed off by the security administrator, it will get re-started automatically.  So there are a lot of redundancy and self-healing components built in to both the software and configuration components on the key server.

We have done a lot to help customers deal with the concern about resilience of a key manager because it is critical infrastructure, and we fully support that through real-time mirroring.  It is not an operating system feature.  The key server itself has implemented this mirroring capability.  It is itself self-healing.  So if two key servers are mirroring to each other and the network goes down, they will queue up those mirroring transactions, and when the network comes back, it will re-commit those changes.  Alliance Key Manager is a robust facility for making sure you have good backups of your encryption keys.

This concludes our series of questions from the recent webinar “Encryption Key Management with Microsoft SQL Server 2008.”  We encourage you to view the webcast and learn even more about how easily and affordably you can begin meeting data privacy compliance requirements with encryption and encryption key management.

Yesterday, our partner, Symantec, released a survey on enterprise encryption practices.  The study contained both good news and bad shows when it comes to encryption and key management.  

First the good news, in a recent interview with eWeek Tim Matthews, senior director of product marketing at Symantec said, “About 48 percent of the survey participants reported their organization had increased their use of encryption over the past two years, with one third reporting "somewhat to extremely frequent" deployments of "rogue" projects without any centralized management oversight.”

Now the bad news, Tim Matthews goes on to say, “Business groups and employees are often independently encrypting the data without involving the IT department. While the move to encrypt is a good thing, these unauthorized deployments are a challenge for IT because the data is lost and irretrievable if the employee loses the key, forgets the passphrase or leaves the company without passing on custody of the encryption keys. If IT doesn't have the key, it also becomes harder to properly backup the data or to access the information as part of an e-discovery request”

We understand the difficulties in managing encryption keys and have been helping companies for years with this challenge, so when we saw this statistic about poor key management, it did not come as a big surprise to us, because we hear about the challenges first hand.  The study showed:   “About 52 percent of the respondents said they have had serious key management problems, with about a third claiming that keys were lost or misplaced keys and another third citing key failure. A little over a quarter, or 26 percent for the participants, said former employees refused to hand over keys when they left the company.”

We have posted several different checklists for companies to help them in their selection of key management vendor. One of our more popular lists is the 10 questions that you should ask your potential key management vendor. Given the news in the study, we thought it was worth showing this list again:

1. Is your key manager FIPS 140 certified?  What is the certificate number?
2. How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?
3. Is there a common key retrieval application interface on all platforms?  What are the differences?
4. What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)
5. Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)
6. Do you supply binary libraries for all Enterprise servers?
7. Do you have a Java key retrieval class and examples? Is it standard Java or JNI?
8. Do you charge separate license fees for each client operating system?
9. Do you require that we purchase consulting services from you?  Why?
10. I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?

We encourage you to download and read the study from Symantec. We are sure you will find it very informative.  Then once you have read the study and have decided you need to learn more about encryption key management, listen to this informative 15-minute podcast.

Last week we began a series of blogs with questions from our recent webinar titled “Encryption Key Management with Microsoft SQL Server 2008”.  If you missed part one, you can view it now.  We talked about the performance impacts of TDE (Transparent Data Encryption) on Microsoft SQL Server 2008.  This time we will talk about how often you need to rotate your encryption keys on your SQL Server and whether your database gets locked during Cell Level or Column Level encryption during the re-encryption process.  Additionally, we will touch on how we can help users that have both Microsoft SQL and Oracle environments.  Without further delay, here are the questions:

How often do keys need to be changed?  During Cell Level or Column Level encryption, will the database be locked during the re-encryption process? 

With Cell Level encryption you can roll keys without bringing down your database.  When you establish a symmetric key in Alliance Key Manager, our encryption key management appliance, you can establish how frequently you want that key to be rolled over, rotated, or changed (which all mean generate a new key) for use by the database.  Alliance Key Manager implements support for both automated and manual key rollover, and if you are using Cell Level encryption in Microsoft SQL Server, you can take advantage of that.  The broader question about how often you should change keys in your database is a really interesting one.  There is no simple answer to that.  If you are familiar with PCI DSS you know that particular question got a little more complicated in version 2.0.  Basically, you have to establish a crypto-period for your keys.  I think NIST would say two years is probably the maximum for the usage period of a key.  Five years on the outside for a key to be used, even for the decryption of previously protected data.  The bottom line is you have to establish a crypto-period for your keys and then implement that as policy.  We support that process by letting you define how frequently keys should be changed and then managing that process for you automatically.

With TDE, the answer is a little bit different.  TDE requires some manual steps to roll keys, but we fully support multiple keys and rolling keys with our encryption key management appliance. 

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

Yes.  We provide encryption keys across a wide set of databases, applications, and servers.  We have customers today who are protecting Oracle databases using our Alliance Key Manager to store encryption keys.  We provide sample code that shows how to do that - same thing with MySQL, DB2 from IBM, and almost every standard database that you might run into.  We also make it easy for customers who are using a variety of development languages to implement encryption. 

If you are using SQL Server EKM, you really get a big win because it doesn’t take any programming at all to implement TDE.  So that is the “easy button” in terms of encryption.  Additionally, if you have written applications in Java that use SQL Server, Oracle, or MySQL, we provide Java examples - full applications in fact - on how to use them.  If you programmed in C#,  VBNET, Perl, Python, or PHP, we have sample code that really helps customers get up and running very quickly with our key management solution.

Stay tuned for our next post on encryption key management in High Availability (HA) and disaster recovery scenarios.  In the meantime, you can view a recording of “Encryption Key Management with Microsoft SQL Server 2008”

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.

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

The recent 2011 PCI Compliance Report released by Verizon concludes that many companies are losing ground on PCI DSS compliance and 44% of all breaches take over a year to be discovered. These findings are disturbing. eWeek.com wrote an excellent summary of the report.

Here is one snippet from the article:

"About 42 percent of organizations had trouble encrypting data in the database or implementing a proper key management strategy to keep the information safe."

We know that data protection is the hardest part of PCI DSS compliance. Many studies show that organizations struggle with encryption and key management. But are they really losing ground after they get their data in place?

I talk to a lot of customer about PCI DSS compliance, and I have a different take on this.

The recent audit and training changes that affect Level 2 Merchants may be showing up in this statistic. Prior to 2011, Level 2 Merchants completed an annual Self Assessment Questionnaire (SAQ). Starting in 2011 Level 2 Merchants must either undergo an on-site audit by a QSA auditor, or send a member of their IT team for ISA training by the PCI council. A lot of companies are opting for the second option and are getting their internal staff through the ISA training process.

I think that a lot of these newly trained IT professionals are coming back home and understanding encryption and key management requirements a lot better. It was easy to put the check marks in the box when doing the SAQ questionnaire. Now there is a lot more thought about what good encryption and key management means. I think that is driving a lot of the change, especially in the area of key management.

Did these companies lose ground? No, they weren’t in compliance before, and they are just coming into compliance now.

Customers tell me that meeting the PCI DSS requirements for key management is their biggest area of remediation. They’ve been storing encryption keys in a file, or somewhere on the hard drive, or on a USB storage device, or on another server where they are not properly protected. None of these techniques can meet PCI DSS requirements for Dual Control, Separation of Duties, and Split Knowledge. Really, any storage of data encryption keys on the same server as protected data is going to be a compliance problem. Newly trained IT staff now understand this and are taking action to fix the problem.

So, did they fall out of compliance? No, they weren’t in compliance before and now they are moving towards better security. And that is a good thing.

I don’t mean to minimize the effort that it takes to stay in compliance with PCI DSS. It’s a lot of work and it takes on-going attention. And security and IT departments are under the same budgetary pressures that all of us feel. They are trying to make do with fewer people and smaller budgets. 

But perhaps the news is not as bad as we think. If you haven’t taken a look at your key management strategy lately, now is the time to do it.

Fore more information, download our podcast "Key Management Best Practices: What New PCI Regulations Say" and learn about encryption key management best practices, as well as what PCI has to say about integrated key management (why it isn't a good thing), dual control, separation of duties, and split knowledge.

Patrick