Townsend Security Data Privacy Blog

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

In just one more day, we'll experience another first at Townsend Security,  we will be exhibiting for the first time at the PASS Summit.  The Professional Association for SQL Server (PASS) Summit is the largest conference of the year for SQL Server professionals.   Earlier this year we joined the Microsoft Partner Program and earned a competency in Business Intelligence, we visited the Worldwide Partner Conference and just a couple of months ago we launched our new HSM for SQL Server. I guess you could say exhibiting at the PASS Summit is the next logical next step for us.

While at the conference we look forward to getting to know this market personally by meeting several new SQL Server customers and business partners.  Attendees will be among the first to see our newly announced encryption key management hardware security module (HSM), Alliance Key Manager for SQL Server, which simplifies how organizations can meet compliance requirements and removes cost as a barrier for a professional key  encryption key management solution. We will get to discuss some of the key features of the product:

• Seamless integration with SQL Server 2008
• Uses Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008.
• Automation of all key management tasks including rotation, retrieval, and generation in a central location.   
• Priced to meet the budget needs of every enterprise.  An entry level, 2-server bundle (primary and failover) is available for under $12,000 list.

We look forward to meeting SQL Server users, enthusiasts and developers at the PASS Summit -- If you are going to be there, be sure to stop by our booth #335.  It will be great to meet you!

If you aren't able to make it to the conference and would like to learn more about encryption key management on Microsoft SQL Server, view our webinar "Encryption Key Management with Microsoft SQL Server."  We think this webinar is informative and shows just how easy it is to implement encryption key management on your SQL server.

The 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

Cancer, directly or indirectly, affects everyone somehow.  It cares not about age, sex, wealth, your faith (or lack of it).  Cancer can develop in almost any organ or tissue in your body.  

Townsend Security's team has been struck three times by cancer.  So in true Townsend spirit we don't just sit around and do nothing, we FIGHT BACK and support each other and our communities!   

October is national Cancer Awareness Month, so to support those we love and those who have been afflicted, a few of us from Townsend Security flew to Chicago to participate in the City of Hope's 2011 Walk for Hope.  The City of Hope is an independent biomedical, treatment and education center.  Founded in 1913, and driven by compassion, researchers and caregivers at the City of Hope strive to bring the world closer to a cure.

We joined Sharon Kleinerman, one of our Account Managers, and her team at The Glen Town Center for the start of our 5k walk/run!  The Glen Town Center has been transformed from a naval base into a beautiful outdoor shopping center that includes a park with a lake and walking trails.  The shopping was tempting, but we were here to raise money to fight cancer.  Just as the walk was about to begin, a light drizzle began falling all around us and we became dubious about what the weather conditions might be for the rest of the day.  Fortunately, just as the walk started, the rain let up.  We began to think that we might actually have a dry walk after all.  However, half-way through...the rain was back with a vengeance.  The rain refused to let up but it couldn't dampen ours' (or any of the participants') excitement and enthusiasm.   Finally, an hour later, we finished - a team of 8 soaking wet WINNERS!!

While participating in the Walk for Hope we learned facts about cancer that are  good for everyone to know.  Did you know that the four most common cancers in the United States are breast, prostate, lung, and colon cancer?   Did you know there are simple ways to protect yourself against these types of cancer - things you can start doing today?

The Mayo Clinic offers 7 Tips to Reduce Your Risk of Cancer:

• Don't use tobacco
• Eat a healthy diet (THINK COLORS!!)
• Exercise is your friend. Maintain an healthy weight and keep moving.
• Protect your self from the sun - even in rainy Olympia, those nasty rays are everywhere and they get through the clouds.  Just because you can't see the sun doesn't mean it is not there. Use sunscreen!!
• Avoid risky behavior
• Get immunized
• Perform regular self exams - KNOW what to look for!!

To learn more about how you can help:
The City of Hope
The American Cancer Society
St. Jude Children's Research Hospital

Draft versions of a Federal data privacy and breach notification law have been in existence for over a year. The House of Representatives passed a version some months ago, and two versions have been working their way through the US Senate. This week saw a significant advance in the US Senate as the judiciary committee under Senator Patrick Leahy’s leadership passed a version out of committee with a vote along party lines. I think Senate Bill 1151 represents a significant step forward towards a federal law that will replace all of the approximately 45 state laws on breach notification. The law still has to be reconciled with the House version, and a lot can change in the process, but there is general agreement in the business community that one Federal law is preferable to a lot of different state laws. So I think there is a good chance that a Federal privacy law can pass.

Here is a recap of some of the features of the new law that will affect your business:

• You will need to have a written security policy.
• You will need to perform periodic vulnerability assessments.
• You will need to protect data using industry standard practices such as encryption.
• The legal penalties include fines and imprisonment.
• If you share sensitive data with service providers, you must ensure that they protect the data.
• You are responsible for notifying people affected by the data loss.
• There is an expanded definition of “Sensitive Personally Identifiable Information”.
• You will need to maintain audit trails of who accessed sensitive information.

In many ways, the new federal law goes further than most state laws in defining what companies must do to protect sensitive data. The law tries to strike a balance between prescriptive measures, and the evolving nature of threats. In many respects the law comes close to adopting many of the principles of the Payment Card Industry Data Security Standards (PCI DSS), and companies who meet PCI DSS standards will find a lot that is familiar in the law.

The definition of Personally Identifiable Information (PII) has expanded pretty dramatically and now includes telephone numbers and mobile device IDs, email addresses, and other information. I will talk about this a bit more in future blogs. I think there are some substantial procedural and technology issues in this area that will affect your approach to protecting data.

As I expected, the Federal law makes reference to industry standards for encryption and key management, and points directly to existing laws such as Gramm-Leach-Bliley (GLBA), the Health Insurance Accountability and Portability Act (HIPAA), and others. The Federal Trade Commission is charged with developing guidelines in this area. I think there is a well-worn template for this type of work that will point directly to the NIST standards and best practices. I believe that companies would do well to be sure that their data protection strategies line up with NIST standards.  FIPS-140-2 certification is already required of some private enterprises, and this is probably the direction we are going.

Be sure to follow us on Facebook, Twitter, and LinkedIn to stay up to date on the latest technology and news about data protection.

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

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

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

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

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

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

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

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

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

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

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

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

What are the performance impacts of encryption?

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

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

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

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

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

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

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

Microsoft has a great hit in the SharePoint suite of products. I am guessing that this might have taken them at bit by surprise, but SharePoint turns out to be very popular with organizations large and small. In the early days it was a free component that tagged along with Windows Server. Now there are many varieties of SharePoint that include flavors for Office, web portals, collaboration, Customer Relationship Management, and on and on. And a whole ecology of Microsoft partners and ISVs are building solutions on top of SharePoint, or incorporating support for SharePoint in their business applications.

What a great success story!

Securing SharePoint is now a big focus for those same Microsoft customers. Once you have a user friendly collaboration tool in place, it’s hard to know what those pesky users are going to put in there. Are they storing credit card numbers or social security numbers? Perhaps bank account numbers? Could our users be uploading spreadsheets with thousands or even millions of records with sensitive data?

You bet they are!

And this is keeping security administrators and compliance auditors awake at night.

What you might not know is that SharePoint is built on top of Microsoft SQL Server as its data store. And in SharePoint 2010 you can now deploy SQL Server 2008 R2 with Extensible Key Management (EKM) and Transparent Data Encryption (TDE) to get data-at-rest protection for your SharePoint content. This is a great step forward in content protection, and many security administrators are now using this facility.

Of course, our Alliance Key Manager for SQL Server solution works naturally with SharePoint 2010 built on SQL Server EKM. You get full support for a compliant and best practice approach for separating encryption keys from sensitive data as required by PCI DSS and other regulations. If you are already running our key manager to protect SQL Server database applications, you have what you need to protect SharePoint.

Many SharePoint customers are rightfully concerned about the performance impacts of encryption. I think Microsoft has done a good job in this area, too. Microsoft will tell you that the likely performance impact with SQL Server Transparent Data Encryption (TDE) is from 2 to 4 percent. Our own performance tests have similar results, and in some cases are below 2 percent. This is really astounding performance when you consider that the entire table space is being protected by strong encryption. Of course, customer environments vary a great deal, and you should always model your environment to determine the likely impacts. But I think that the large majority of SharePoint 2010 installations will benefit from SQL Server TDE encryption.

For further information, download our white paper "Encryption Key Management for Microsoft SQL Server 2008" and learn about meeting encryption and key management challenges on your Microsoft SQL Server.  Additionally, I’ve added some resource links below if you want to explore SharePoint 2010 and SQL Server encryption in more detail.

Patrick

Resources

Here is a blog by Margo Crandell of Microsoft on SharePoint and SQL Server.  It’s a good entry point for a discussion of SharePoint with SQL Server.

This TechNet article talks about planning and deploying SharePoint with SQL Server, including how to migrate to newer versions of SQL server.

I’ve found this Microsoft Whitepaper very informative on security and SharePoint. You will find a good, basic discussion about SQL Server TDE in this document.

As we work with Microsoft customers who are implementing encryption with Extensible Key Management in SQL Server 2008 R2, the question inevitably arises about whether to use Transparent Data Encryption (TDE) or Cell Level Encryption.

As you might guess, this comes down to tradeoffs between ease of implementation, performance, and security.

Transparent Data Encryption (TDE) is very easy to implement. It doesn’t require any changes to your existing applications, and using TDE with Alliance Key Manager, our encryption key management solution,  is very straight-forward. It typically only takes a few minutes to get up and running with our encryption key manager and TDE. Cell level encryption, on the other hand, will take at least some changes to your SQL statements or .NET application code. These changes aren’t difficult at all, but you still need to make them. For some of our customers who don’t have the source code for the application, or who don’t have IT resources available, this can be a significant barrier. The good news is that the work to set up the Alliance Key Manager key server is the same for both Cell Level Encryption as for TDE. From an ease of implementation point of view, TDE is the easy winner.

The second difference between TDE and Cell Level Encryption is performance. You might think that Cell Level Encryption would perform better because there is actually less data being encrypted, but you would be wrong! TDE is the clear winner in the performance category. Microsoft estimates that there will be a 2% to 4% performance penalty with TDE. Our own tests using the publicly available SQL Stress tool (www.sqlstress.com) shows that for most databases the performance penalty is closer to the 2% value, and in some cases less than 2%. Cell Level Encryption almost always carries a bigger performance impact. So TDE is once again the winner in the performance category.

The security tradeoffs are more complex. As Microsoft has noted, TDE does not encrypt and decrypt in memory:

“Note that neither BitLocker nor TDE encrypt data in memory. This can provide a substantial performance benefit over the encryption offered in SQL Server 2005, including the use of indexed searches (discussed later). But this also means that a system administrator with access to this memory can read the unencrypted data. All users with database permissions to access data will see unencrypted data.”

Cell Level Encryption does do encryption and decryption in memory, and this provides an incremental improvement in security.  So Cell Level Encryption provides a slightly better security strategy. If you use TDE as your encryption strategy, you will want to be sure to use a number of other techniques to lock down your environment.  You can read more about this on the Microsoft MSDN web site here.

I think for most Microsoft customers the use of TDE will fit well with their tolerance for risk and their security strategy.  Whether you choose TDE or Cell Level Encryption, you end up with your data much better protected.

You need to combine encryption and good encryption key management with other steps to properly secure your Windows and SQL Server environment.  Encryption is not a magic bullet, but without it your data is exposed to loss.

For further information, download our white paper "Encryption Key Management for Microsoft SQL Server 2008" and learn about meeting encryption and key management challenges on your Microsoft SQL Server.

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

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

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

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

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

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

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

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

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