Townsend Security Data Privacy Blog

We’ve heard a lot of different excuses and reasons for a company to decide not to encrypt sensitive data — ”it’s not in our budget”, “a data breach won’t happen to us”, etc. For the companies out there who are taking responsibility to protect their customers’ sensitive information with encryption, we also often see these companies fall prey to a few common pitfalls that make their encryption strategy weak. A weak encryption strategy isn’t much better than having no encryption strategy at all. Here are the top 10 encryption pitfalls to avoid in order to implement strong encryption:

1. Failure to Asses Risk

We are still finding today a lot of organizations and companies that have not implemented any type of data protection at all. When we talk to a company taking credit cards and not encrypting that credit card information, we know that they've not properly done risk assessment on what it  means to fail a PCI-DSS audit or have a breach when you're not meeting PCI-DSS standards. The risks associated with a data breach not only include fines paid to the government, but also the cost of credit monitoring for your customers with compromised data, loss of trust from stakeholders, and damage to your brand name.

2. Encryption Key Management

Once you start an encryption project you’ll be faced with the one, core technical requirement: protecting the encryption keys. One of the biggest causes of audit failure for encryption is not adequately protecting those keys. Getting a secure, FIPS 140-2 compliant key management device in place to protect your encryption keys will help you avoid having to go back and re-do your encryption project using proper key management.

3. Client Side Support

Does your vendor supply you with all of the tools you need to implement encryption and key management? Choosing a vendor the provides poor client-side support can be a huge detriment to your encryption project. That is why it’s important to choose a vendor that will provide sample code and applications that snap into client-side environments to make your encryption project faster and easier.

4. Virtual and Cloud Environments

Today, security is the number one concern for companies migrating to the cloud. The principles of encryption and key management remain largely the same, but the question of how to manage keys for encrypted data in the cloud is still debated. Hosting encryption keys “in-house” is currently the most common model. Even if you’re managing your encrypted data in-house, be aware that you may choose to move to a virtual cloud environments in the future, and you will want to make sure that your encryption strategy and key management strategy can migrate with you to the cloud

5. NIST and FIPS Certifications

Industries that deal with sensitive client information such as credit card numbers, social security numbers, and private health information must adhere to regulations (some of them governmental) in order to protect individuals’ personal and sensitive information. These regulations follow recommendations by the National Institute of Standards and Technology (NIST). When protecting data at rest, you should be using Advanced Encryption Standard (AES) encryption, which is a standard put forth by NIST. You should also look for a key management device with FIPS 140-2 validation, also a NIST standard.

6. Performance - What are the Performance Impacts?

It’s possible to encounter serious performance impacts when you implement encryption. That’s why we not only recommend you use only AES and NIST certified solutions, but that if you’re the IT person dealing with the encryption, that you do some preliminary testing of the encryption on a sample database the same size as the actual database you will be encrypting. Your encryption and key management vendor should be able to help you do this with ease.

7. Ease of Use

An encryption and key management solution that is difficult to use can lead to a slowed project, unexpected costs, and delays. This can be a huge roadblock, especially if you are struggling to address a data protection problem or meet deadlines imposed by compliance regulations. To avoid ease-of-use problems, look for a solution with a GUI interface designed to run on your platform and allows you the necessary points of access to your encrypted data and encryption keys.

8. Data Leakage to Quality Assurance (QA) and Test Environments

Segmenting your critical data apart from non-critical data is an important step in preventing leakage of the critical data onto unprotected environments such as testing and development environments. Simple employee mistakes make up a large portion of data breaches that occur every year. Knowing which servers your sensitive data is located on and making sure that data doesn’t accidentally get moved to and unsecured location is critical.

9. System and Compliance Logging

Most compliance regulations including PCI-DSS recommend if not require some sort of system logging of your critical data. Whether it is file integrity monitoring or system logging to collect and store security events, these tools help you to catch changes to your database in real time. This is actually one of the most important parts of data security, and many data breaches can be immediately detected with system logging.

10. Budget Should Not Be a Barrier

When implementing encryption and key management, trying to save money by skipping steps will cause you a great deal of grief. Conversely, your encryption and key management vendor should be able to offer you a NIST certified,  scalable solution at an affordable price.

Q: What is enterprise key management? What questions should I ask an enteprise key management vendor?

When it comes to protecting sensitive data, it’s fairly common knowledge today that the best way to protect that data is to encrypt it. Companies of all sizes must do this whether they’re taking credit card information, names and addresses, or protected health information. These days encrypting your data is pretty easy. Some operating systems even do it for you, automatically. And if you have a fairly small database of sensitive data that’s stored all in one place, then the key management for your encrypted data is also pretty straightforward.

However, not all networks are so simple. Many times I run into companies who not only store their data on several different operating systems, but they also use several different versions of each system. With such a highly complex network, it can be difficult for IT administrators to easily encrypt all of their sensitive data. They might not even know where their sensitive data is! The complexity of the database infrastructure might be so overwhelming, that implementing an encryption key management system doesn’t even seem feasible.

That’s because these companies don’t just need a key management solution, they need an enterprise key management solution.

Enterprise key management is term being used to today to refer to professional key management systems that provide encryption keys across a variety of operating systems and databases. A network, for example, might be comprised of several different versions of Microsoft SQL Server as well as IBM i, Linux, UNIX, or Oracle servers, as well as backup tapes and data stored in the cloud. The encryption key manager needs to be able to communicate simultaneously with all of these locations in order to provide encryption keys, decrypt, and rotate keys.

Your enterprise key manager (not to be confused with Extensible Key Management, or EKM for Microsoft SQL server) should have high availability and be located centrally in the network, typically in a protected hardware security module (HSM). When looking for an enterprise key management solution, make sure you ask your key management vendor these important questions when assessing their solutions:

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

For more information on the importance of encryption key management, download our ebook "Definitive Guide to Encryption Key Management Fundamentals" and learn how to overcome the challenges of deploying encryption key management in business applications.

Encryption key management has a bad reputation. How bad? I once heard a SQL Server professional describe encryption key management as so costly and difficult to implement, it is a “nightmare.”  It’s hard to imagine that attempting to simply manage your encryption keys evokes images of terrifying dreams that wake you up at night in a cold sweat. However, for many database administrators who must encrypt data, the idea of incorporating a good encryption key management strategy (dual control, separation of duties, etc.) really does sound like a daunting task. Most DBAs assume that a key management project is time consuming, expensive, incredibly complicated, and requires specialized third-party consultants. Simply getting the encryption key manager up and running is a huge headache.

We don’t believe good encryption key management needs to be difficult. In fact, we believe that good encryption key management should have these 9 easy features:

1. Easy to Install: A single-use (1U) server plugs right into your IT infrastructure and requires no on-site technician to install.
2. Easy to Configure: Install your license, certificates and keys, configure options, and start the server all within a standard, secure web browser and administrator console.
3. Easy to Manage: Operate your console within secure and authenticated TLS sessions, use two admins for dual control, collect logs, manage multiple servers as well as manage local and remote key servers, all through one interface.
4. Easy to Evaluate: Evaluating a product before you buy shouldn’t be difficult. You should be able to evaluate the product without any hardware on a ready-to-use VMware instance or an internet-based demo server, pre-configured with licenses, certificates, and keys.
5. Easy on Developers: Developers should be provided with a rich library of documentation and sample code to use in their applications for any platforms that need more development to get key management running smoothly.
6. Easy to License: You should not need to license every end point that connects to the key server. The cost and complexity of licensing all endpoints is unnecessary and can be a huge barrier to getting data protection up and running quickly across the organization.
7. Easy to Own: Key management should be affordable to small and mid-sized businesses. The solution should be scalable to each organization’s needs.
8. Easy to Deploy: Customers should always have access to direct shipping, a simplified order process, remote configuration, and installation services.
9. Easy to Sell: Integrating a key management solution should be easy for partners and include easy software integration, thorough technical and sales training, multiple support plans, and flexible and tiered solutions!

Looking for key management as easy as this? View our webcast, “Encryption Key Management Simplified - Removing Complexity & Cost” to learn more. Or contact us for a technical overview on Alliance Key Manager, our encryption key manager, with one of our technical sales support representatives.

Microsoft made a huge Windows Azure cloud announcement this June with their support for full Windows Server workloads including support for all major versions of SQL Server. Prior to the June announcement, Azure only supported Windows applications, and a simple database called SQL Azure.  Now you can deploy full production Windows server instances to Azure. That is a really big change.

However, study after study shows that the number one concern of organizations moving to the cloud is security. And the number one security issue is protecting sensitive data. And the number one problem in the area of data protection is how to manage encryption keys.

By now most of you know that we have a strong partnership with Microsoft around SQL Server encryption. For months we’ve been helping customers protect SQL Server data using Alliance Key Manager, our encryption key manager. We cover every version and edition of SQL Server for encryption with NIST-certified encryption key management. Whether you are using SQL Server Enterprise Edition with Transparent Data Encryption (TDE), or SQL Server Standard or Web Editions without the TDE support, or even older versions of SQL Server – we have encryption and key management solutions that help you meet compliance regulations.

So it is natural that we are hearing a lot from Microsoft customers about securing data in Azure. But how does all of this work in the Azure environment?

The short answer is – it works in Azure just like it works everywhere else. Regardless of the Azure platform you are using, our encryption key manager protects the encryption keys that protect your data. You can run full SQL Server TDE in Azure, or you can run SQL Server Cell Level Encryption, or you can use our Windows .NET assembly to protect data in your .NET applications.

In the same way that we protect SQL Server data in traditional IT environments, we protect it in every Microsoft Azure environment, too. And that means we protect SharePoint 2010 and Dynamics, too, when they are deployed on top of SQL Server with TDE.

When you protect SQL Server with Alliance Key Manager, you can host the key server in your own data center, or you can install it at your own favorite hosting provider, or you can use a key server in our hosting center. The choice is yours.

Moving applications to the cloud involves many challenges. Exposing your data without proper encryption does not have to be one of them.

Patrick

One of the worst scenarios we can think of when it comes to encryption and encryption key management is having to do your encryption project a second time around. We see this again and again when companies come to us after realizing they’re about to fail or have failed a data security audit due to a number of reasons:

• They did their own “home grown” encryption project
• Were not using an external HSM to house their encryption keys
• They were not using dual control to manage their keys
• Or any other reason that made them, in the end, not compliant with the industry regulations they face (PCI DSS, FFIEC, GLBA, etc.)

The unfortunate thing about these situations is that these companies are forced to redo an entire encryption project that they’ve already invested time and money into. Going through this process twice, however, is completely unnecessary if you take the right steps the first time around.  Here are three things to keep in mind before you start your encryption project.

1. Know your compliance requirements and security best practices before you start

The first step is to identify which data security compliance regulations you face. If you collect credit card information, you must comply with PCI DSS. If you collect personal health information (PHI), you must comply with HIPAA-HITECH. If you’re a financial institution, then you must be compliant under FFIEC and GLBA. Publicly traded companies must comply with the Sarbanes-Oxley Act, and any company collecting personally identifiable information (PII) will almost always fall under state or other data security compliance regulations. Many companies fall under several compliance regulations and you must be aware of these.

All of these regulations require that you protect your sensitive data, and the only way to truly accomplish that is with AES standard encryption used correctly. These regulations also recommend—if not require—encryption key management best practices, such as dual control and separation of duties, which can only realistically be implemented using an external hardware security module (HSM) to house your keys. HIPAA/HITECH, for example, doesn’t outright require good encryption key management. However, if your healthcare company has a breach, and isn’t using key management best practices, your data will be considered compromised and you will be thrust into the costly process of data breach notification.

2. Do your encryption key management right

Hackers don’t break the encryption, they find the encryption keys. Storing keys and protected data on the same server will almost always lead to an audit failure, and will leave you highly susceptible to a data breach. If you’re not doing a good job managing your encryption keys by using an external HSM and dual control, you’re already in line for a costly audit failure or devastating data breach.

3. Choose a solution that’s NIST certified

Choosing encryption and key management solutions that are National Institute of Standards and Technology (NIST) certified will ensure you’re meeting the minimum requirements. NIST determines the highest standard for encryption and provides pointers and best practices for managing encryption keys. You should also avoid cutting corners by doing your own “in house” encryption project. Recently, a study by Symantec found that over fifty percent of unauthorized encryption projects resulted in serious problems with encryption keys. Unprotected encryption keys leads to data breaches and audit failure.

When it comes to protecting sensitive data, you should never cut corners because of cost. Many small to mid sized companies forgo data security because they perceive the monetary cost of an encryption project to be too great. The truth of the matter is that a lack of proper data security could result in millions of dollars in fines and damage control. The cost of an average-size data breach is $5.5 million. In the end, data security is an investment to protect your business from a costly breach that many companies never recover from.

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

When it comes to encrypting data in the cloud, encryption key management can get a little tricky. I sat down with Patrick Townsend, CEO and Founder of Townsend Security to ask: If key management is so important for compliance, how can organizations working in cloud platforms such as Microsoft Windows Azure be sure they’re deploying good key management?

First of all, when you’re encrypting data, you should never, ever store your encryption keys on the same server where your encrypted data is stored. When it comes to encryption key management for cloud applications, there are really 3 different models:

1. Use an external Hardware Security Module (HSM) as part of your own IT infrastructure.
This model allows applications running in Windows Azure to use encryption services or retrieve an encryption key through a secure connection to the key server placed in your own IT infrastructure. Using dual control and separation of duties, this is usually the best and easiest model for Cloud users and will help you to meet data security compliance regulations.

2. Outsource encryption key management to a physical hosting environment.
Rather than placing an encryption key management HSM in your own infrastructure, you can use a professional hosting company to hold your key management server in a high security hosting environment. With this model, your Windows Azure applications will communicate to the hosted key server off-site to perform encryption and key retrieval services.

3. Run Key Management in The Cloud.
Storing encryption keys in the cloud is generally considered a bad idea. The cloud is typically a less secure environment because its services are usually shared with other users. These services include disk space, memory, and other facilities that other companies may also be using. In a cloud environment there are more factors and complexities at play, and many unknowns about how the cloud provider protects the data. Even compliance regulations such as PCI-DSS mention these risks associated with the cloud. That’s why we recommend companies use an external HSM, ideally within their own infrastructure, to keep their encryption keys under their own control and eliminate unknown factors.

In the end, however, the model you use to store encryption keys isn’t the last step to protecting your data and meeting compliance. You must always, always, always, have a strategy for managing keys that includes dual control, separation of duties, and split knowledge. There are some companies using an external HSM for their keys and are still not meeting compliance regulations because they are managing their keys poorly.

Want to learn more? Check out the Podcast, “Securing Microsoft Windows Azure with Encryption and Key Management” to learn how to meet compliance regulations with encryption and key management, performance considerations, managing encryption keys, and what to look for when deciding on an encryption key management solution.

I am often asked about how one can restrict access to Alliance Key Manager (AKM), our encryption key manager.  There are a few different options available here in relation to locking down and controlling who has access to which keys.  This often is a concern for bigger organizations that have multiple departments authenticating to the encryption key manager and performing key retrieval operations, but I’ve known smaller companies as well that take advantage of the granularity AKM provides in this area.

One way you can restrict access to Alliance Key Manager is by restricting keys to specific users or groups of users. The users and group access can be defined on a system level, or at the level of each key. When you create a key you can define the restrictions on user and group access.

Since all connections to AKM are mutually authenticated over a TLS session, you as a client (key requestor) must present an X509 digital certificate to AKM that is signed by a trusted Certificate Authority (which needs to be known to the key server).  Within your client certificate are multiple fields of user data collectively known as the Distinguished Name (DN). Further, within the DN you'll define fields with information regarding who you are, what organization you are with and where you're located. There are two fields in particular that the AKM server will look at to determine your Group or User privileges. These are the Common Name (CN) field and the Organization Unit (OU) field. We look at the common name to determine user access and the organization unit to grant group authority.

Lets look at an example.  There is an AES encryption key available on an AKM server used to protect an employee's personal data. It is restricted so that only members of the Human Resources group can use that key. So any individual with "Human Resources" defined as their OU can successfully request that key, all others are turned away. This is Group Restricted Access.

To further this example, the director of Human Resources, Sam, needs access to a specific key only he can use. There would then exist an encryption key on AKM that has group and user policy defined as "Sam / Human Resources" and Sam's X509 digital certificate would have the CN of "Sam" and the OU of "Human Resources." This would ensure only he is allowed to access that key. This is strict group and user control of key usage and deters other "Sams" in the company from getting the key, as well as other individuals within the "Human Resources" department.

There are a few other ways to restrict access. You can specify just specific users who can access keys and ignore the group altogether. This would require defining a user table within AKM and tying specific keys to it. Then any user with the appropriate CN can authenticate and use those keys. The same can be done for groups as mentioned previously or any combination of group or user status as defined by the group or user table laid out on AKM.

And lastly you can allow anyone with an authenticated x509 digital certificate that can latch up to the key server successfully request a key. This method ignores the CN and OU altogether and is the least restrictive level of key access. However it still locks down key control as only authenticated clients with proper certificates can gain access to encryption keys.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

The task of deploying encryption key management into your infrastructure to meet security and compliance best practices can be overwhelming at first.  To help give you a 'bird's eye view' of the core components of our Alliance Key Manager (AKM), our encryption key management HSM, I want to breakdown the three major components to it.  Having this understanding in your back pocket as you roll out AKM can help smooth out the process.

First up, your security team can utilize our AKM Java GUI console to create and manage AES encryption keys for use in your applications.  This is a program that you install on a Windows machine that communicates directly with the key server via a secure TLS session.  Here, keys can be created, expired, revoked, rolled or even deleted – requirements of PCI DSS and other compliance regulations.  You can also define a key access policy for each key that is created, specifying what groups or individuals can request and use it.  Alternatively, you can also use our Linux command line facility to completely automate encryption key management through scripting calls.

The second component focuses on your application that's doing encryption and requires access to an external key manager.  You’ll need to make some minor coding changes to your application layer to enable it to make API calls to our shared library that does key retrieval portion.  To help you succeed here we offer sample code in a variety of programming languages for your development team to work with.  All of these samples can be found on the AKM product cd.

If you need Extensible Key Management (EKM) for Microsoft SQL Server 2008 Enterprise Edition and above you can take advantage of Transparent Data Encryption (TDE) or Cell Level Encryption.  We see many organizations use TDE and EKM because they can easily implement encryption without changing any of their applications - and can be deployed relatively quickly.

Finally you have the ability to physically manage the key server appliance itself.  By using a web browser directed at the IP address of the appliance on your network you can create system and database backups, define mirrored servers, and enable Syslog to meet PCI-DSS and other compliance requirements.

Download our “Encryption Key Management Simplified” resources kit to find more information on meeting PCI DSS and HIPAA, encryption key management best practices, and more.

One of our customers recently submitted a support ticket related to a question asked by their QSA Auditor.  Just a quick background on our customer - they have an all IBM i environment and are using AES/400, our NIST-certified AES encryption among other data privacy solutions we offer.  This customer needs to comply with PCI because they are accepting credit cards and store personally identifiable information (PII). The question was: How does your AES encryption software prevent unauthorized substitution of cryptographic keys?

At Townsend Security we stress the need for encryption any time you have sensitive data, but that is only half of the battle.  You also need to protect the encryption key with a key manager.  Did the question about substitution of cryptographic keys surprise us? No, it didn’t.  This is a great example of what is happening out in the business world.

If your encryption is weak (did you know there is weak encryption?), this is a legitimate concern. There is a “key store” on the IBM i that stores encryption keys, but it’s like putting your house key underneath the welcome mat to your front door.

If you are using our Alliance Key Manager (our encryption key management HSM), we use NIST FIPS 140-2 best practices for detecting key substitution or key corruption. This involves the use of an HMAC mechanism with each key stored in the key management appliance.

What kind of questions are your QSA Auditor’s asking?  We would love to hear from you, whether you are a current customer of ours or not.  If you are interested in hearing more download our podcast on compliance and encryption key management.

How easy is securing and protecting sensitive data on SharePoint?

Over time Microsoft has been moving SQL server underneath almost all of their core enterprise products (SharePoint, CRM, Dynamics, etc.), which is great news for IT administrators because SQL Server supports automatic encryption. This means that protecting your SharePoint database and meeting compliance regulations (PCI-DSS, FFIEC, HIPAA, etc) is easier than ever.

SQL Server Enterprise and higher editions (starting with 2008 through 2012) fully implements extensible key management (EKM) and encryption to protect data. Installing encryption on that platform is the first step--administrators can then leverage the automatic encryption capabilities of SQL Server with only a few commands and no application changes. The second step is to understand the importance of protecting your encryption keys using separation of duties and dual control on an external Hardware Security Module (HSM).

The path to implementing encryption and key management for SharePoint is one of the most straightforward and easy paths. Townsend Security’s Alliance Encryption Key Management solution fully supports automatic SQL Server encryption and integrates with ease.

What impact does encryption have on SharePoint performance? Should users and administrators be concerned?

Encryption will always be a CPU intensive task and there will be some performance impact due to extra processing power needed for encryption and decryption. However, the Microsoft encryption libraries as well as the .NET environment are highly optimized for performance. I have always seen very good performance on SQL Server and the native encryption capabilities that it provides. Microsoft reports that Transparent Data Encryption (TDE) on SQL Server may cost you 2-4% penalty in performance, and our own tests show similar results that fall on the 2% end of things. There are also several encryption and encryption key management solutions on the market, and each one performs a little differently. 

Ultimately, performance depends on the amount of data you’re storing, and I always recommend that a customer take into account all factors that affect performance including encryption, number of users, size of documents, number of documents, and the underlying platform they’re using.

Lastly, it’s important to note that using an external HSM for key management (a critical piece of compliance), like our Alliance Key Manager, does not affect the performance profile of the database that is under protection.

In the end, if you are storing sensitive information on SharePoint, then you likely fall under industry regulations and state privacy laws. Regardless of your industry segment, whether its medical, financial, retail, education, or government bodies, you have a lot of choices to get your sensitive data data properly protected.  At the end of the day, if data gets out and it’s unencrypted, you have a data breach on your hands.

To learn more about securing SharePoint with Encryption and Key Management, listen to our latest podcast here.