Townsend Security Data Privacy Blog

Wherever your sensitive data resides - client side applications, secure data centers, or in the cloud - Encrypt it!

“Sensitive data” is not just credit card numbers and expiration dates anymore.  Because of recent data breaches, we know that loyalty information like names, e-mail, physical addresses, phone numbers; personal data like birthdate, social security number... so much information today... now constitutes what we call personally identifiable information (PII) and must be properly protected with encryption no matter it is stored.

When it comes to protecting data, look to well-defined industry standards for an encryption algorithm that is reviewed and vetted by cryptographers around the world. Advanced Encryption Standard or AES is the most commonly used encryption algorithm to protect sensitive data. Validated by the National Institute of Standards and Technology (NIST), this standard is referenced in a wide variety of compliance regulations either as a requirement or as a recommendation. However, the AES algorithm is not the secret that we have to defend. Think of encryption as the lock that you put on your front door, and the encryption key is your house key. You don’t tape your house key right next to the lock when you leave in the morning, you take it with you and you protect it from loss or theft. Your unique encryption key is THE secret that you must protect, which can be accomplished using a secure, certified key management solution. Getting encryption key management right is in fact the biggest challenge customers and organizations run into when they start their encryption projects.

When you look at what it takes to properly protect sensitive data with encryption, you immediately find standards (NIST) & best practices for key management, and industry compliance regulations (PCI DSS, HIPAA/HITECH, FFIEC, and state privacy laws) that require proper key management. They all say the same thing: “Do Not Store the Encryption Key on the Same Server as the Encrypted Data”.

Encryption key management is a well-defined process with standards and best practices around managing encryption keys and a formal definition of the encryption key lifecycle.  

When an encryption key is first generated, or established, it may not be used for some time so it waits in a pre-activation status until it is being actively used.  The key will expire after use or based on a set definition and then will go into escrow after post-activation. After that period, the key is generally destroyed.

One way to destroy data is to destroy the encryption key that's protecting it, because if the key is not recoverable neither is that data. Auditors will want to know if you have a process for managing the encryption key through the entire lifecycle, and this is one of the things that a key management solution does for you in a provable way.  Beyond the encryption key lifecycle, the key management solution provides access controls for users and groups, in-depth audit trails and system logging with the ability to integrate across multiple platforms, and they must implement a mechanism for dual control and separation of duties to really meet compliance regulations as well as defensible security best practices.

It is also very important for an encryption key manager to provide the option of onboard encryption. The core function of the encryption key management solution is to generate, protect, and distribute encryption keys to authenticated users. If you have a web application or a more exposed cloud environment, retrieving an encryption key may seem risky to you in terms of having that key in your operating environment. With an onboard encryption solution you can send your data to the key manager, name a key, and get that data encrypted or decrypted strictly within the confines of that key management solution. Avoiding the risk of losing encryption keys in a more exposed environment is an important component in a compliance strategy.

Even 10 years ago, encryption key management solutions were very expensive specialized hardware devices and very difficult and time consuming projects. Thankfully, encryption and key management is no longer the development or cost headache it once was. Since IT infrastructures have become very complex environments using different technologies and platforms (60% of Microsoft SQL Server customers are also running Oracle someplace in the organization), a key management solution also needs to address these complexities and protect data wherever it may be. There are still hardware security modules (HSMs) and now there are new options for deployment of cloud-based HSMs, virtual appliances, and true cloud instances of encryption and key management.

Hardware Security Module (HSM) is a physical appliance or security device that is protected and tamper evident. Built for high resiliency and redundancy it has hot swappable rated disc drives, dual power supplies, dual network interfaces, and is deployed in your IT data center.

Cloud HSM is a physical appliance hosted in a secure cloud with real-time encryption key and access policy mirroring.  Dedicated HSMs are hosted in geographically dispersed data centers under an ITIL-based control environment and are independently validated for compliance against PCI DSS and SOC frameworks. No access is available to the cloud vendor or any unauthorized user.

Virtual Appliances are the exact same key management solution - the same binary software that runs inside the hardware HSM - available as a VMware instance.

In the Cloud - If you're running on Microsoft Windows Azure or vCloud, the encryption key manager can run as a true cloud instance in a standard cloud or deploy in a virtual private cloud for added data protection for sensitive applications.

Because encryption and key management is so important, we offer all of the options listed above as NIST validated and FIPS 140-2 compliant solutions. We also want to make sure encryption is available everywhere you need it, so at Townsend Security we have a very different philosophy and approach:

• We think that when you buy an encryption key manager, you should be able to easily deploy the solution, get all your encryption projects done properly, and have very affordable and predictable costs.

• We understand that we live in a world where budget matters to our customers, so we do not charge client-side fees.  

• We understand that IT resources are limited and have done a huge amount of work to make our solutions easy with out-of-the-box integrations, simplified deployments, and also provide along with our solution ready-made client-side applications, encryption libraries, source code samples, as well as SDKs for developers who need them to get their projects done very quickly.

To learn more about key management and how to properly encrypt sensitive data anywhere you store it, download our latest webinar featuring data security expert Patrick Townsend:

With encryption and key management now being offered on a variety of hardware, virtualized, and cloud platforms, is it simply just a matter of preference or is one option better for you than another?  

Companies of all sizes now have options for securely protecting sensitive data using the appropriate security technology for their situation and industry regulations. Being responsible for the safekeeping of sensitive data like credit cards, social security numbers, or e-mail addresses, makes your encryption and key management strategy critically important. Once your sensitive data is encrypted, key managers are the specialized security devices that are designed to safeguard your encryption key (which is the secret that must be protected). Before deciding on how an enterprise should deploy an encryption key manager there are several questions to ask and factors to consider.

What different device options are available to organizations needing an encryption key manager?

Hardware Devices
Today we have many options for key management solutions, including the traditional key management hardware security module (HSM), which is now more cost effective and easy to deploy than it was even five years ago. HSMs are network attached in your data center and accessed when encryption keys are needed. If your company has a physical data center and the infrastructure to support it, an HSM can still be your most secure option.

Cloud-hosted HSM
The cloud-hosted key management HSM functions in much the same way as the traditional security device. However, you do not need to have the infrastructure of a physical data center in order deploy or maintain the cloud-based HSM since it is hosted by the cloud hosting provider.  Be aware of your cloud environment (is it shared or private?), and make sure to choose an option that provides real-time mirroring and redundant backups in geographically diverse locations.

Virtualization Options
Additionally it is now possible to deploy virtualized key management appliances. There is no hardware when you deploy a VMware or Hyper-v or Xen virtualized appliance inside your own virtualization infrastructure. A true cloud-based key management solution like VMware gives you a path to run key management solutions in vCloud either as standard cloud instance or virtual private clouds. Microsoft Azure and Amazon Web Service and other cloud platforms provide a mechanism for deploying virtualized key management appliances too.

What are some factors people need to consider when deciding which key management option is right for their organization?

Risk Tolerance
Risk tolerance is perhaps the main driving force for which of the key management options you might choose. If you're very risk-averse then probably you will want to deploy a hardware security module (HSM) in your own data center.  If you have a moderate level of risk tolerance  you might consider a cloud-based HSM hosted by a cloud vendor with appropriate security technology. A company dealing with small amounts of data might bear some additional risk and use a key management solution to help protect encryption keys in a virtual environment. Cloud or virtual solutions can be much more cost-effective and give enough protection for encryption keys to meet a lower risk tolerance level.

Compliance Regulations
Most compliance regulations give clear guidance on best practices about where encryption key management can and should run. Generally speaking, regulations are based on your industry and what type of sensitive data you store. 

PCI Security Standards Council has issued Cloud Computing Guidelines as well as guidance around virtualization of data protection solutions, so you can be PCI compliant with a cloud-based key management and encryption solution.

Cloud Security Alliance (CSA) has issued good guidance around key management and cloud environments - version 3.

Other regulations are not yet providing concrete guidance,and in some cases it is best to confirm with qualified auditors and assessors to really understand whether or not you can be in compliance and deploy true cloud-based virtualized key management solutions.

Infrastructure
Your key management options are also based on where your data is stored. If you don't have a traditional data center, for example if you are using a software as a service (SaaS) solution, you may not have your own IT infrastructure or personnel with which to deploy a traditional encryption key management HSM internally. So the physical and organizational structure will come to bear in terms of the choices that you have around deploying key management.

Cost
Budget is always an important factor. As you consider various options, ask about endpoint licensing fees and make sure you have predictable maintenance costs as more databases/applications request key access. Remember to consider the costs of not properly managing sensitive data when doing the security cost benefit analysis.

Whatever option you choose, it is always wise to use key management best practices:

• Always separate the encryption keys from the protected data
• Use dual control
• Practice separation of duties
• Manage key rotation
• Look for NIST validations like FIPS 140-2

Please download our most recent podcast on Encryption Key Management Options to hear more about how to meet the challenges of running cloud or virtual applications where implementations are inherently shared, multi-tenant environments!

The PCI conference is just finishing up and I’ll have more on the conference a bit later when information can be made public. One of the interesting talks was by Chris Novak of Verizon. I just want to recap some of his thoughts.

The number of highly targeted and sophisticated attacks is on the rise. We’ve heard this message over the last few months, and the Verizon study confirms this. A highly targeted attack goes after a specific companies’ assets with a lot of knowledge about the internal systems. The ability of the attacker to cloak the software is good, and the sophistication of the attack is high. These are highly knowledgeable technicians creating the malware, and they are getting good at attacking sophisticated systems like such as Hardware Security Modules (HSMs) that store or process encryption keys. The targets are usually companies with a large concentration of high value financial information. It’s expensive to launch these types of attacks, and the payoff is high. When these breaches are discovered they get a lot of press. But here’s an interesting fact: These sophisticated attacks on specific targets are still in the minority. Over 80 percent of the breaches are pretty low-tech. That’s right, amazingly most of the attacks are against web servers and most of these use SQL injection as the way to get inside. What’s stunning is that we’ve known about SQL Injection attacks for a long time. We know how the attacks are made, we know how to test for the weakness, and we know how to remediate the problem. So why haven’t we made much progress in preventing this exposure?

First, we aren’t paying enough attention to our web sites which are not directly related to credit card process. Novak used the example of an attack on a companies’ HR web site. The company posted job openings on the site and did not think it was much of a target. But attackers gained entry to this job postings web site, and then navigated through the internal network to a high value target.

The lesson? We know what to do, we just need to apply that knowledge more broadly.

We might also ask why are we still having a problem with SQL injection? Novak had an interesting take on this, too. To prevent a SQL injection attack you have to use good programming practices. You can’t just plug in an intrusion detection device and think you are safe. You prevent SQL injection by changing the way you develop web and business applications. Do you know what OWASP is? If not, there’s a good chance you are exposed somewhere in your application code to SQL injection.

The lesson? We have to get much more serious about secure programming. If you are a developer of web or business systems, you should know the OWASP Top 10 forwards and backwards. If you manage a development group, be sure everyone is trained on secure programming practices. Make it a requirement for hiring and promotion.

I will leave you with one more interesting point from Novak’s talk. In almost all breaches that Verizon studied, there was enough information in the system logs to identify the attack, but the logs were not reviewed and the attack went undetected.

The lesson? We need to monitor our system logs a lot better. This means investing in software that can automatically sort through the large number of logs and tell us when there is a problem.

There are positive changes under way at the PCI council and I will discuss these more in the days ahead. But one big take-away is that we need to do better what we already know we should be doing. This part is not rocket science.

Patrick