Townsend Security Data Privacy Blog

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.

Microsoft defines an interface for external key management systems with their SQL Server Extensible Key Management (EKM) architecture, but does not define how encryption key management vendors should communicate between the Windows server and the encryption key manager. This is important because the communications over the TCP network must be secure, and access to the client side certificate credentials also has to be secure.

Our Alliance Key Manager uses the Transport Layer Security (TLS) communications protocol to provide for secure and authenticated connections between the Windows server running SQL Server, and the encryption key manager. TLS is the de facto standard for protecting communications between a client application and a server. Our SQL Server EKM provider software uses mutually authenticated TLS connections to ensure that all information exchanged between SQL Server EKM and the key manager is protected.

But how do you protect the client side X509 certificates and private keys needed for TLS security?

The best way to do this on a Windows platform is to leverage Microsoft’s certificate manager and certificate store. When you use this native Windows facility you also get a lot of native Microsoft security for certificates and private keys. For example, you can restrict access to the private key used for TLS communications to a small, defined set of users. You don’t need to rely on file permissions to implement this level of protection, and you can leverage Windows event management to report unauthorized access attempts.

The Alliance Key Manager EKM Provider for SQL Server fully integrates with Windows certificate management and .NET TLS services when establishing a TLS connection. This provides the most secure implementation for managing certificates and private keys for TLS negotiation.

For more information view our webinar "Encryption Key Management with Microsoft SQL Server."  We think this webinar is informative and shows just how easy it is to implement encryption key management on your SQL server.

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

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

The generation of tokens is an important part of the new PCI SSC guidance on tokenization. Tokens can be generated using a number of techniques including random number generation, encryption, sequential assignment, and indexes. Using tokens to recover the original credit card number must be “computationally infeasible” according to the new guidance.

In this area, I think the tokenization guidance could be much stronger. To the cryptographic community it is well understood how encryption and proper random number generation can produce results that can’t be feasibly reversed using computational methods. The use of indexes and sequential assignment is a lot more “iffy” in my mind. Here is an example: I have a table sorted by the credit card number that contains 100,000 rows. I read the table and assign tokens in a sequential manner.  Are these tokens as strong as tokens generated by a random number generator? Obviously not. Merchants and QSA auditors need to be very careful about a tokenization solution that uses indexes or sequence numbers for token assignment.

The use of encryption to generate tokens should also give merchants some pause for extra thought. First, using encryption may produce tokens that are indistinguishable from normal credit card numbers. The guidance discusses distinguishability of tokens, and if you use encryption to generate tokens you are probably going to have additional work in this area. Secondly, it is not clear yet if tokens generated in this manner will be subject to additional encryption and PCI SSC guidance. The work released today holds open the likelihood that there will be additional guidance for these types of tokens. In other words, the jury is still out on the use of tokens generated by encryption. Lastly, tokens generated by an encryption method almost certainly have to meet all of the PCI DSS requirements for encrypted PAN. It is hard to imagine any other outcome. Merchants will want to be extra careful when deploying a solution that uses encryption to generate tokens.

Lastly, we can expect to see an increase in the number of cloud based tokenization solutions coming to market. The new guidance only touches on this in a tangential way when it discusses the need to carefully review all aspects of a tokenization solution. Since most clouds are based on virtualized environments, I suggest that you read the PCI SSC virtualization guidance from the PCI SSC. It is very hard to see how any of the most popular cloud environments can meet the recommendations of that guidance.

Big kudos to Troy Leach and the members of the tokenization SIG and Working Group who’ve been laboring on this document! The council and advisory committees also deserve praise in nurturing this process. The stakeholders are a diverse community with sometimes conflicting interests. The result speaks well to the management team. I know that we’ll be seeing more work from this group in the future.

Click here for more information on Alliance Token Manager, our tokenization solution and learn how we can help your organization with a certified and comprehensive tokenization technology.

-Patrick

Today the Payment Card Industry Security Standards Council issued some long awaited guidance on tokenization as a method of protecting credit card information (“PAN”, or Primary Account Number in PCI language). This guidance has taken a number of months to produce, and will be very helpful to merchants who want to deploy tokenization solutions to reduce the scope of PCI compliance efforts, for those who have already deployed solutions and need to assess if they meet minimum requirements, and for QSA auditors who have been looking for some guidance in this area.

The link to the guidance is here.

Here are some first thoughts on reading the guidance.

As I’ve been saying here before, a tokenization solution is always in scope for PCI DSS compliance. This means the merchant is responsible for insuring that a tokenization solution itself meets all of the PCI DSS requirements. Whether you create your own tokenization application, or you acquire one from a vendor, it is in scope for PCI DSS compliance and you are responsible for it. The guidance makes this point very clearly. In fact, the guidance makes the observation that tokenization solutions are likely to be the targets of attack because they become a centralized repository of credit card information. Merchants should be very careful that their tokenization solutions meet all PCI DSS requirements and are sufficiently hardened. In my opinion, there are very few merchants who would be up to the task of creating such a solution in-house.

Following on the previous point, a tokenization solution must have encryption and key management capabilities that meet PCI DSS requirements. This means special care in the deployment and implementation of key management. You should be very sure that your key management solution implements proper Dual Control, Separation of Duties, Split Knowledge, and separation of keys from protected data. When acquiring a vendor solution for tokenization look for FIPS-140-2 certification of the key management system – that should be a minimum requirement to indicate the proper implementation of encryption and controls.

Download a recent webcast I recorded that discusses the importance of tokenization and PCI compliance.

Today’s announcement by the PCI Security Standards Council on tokenization is certain to raise awareness about the importance of selecting the right tokenization solution for your organization and ensuring it meets the PCI DSS requirements.  I will be post another article Tuesday that will discuss more thoughts on this new guidance.

I hope you find this helpful.

Patrick

 

A little over a year ago Mastercard sent a shot over the bow of Level 2 Merchants when they informed them that they would have to undergo a PCI DSS audit by a qualified QSA auditor, or send internal IT staff to ISA training given by the PCI Security Standards Council. Level 2 merchants had been completing a Self-Assessment Questionnaire (SAQ) each year, and this represented a big step-up in the requirements.

Merchants scrambled to prepare for this new requirement which was due to take effect on June 30, 2011. A number of Level 2 merchants signed up early for the ISA training, and several training sessions were held in the US and Europe. Annual training and certification seemed more attractive than an on-site QSA audit to many merchants, probably because of the cost associated with an on-site audit. But I am guessing that the demand for ISA training out-stripped the availability of classes.

Mastercard just announced a postponement of the SDP ISA requirement:

“In June, 2011, MasterCard announced revisions to the SDP Program mandate by postponing the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements until 30 June 2012. MasterCard has postponed the implementation date of the Level 1 and Level 2 merchant internal audit staff training and certification requirements to accommodate for the PCI SSC’s global rollout of the ISA Program and to provide Level 1 and Level 2 merchants in all regions with the opportunity to attend the ISA Program and pass the associated accreditation examination.”

The full announcement is here.

I believe that this announcement is a good faith action on the part of Mastercard to help merchants meet the requirement. We saw a similar action on the part of the State of Massachusetts when they delayed the implementation of their mandatory encryption requirements for consumer privacy. These requirements were eventually placed into effect and are now law. Level 2 merchants should not interpret this as a reprieve from having to meet these requirements. If you aren’t scheduled for ISA training, get registered now and don’t put it off!  You are going to need to meet these requirements and the sooner you get the training done the better off you are going to be.

By the way, I’ve heard great reports on the training! It is practical and effective, and Level 2 merchants are reporting a lot of benefits from the training.

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

Patrick

 

   

DOWNLOAD WHITE PAPER Download our Encryption Key Management and PCI DSS 2.0 Compliance Matrix white paper and learn more about ensuring the data you are protecting meets PCI compliance. Click Here to Download Now

We are now past the half-way mark between PCI DSS version 1.2 and PCI DSS version 2. During this year of 2011 merchants have the option of qualifying under either version of the data security standard. Starting on January 1 of 2012, the only option will be to meet the version 2 standard. So, what trends have we observed?

Level 1 merchants are doing pretty well meeting the data security requirements because they’ve been through several cycles of on-site QSA audits. With the basic security controls in place, they are focusing on implementing better real-time monitoring and learning to react quickly to new threats. We still see breaches among large retailers because the bad guys are getting better, but the larger merchants have really stepped up their game.

The picture is not so bright with Level 2 and Level 3 merchants. Level 2 merchants now have to undergo an on-site QSA audit, or do annual training with a PCI SSC certified trainer. This is having a big impact on a lot of these merchants whose security controls were not up to par. They are having to deploy better monitoring systems, and meet industry best practices for encryption and key management. And key management is turning out to be a problem area from many of these mid-tier merchants.

What are the key management problems that I am hearing about? Here are some examples:

• A retailer with an eCommerce web site running on a Windows platform is encrypting data in a SQL Server database, but the key is stored on another server in the clear. A QSA auditor required that the merchant deploy better key management practices.
• A large manufacturer runs a user group and collects membership fees from a web site which are then processed on an IBM System i (AS/400) platform. The encryption keys were stored in encrypted format on the same server. A QSA auditor at their payment processor required that they institute better key management practices by storing the keys in an HSM on a physically separate server.
• A division of a large home improvement retail chain accepted customer orders from a web site, and processed the authorization transactions on a Linux server. The encryption keys were stored on a removable storage device. The payment processor rejected their self-assessment questionnaire on the basis of key management practices. The division migrated to the corporate key management solution to mitigate the issue.
• A software vendor who provides web hotel reservation portals uses both a Windows application and a Linux application to process reservation requests and payments. PCI standards require that credit card numbers be encrypted as data moves through both server environments. This software developer had good advice and chose a defensible key management strategy from the start.

I think you get the idea. Starting with a good key management solution is going to save you some grief later. We helped each of these companies meet PCI DSS compliance for key management, and in most cases it really didn’t take that much time or effort. But better to get it right from the start!

To learn more, download our white paper on encryption key management requirements for PCI.

Many of you have asked me about encryption and key management requirements for HIPAA and HITECH Act. I can understand why there is a fair amount of confusion about this. The US Department of Health and Human Services (HHS) has not issued the final rules, but they have indicated that the current Interim Final Rules are unlikely to change very much. The final rules are due to be published later this year, and may be updated on an annual basis.

The current IFRs indicate that encryption is an accepted method of protecting patient health information. However, there is no mandate for encryption, and medical providers (Covered Entities, in HHS regulatory speak) can use other methods to protect data. However, the guidance about breach notification is very explicit on the question of encryption. A medical provider can only avoid breach notification if the data is encrypted. In the event of a data loss where the data is not encrypted, the medical provider must report the breach to HHS and to the patients affected by the loss. The breach event is published on a public web site maintained by HHS. There may be penalties for the loss of unprotected information, and HHS has already started levying fines on medical providers. Here is what HHS says about encryption and breach notification:

“Protected health information (PHI) is rendered unusable, unreadable, or indecipherable to unauthorized individuals if one or more of the following applies:

1. Electronic PHI has been encrypted as specified in the HIPAA Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.“

This is how proper key management is discussed in the HHS documentation. Note that it explicitly states that encryption keys must NOT be stored on the same device as the protected data. This is very similar to the PCI DSS requirement. The HHS documentation makes reference to NIST publications, and those publications recommend the use of FIPS 140-2 key management solutions.

It is important to note that tokenization is not mentioned by the HHS guidelines at all. Tokenization vendors will probably argue that tokenized data is not patient information, so can be used to avoid breach notification. But that is a vendor claim, and is not addressed by HHS. It should be noted that like PCI DSS, the tokenization solution must also meet the HHS guidelines for encryption and key management.

The bottom line?

The only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies. Encryption keys must not be stored on the same device (server) as the protected data. NIST best practices recommend that key management systems should be FIPS 140-2 certified. Our Alliance Key Manager solution meets these guidelines and will help you get to the land of HIPAA and HITECH Act Nirvana.

For more information, download our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification with NIST-Certified Data Encryption."