Townsend Security Data Privacy Blog

If you're starting an encryption key management project, you should always know the warning signs of obstacles that might make your project way more difficult and costly than it needs to be. We often see companies who have recently failed a data security audit, or realize that they are about to, because they didn't watch out for these pitfalls before they began an encryption key management project.

1. Complicated Project Requiring Outside Consultants and Time
If you find yourself bogged down by hiring outside consultants (beyond your encryption key management vendor) to help you set up and run your encryption key management system, you're probably headed for trouble. Encryption key management should be simple, straightforward, and easy to deploy.

2. No Certifications
NIST certifications are a must when it comes to implementing good encryption key management. In order to meet compliance for PCI-DSS, GLBA/FFIEC, FISMA, and other compliance regulations, always use NIST-certified AES encryption and FIPS 140-2 compliant encryption key management. Your QSA or other data security auditor will look for these certifications.

3. No Client-Side Support
Your encryption key management vendor should supply you with the appropriate client-side applications to make your encryption key management run as smoothly as possible. If you find yourself scrambling to find sample code, binary libraries, key retrieval and other tools, your encryption key management project time will almost certainly increase and not come to a complete halt.

4. No Dual Control and Separation of Duties
When it comes to doing your encryption key management right, one of the critical pieces to meeting compliance requirements such as PCI-DSS is using the principles of dual control and separation of duties. These are hard and fast guidelines when it comes to the handling of encryption keys, and are considered a "best practice" for encryption key management. If your encryption key management hardware system doesn't implement these policies, it will be difficult to pass your data security audit down the road. Some compliance regulations such as HIPAA/HITECH Act don't yet require these policies; however, you should expect these best practices policies to be implemented into regulations down the road.

5. Complex and Hard to Predict Licensing
When you don't know how much your encryption key managemer is going to cost, your project will stop in its tracks. When you don't know how many licenses your company will need over time and how your encryption key management vendor will charge you for them, estimating the cost becomes very complicated. Often a vendor might limit how many devices can connect to your key server or the number of keys the key server can create, resulting in unpredictable costs. As we all know, a project with an unpredictable cost never gets off the ground! The cost of licensing should not be a barrier to protecting your sensitive data.

To learn more about how encryption key management and how easy it can be, check out our webinar, “Key Management Simplified.”

XN3H7FQ298CU 

Today there are so many ways to lose control over sensitive data. Hackers are constantly trying to access networks, laptops get stolen out of cars, and unauthorized employees are given access to data that they were never meant to see. With so many ways to lose data, no wonder so many IT execs bury their heads in the sand at the idea of data security. It seems like there's nothing they can do.

Unfortunately for those people who ignore the pressing need for tighter data security (and are probably setting themselves up for a data breach), there is something they can do. They can encrypt their data, and they can use key management best practices to protect their encryption keys.

Encryption and key management are considered the highest standard in data protection, and are required or recommended by most industry regulations such as PCI-DSS, GLBA/FFIEC, FISMA, and HIPAA-HITECH Act.

But what exactly is encryption and why do you need key management?

I recently talked with data security expert Patrick Townsend, founder and CEO of Townsend Security, to find out. Watch the video of that discussion here.

What is encryption?

Encryption is a means of encoding data using an encryption algorithm to render data unreadable. AES encryption is a standard put forth by the National Institute of Standards and Technology (NIST). It is accepted as the strongest method to secure sensitive data. Encrypted data looks like gibberish. For example, an encrypted version of the name "John Doe" might look like "Ue%#KD#@". In order to read the gibberish, someone must have access to the encryption key, which unlocks the encrypted data to make it readable.

What is an Encryption Key?

When you encrypt data, an encryption "key" is created. Each encryption key is unique.  Encryption keys are the secret that must be protected. Encryption keys are a lot like the keys you use to lock your house. It's likely that you and several of your neighbors use the same kind of lock on your door, but each of you owns a unique key. Like a house lock, encryption uses the same algorithm to encrypt data, however in each instance, a unique key is created to unlock each piece of data. Losing your encryption key to a hacker is like losing your house key to a thief.

Hackers don't break encryption. They find the keys.

A lot of IT executives have dug themselves into a hole because they know they need encryption and key management, but they don't want to admit to their bosses that they've been ignoring the issue--and putting the company at risk--for years. It can be a very difficult subject to talk about, especially when budget has played a role in the decision making.

If you’re ready to begin having this discussion with your IT team, you should arm yourself with the right questions. We recommend you check out this video, “What is Encryption Key Management?” featuring Patrick Townsend, Founder & CEO of Townsend Security.

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

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.

Microsoft has announced that the October Windows update will change Windows support for certain RSA key sizes.  Our customers have asked:  How will this affect our use of your encryption key manager? Do we need to worry?

No, you don’t need to worry. Here’s why:

Microsoft operating systems will remove support for RSA keys smaller than 1024-bits. The use of 1024-bit and larger keys will still be supported without change. So, only RSA keys that are SMALLER than 1024 are affected.

Alliance Key Manager, our encryption key management HSM, enforces the use of 2048-bit keys and does not allow they use of keys smaller than 1024 bits. NIST has recommended that applications migrate to larger RSA key sizes for some years, and we built Alliance Key Manager to meet those key size best practices. Today, no application should be using an RSA key that is less than 1024 bits.

Our existing customers will not be affected by this Microsoft change. If you are using Alliance Key Manager for Microsoft SQL Server Transparent Data Encryption (TDE), Microsoft SQL Server Cell Level Encryption, Microsoft SharePoint 2010 with SQL Server TDE, Microsoft Dynamics CRM, or our Microsoft Windows .NET client applications, you will not be affected by this change.

We simply do not allow the use of insecure RSA key sizes.

Download our podcast "Encryption Key Management" to learn more about encryption key management and what auditors are looking for and how to easily manage your encryption keys.

Patrick

If you have Microsoft SQL Server with Extensible Key Management (EKM), the implementation of encryption and key retrieval with Alliance Key Manager, our encryption key management Hardware Security Module (HSM) is easy. Our HSM comes with the Windows EKM Provider software that you install, configure and deploy.  Problem solved.

But what if you have a significant investment in Microsoft applications that don’t support EKM?

For example, you might have applications built on SQL Server 2005 or SQL Server 2008/2012 Standard Edition which do not support EKM. You could upgrade to SQL Server 2008 R2 or SQL Server 2012, but there might be application roadblocks that prevent the upgrade right now.

Or, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data.

These technical hurdles won’t stop you from using our encryption key manager to meet compliance requirements for protecting encryption keys. We provide a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# code and you are retrieving the encryption key from the HSM, and the problem is solved.

The sample code on the product CD will get you up and running quickly. There are C# sample applications with source code that you can use as a starting point in your projects. The Alliance Key Manager .NET Assembly works with any .NET language including C#, C, and C++.

The Alliance Key Manager .NET Assembly also works with the Common Language Runtime (CLR) environment, and with Stored Procedures. And you can mix and match your .NET languages, databases, and OS platforms.

The combination of automatic encryption (EKM, TDE, Cell Level Encryption) with the Alliance Key Manager .NET Assembly code means that you won’t have any gaps in your coverage of your Microsoft platforms.  Download our white paper "Key Management in the Multi-Platform Environment" for more information on securing your encryption keys.

Happy coding!

Patrick

So you've decided to purchase an encryption key management HSM to help you pass a QSA audit and meet PCI DSS compliance.  Unfortunately just showing the auditor your paid receipt and key manager is not enough to satisfy requirements.  You have to actually be using them in a production environment.  Fortunately this is a fairly simple process to get started with Alliance Key Manager, our encryption key management HSM.  

Once the appliances are assigned IP addresses and reachable on your network, there are three fundamental tasks that you should complete prior to going into production.

First you'll want to setup and configure mirroring to your H/A failover server.  This is as easy as toggling on outgoing mirroring in the AKM.conf file of your primary server.  Next you'll want to have one of your Security Admins log into the Java based AKM Admin console for the production server and point it towards the failover server that will be receiving all the mirrored commands.  The final step to complete mirroring requires logging into the failover server and defining the incoming mirror details in the AKM.conf file for that appliance.  You'll also want to be aware of any firewalls in your network that could inhibit traffic and add exceptions accordingly.

The second part to deploying an encryption key management appliance involves defining your log collection of system logs for audit purposes and meeting section 10 of PCI DSS.  Alliance Key Manager supports transferring system logs via syslog-ng to a log collection server that is running a SIEM solution.  This is configured in the standard syslog manner by defining a log source, destination, and path.

The final and surprisingly perhaps most overlooked step to appliance setup is the creation of system backups.  Within Alliance Key Manager you will create two different types of backups from the outset.  The first will be a backup of your key encryption keys and configuration settings.  This backup needs to really only be run once during the setup of the device as there won't normally be changes to these settings going forward.  The second backup will be of the primary key management database, which will contain all your data encryption keys used by key retrieval clients.

During the backup process you'll be asked where you want these backups stored and define a backup destination.  Your choices include a local directory on the key server itself or sending it to an FTP server using SSL or SSH.  We  recommend sending your backups to a secure FTP server off the appliance in the event of a hardware failure and you can't reach the backup directory you'll still have access to these crucial images elsewhere for restoring purposes.

To make life easier on your network team we provide a scheduling facility that allows you to automatically create and transmit these backups at any specified time of your choosing.

Tackling these three tasks while setting up your Alliance Key Manager HSM will help you well on your way to passing that QSA audit.  The deployment team at Townsend Security can help you breeze through these steps as well as provide you documentation that covers these items in further detail.

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.

I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM.  Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management.  I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.

To get started, when creating a symmetric key, you assign it a user friendly name.  This can be something as simple as ENCKEY_HR.  This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it.  And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key.  Your options are 128 bit, 192 bit, and 256 bit keys.  I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data  

When creating keys, you’re allowed to set activation and expiration dates.  This allows you to pre-create keys and to define a schedule as to when a key can be made available for use.  You may want to have a policy where keys expires every few years and you revoke their use from users.  If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys.  When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key.  The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use.  Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.

To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.

Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage.  I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go.  Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key.  These fields enable you to easily track important details relevant to the key throughout its lifecycle.

Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.