Townsend Security Data Privacy Blog

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.

Welcome to our final installment in the "Data Privacy for the Non-Technical Person" series.  In case you missed the other two blogs in this series, here are the links to part one and part two.  This third and final blog will cover data privacy compliance regulations and how an organization would begin to develop a security policy.

We hope that these blogs have been informative and answered questions that you might have had about data privacy.  If you still have questions, please feel free to send us an email.  Additionally, download our podcast "Data Privacy for the Non-Technical Person" to hear my conversation with Patrick Townsend, Founder & CTO, in its entirety.

Are there are any laws or regulations requiring businesses to protect their sensitive data?

Yes.  There are quite a number of laws, and they cross over each other too.  Many find themselves having to work with several regulations when protecting data.  If you take credit cards, you fall under the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a private regulation promoted by the card brands (Visa, MasterCard, etc.).  If you are a bank or engaged in the banking industry you fall under the Gramm-Leach-Bliley Act (GLBA) and FFIEC regulations for protecting information.  Those are specific to the banking industry.  If you go to the doctor or are a doctor/medical clinic or any place in the medical industry, you fall under the HIPAA/HITECH Act to protect patient’s medical information.  There are also other regulations too.  The government is moving laws through congress to define protections for PII.  So there are a number of regulations affecting data that needs to be protected.

So how would an organization begin to develop a security policy?

This is a real challenge, particularly if you are starting for the first time.  It can seem overwhelming, especially when we read about the sophistication of data breaches and the attacks on companies.  Keep it simple to start – there are things that you can do to that are very effective upfront and know that you are vulnerable.  I think one think that sometimes inhibits people from taking action is thinking that they are not going to be subject to a data breach.  That is a dangerous attitude.  So, keeping it simple, taking simple steps, ranking where the vulnerabilities are and doing those things first are really important things.  There are really the obvious things like making sure you have good anti-virus software running on your computers and using good, strong passwords.  If you have a web site, there are scanning tools that will help you scan to see if your web site is secure.  And if your business is handling sensitive data, run background checks as part of your new employment procedures.  Finally, there is some online help that can be really useful for most people – sans.org is a place where you can go to get basic policy information and educated on threats.  For business that need to secure data, we have a lot of resources on our website to help you understand the various regulations and what encryption and key management tools you can use to begin protecting your data.

Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

This week brings part two of the "Data Privacy for the Non-Technical Person" series.  Last week we determined what constitutes personal information that needs to be protected.  This week Patrick Townsend, Founder & CTO, talks about how organizations are protecting sensitive information, how encryption and key management relate to each other, and what happens when encryption is not done correctly.  If you are jumping in mid-stream, you can read part one here.  Additionally, you can download our podcast titled "Data Privacy for the Non-Technical Person" to hear our conversation in its entirety.

How do organizations protect sensitive information?

They use a number of techniques.  Some of them are pretty obvious.  Businesses use anti-virus software and software to detect intrusions on their network, as well as making sure they have a secure web site if they are taking sensitive information from you over the internet.  And then they do some things that most people might not be aware of.  A business that is trying to protect your personal information will do some things that are procedural in nature – for example a lot of companies will now make sure all new employees have a background check.

Companies are also doing things that help make their data very difficult to steal.  Encryption, which is the process of taking a credit card or social security number and turning it into and encrypted value, makes stealing data near impossible.

Companies who are really trying hard to protect information of their customers and employees are deploying a variety of tools.  Encryption is probably one of the more important ones and it is one of the more difficult technologies to deploy, but certainly all of the major companies that you might do business with over the Internet will be using encryption to protect your data.

Encryption and key management have been talked about a lot lately.  How do they relate to each other?

Encryption and key management go together.  They are very complimentary technologies.  When you encrypt a credit card number, you have an encryption algorithm that takes your credit card number and turns it into something totally different.  But another important input into that process is a secret key.  Many people think that the encryption algorithm itself is some kind of secret mechanism, which isn’t the case.  Encryption is well understood.  There are standards for it and it is readily available.  What is really the secret that prevents losing data is the encryption key – just like the key to your front door is what protects your house.  An encryption key works very much in the same way.  Companies that use encryption really have to create a key that is very unique and very strong, and they have to protect it so that it doesn’t escape into the wild. Anyone that has the encrypted data and the encryption key, really can get the sensitive data back.  In the real world of protecting data with encryption, measures are taken to protect the encryption key – that is the real secret that people are trying to protect in a business environment. 

What happens when encryption is not done correctly?

There are many ways that encryption can be done poorly or incorrectly.  We see that sometimes around the area of encryption key management.  For example, storing an encryption key on the same platform where the data that it is protecting is just bad practice.  Sometimes you hear the term “integrated key management” or people say “we are storing the encryption key in a database file and we have locked that database file down.”  These are really poor practices and, in fact, cannot meet compliance regulations about encryption key management.  So, that is just one example of encryption that is done badly.

Other examples are just using non-standard or proprietary encryption.  The CUSP mode of AES encryption, for example, is not a standard mode and is a proprietary protocol that can’t be a part of true compliance.  It is just another example of running off the rails in terms of best practice for encryption.  A company that is purchasing encryption technologies should really examine their vendors carefully.  I always point back to NIST certification because it is the bottom-line indication you have that the encryption product is a good quality solution. 

Here is another interesting thing that I think people sometimes forget.  If you have a data loss, it is going to be your problem, not the vendors problem.  Even though you may have acquired a solution that is not right, it is still going to fall on you.  It is going to be your headache to solve, your customers that are upset, and your financial loss when data gets out.  The loss of trust from your customers and employees is also difficult too.  For all these reasons, I think paying attention to encryption technologies is a good idea.

Stay tuned for our next and final installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

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

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

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

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

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

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

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

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

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

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

Patrick

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

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

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

What constitutes personal information that needs to be protected?

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

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

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

Stay tuned for our next installment in this series.  Download our podcast “Data Privacy for the Non-Technical Person” to hear more of this conversation.

Alliance Key Manager for SQL Server

Today we are excited to announce the availability of our new Alliance Key Manager for SQL Server (AKMSS). AKMSS is a certified Hardware Security Module (HSM) that manages and protects access to your encryption keys.

Our new HSM is focused on providing mid-market Microsoft SQL Server customers and their technology partners with an affordable, easy to deploy, solution for meeting data privacy compliance requirements in PCI-DSS, HIPAA/HITECH, FFIEC and other data privacy regulations. Unlike other HSMs on the market, AKMSS is built, tuned and priced specifically for small and mid-size SQL Server customers who need to protect sensitive data in their databases.  AKMSS comes with a standard Windows interface so it is easy to configure, deploy, and operate.  AKMSS is based on proven technology that is already successfully used by thousands of customers worldwide.

Townsend Security built this HSM with the idea that cost should not be a barrier to data privacy compliance.  We know that small and midsize companies are increasingly feeling the pressure to meet data privacy compliance requirements, and at the same time many are being targeted by data thieves.  Our AKMSS HSM will help small and medium-sized businesses meet data privacy requirements for encryption key management with FIPS 140-2 certified appliance.

Some of the features and benefits of our AKMSS HSM include:

• Out-of-the-box integration with SQL Server 2008
• Utilizes Microsoft’s Extensible Key Management (EKM) interface to support Transparent Data Encryption (TDE) on SQL Server 2008
• Based on our FIPS 140-2 certified AKM software
• Reduces cost as a barrier for a professional data privacy compliance
• Built to be integrated - the product is ready for partner integration

If you need key management for the Microsoft SQL Server world, please take a moment to contact us and see how you can add industrial strength compliance to your encryption project.

You can learn more about the solution here.  Additionally, we have a webinar titled "Encryption Key Management with Microsoft SQL Server 2008" that shows just how easy encryption key management can be on your SQL server.

John Earl, President & CEO

Mid-size companies are under attack like never before, and breaches and financial losses are on the rise. The attacks are usually not that sophisticated - we are talking about the usual security weaknesses which include the lack of encryption and good encryption key management. So, if we know what the problems are, why are so many companies still vulnerable?

I think I know a big part of the answer: cost and complexity.

Mid–market companies are very sensitive to the cost of any IT project that does not contribute directly to the bottom line. And the more complex a project is, the higher the cost. For better or worse, encryption is viewed as a terribly complex, time-consuming, and costly project. Despite the obvious financial pain that a breach causes, and despite the fact that compliance regulations such as PCI DSS, HIPAA and the HITECH Act, GLBA and FFIEC, and state privacy laws encourage encryption and provide safe harbors when it is used, it just doesn’t get done.

Alliance Key Manager for SQL Server

That’s why I am really happy about our announcement today of an affordable and easy-to-deploy encryption key management HSM solution for Microsoft SQL Server. Building on our existing FIPS 140-2 certified Alliance Key Manager solution, our new encryption key management HSM offering for Microsoft SQL Server puts encrypting sensitive data within the reach of any company. With an affordable entry point, it can fit within the budget of most companies. And enabling encryption in the database does not require expensive programming resources. Your database administrator or your favorite solution integrator can get the job done very quickly. You can find out more about Alliance Key Manager for SQL Server here.

Microsoft deserves a lot of credit for opening the door to easier compliance. The SQL Server Extensible Key Management (EKM) architecture provides a straight-forward path to implementing encryption and key management. EKM is the strategic architecture for encryption in current and future releases of SQL Server.  With the Transparent Data Encryption (TDE) option of EKM, they even made the process simple to deploy. Microsoft created a door for third party vendors of key management HSMs to enter, but there have been few entries in this area. Our new Alliance Key Manager for SQL Server HSM will knock down those cost and complexity barriers for mid-market companies.

Independent Software Vendors and Solution Integrators are also a very important part of the Microsoft SQL Server ecology. Software developers have created thousands of applications on top of SQL Server, and mid size companies look to ISVs to solve difficult compliance issues for them. Along with our release of our HSM for SQL Server, we are inviting ISVs to join our partner program and realize the benefits of simple and cost effective data protection. We are making it easy for ISVs to integrate encryption and key management directly into their applications. Partners can get more information here.

Lastly, did you know that SQL Server is the data store technology for many of Microsoft’s products? For example, SQL Server is the underlying data store for Microsoft SharePoint and Microsoft Dynamics. With SharePoint 2010 you get full support for SQL Server EKM encryption. Worried about sensitive data in your SharePoint collaboration environments? There’s a solution for that!

I will be writing more about our new SQL Server HSM for encryption key management over the next few days. There are some really nice features in the product that deserve a deeper look. For more information on view our webinar "Encryption Key Mangagment with SQL Server".  This webinar is informative on just how easy it is to implement encryption key management on your SQL server. 

Patrick

As “The Encryption Company,” we often blog about meeting PCI DSS with encryption and key management.  Our NIST-certified technologies will help your organization satisfy Section 3 of PCI DSS, as well as other privacy regulations.  But there is another section of PCI DSS that Townsend Security can help you with – Section 10.

Section 10 states the requirements for tracking and monitoring access to network resources and cardholder data.  Some things that this section speaks on is procedural – daily reviewing logs for all system components and retaining an audit trail history for at least one year.  Section 10 also specifies how your logging solution needs to perform.  This includes automating audit trails for all system components and securing audit trails so that they cannot be altered.

This regulation is especially important for organizations using IBM i’s.  The state of logging on most IBM i’s is not good.  The IBM i doesn’t log information like your other systems and the security logs that it does produce are often an enclave inside the IT organization.

So what does this mean?  Only the IBM i administrators can know what is happening on that machine – all the valuable logging information is sequestered on the IBM i.  Network originated threats to the IBM i are often not noticed or responded to by the security team.  This puts a lot of sensitive data at risk and your organization not meeting compliance regulations.

There is an answer.  Townsend Security has been helping customers meet section 10 of PCI DSS with Alliance LogAgent.

Alliance LogAgent

• A complete solution that can capture and forward all IBM i security events
• Built by IBM i experts specifically for SIEM integration
• Robust filtering capability minimizes network impact
• Strong encryption between IBM i and SIEM console
• Seamless integration with ANY SIEM console
• Integrated User Monitoring and log forwarding 

To learn more, we recently recorded a webinar titled “Understanding Log Management on the IBM i.”  View this 30-minute webinar and learn how to meet compliance requirements with real-time security event logging across your Enterprise.

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