+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

HIPAA and Encryption - What You Need to Know

Posted by Patrick Townsend on Oct 10, 2017 8:46:26 AM

HIPAA regulations regarding data security for patients are hard for a layperson to understand, and are even difficult for administrators and technologists who work in the healthcare industry. This is especially true for smaller organizations, partly due to the complexity of the HIPAA law itself, and the HITECH regulations that followed it. Let’s try to clear up some of the misunderstanding around HIPAA and encryption, and clarify what you should do regarding data protection for patient data.

Achieve saThe first confusion about the protection of patient data is that encryption of this data is a strong recommendation, but that it is not a mandate. It is what is termed an “addressable” requirement. The word “addressable” has very specific meaning in the context of HIPAA. If implementing encryption of patient data is not feasible, a healthcare organization under HIPAA regulations, can implement equivalent protections. So, if your software vendor or IT department thinks that encryption is not feasible you have the option to implement other equivalent security controls to compensate for that. The reasons why you think it is not feasible must be documented in writing, and must be reasonable and valid.

Encryption is not a mandate under HIPAA law. And unless the law changes, it is probably not possible for HHS and its Office for Civil Rights (OCR) to make it mandatory.

But there is much more that you need to know. While HHS and OCR cannot mandate the encryption of patient data, they do have the ability to make it painful if you don’t. And that is exactly what they are doing. For example, if you claim that you can’t encrypt patient data, document your reasons, implement compensating controls, and THEN have a data breach, you are likely to be penalized for the lack of effectiveness of the compensating controls. Your data breach is clear evidence that your compensating controls were inadequate.

I like to call this a “Backdoor encryption requirement”. That is, there is probably nothing you can do in the way of compensating controls that are equivalent to encryption. But you won’t discover that until you have a data breach.

Lacking the ability to mandate encryption, HHS and OCR have taken to the strategy of increasing the penalties for lost patient data. I’ve heard recently from many organizations in the healthcare segment of increasing concern about the potential fines related to a data breach. This is driving a new interest in encryption and the related requirement to protect encryption keys.

This last point is crucial when implementing encryption for HIPAA compliance - your encryption strategy is only as good as your encryption key management strategy. Encryption keys are the secret that has to be protected. If you lose the encryption key, the cybercriminals have the ability to access patient data. Storing encryption keys in a file, in application code, or on mountable drives or USB storage will certainly fail a best practices review. Use a professional, certified key management solution in your encryption deployment to protect patient data.

If you are going to do encryption of patient data, get it right the first time! Use good key management practices.

Patrick

Achieve Safe-Harbor Status from HIPAA Breach Notification

Topics: Encryption Key Management, HIPAA, AES Encryption

The Cloud and Encryption Key Custody

Posted by Patrick Townsend on Aug 1, 2017 11:32:25 AM

You should be concerned about storing encryption keys in the cloud, but probably not for the reason you think.

Webinar: Securing Data in the Cloud with Encryption Key ManagementOne of the most common questions I get about cloud encryption key management is “Who has access to my encryption keys?” As customers migrate to Microsoft Azure and Amazon Web Services (AWS), it is really good to understand the policy implications of cloud service provider encryption key management services. And it is not a topic that cloud service providers like to discuss very much.

The truth is that common key management services such as Microsoft Azure Key Vault and Amazon Web Services Key Management Service (KMS) are under the control and management of Microsoft and Amazon. The user interfaces and APIs available to customers on these cloud platforms are easy to use and very inexpensive, or even free. So they are very attractive to new cloud customers.

So what is the problem?

First, I don’t feel there is a problem with the security implementation of key management services by these cloud service providers. They have great security teams and I believe they take care in both the implementation of the security systems as well as in the hiring and management of the teams that support the key management systems. And you can’t really argue with the cost model of key management services. Cheap or free is always attractive.

The problem originates in the fact that the cloud service provider creates, manages, and owns the actual encryption keys that protect your data. This means that they are subject to law enforcement warrants and national security letter requirements to surrender your data and encryption keys. And you may not be notified of these actions. This is not an issue just in the United States. Many national governments have various legal rules that require cooperation by cloud service providers. Many cloud companies try to be transparent about these law enforcement activities, but transparency can be blocked in many cases.

Should cloud service providers refuse to obey lawful requests for information about their customers? Of course not. We all live in a nexus of laws and regulations that are largely designed to protect us. If a law enforcement warrant is lawfully obtained a cloud service provider would be acting responsibly by complying with a request for copies of your data and your encryption keys. And they may not be able to inform you of that action.

And there is the problem. You might not know what is happening to your information stored in the cloud.

Any responsible executive team in a business or organization would want to know if there was a potential problem with an employee, group of employees, company policy, or operation in a local, federal or international environment. Executives want to be aware of potential problems and respond to them as quickly as possible. In fact, this is a core governance requirement. And they can’t act quickly and responsibly when they are not aware of a problem. And that’s the rub. If you give your cloud service provider access to your encryption keys you may lose the ability to know when a problem arises.

Is there a solution to this problem?

By deploying a third-party encryption key management solution in the cloud or on-premise in your own data center you retain exclusive ownership to the encryption keys and data they protect. Cloud service providers cannot respond to law enforcement and intelligence service actions because they have no administrative access to the encryption keys. This doesn’t mean that law enforcement and intelligence services won’t be interested in obtaining your information. But it does mean that they will have to notify you of their desire to obtain your data. Of course, as a responsible business you will want to comply with these requests. But you will do so with full knowledge of the activity and will the full advice of your own legal counsel. And the process will probably provide you with some clues as to the reason for the action. That’s something you will really want to know.

Retaining custody of your encryption keys means retaining control of your organization’s governance and risk-management controls. And that’s a good thing.

Knowing is better than not knowing.

Securing Data in the Cloud

 

Topics: Encryption Key Management

Who owns my encryption key in the Amazon AWS cloud?

Posted by Patrick Townsend on May 16, 2017 9:41:44 AM

One of the most frequent questions I receive about encryption in the AWS cloud is “Who owns the encryption keys in the cloud?” and “Does Amazon have access to my keys?” I understand why this is a confusing question. I also understand why the question is important to many Enterprise customers. Cloud service providers don’t like to talk about this very much, so let’s spend some time running this to ground. We’ll start with the question about Amazon’s access to your encryption keys.

How to Meet Best Practices for Protecting Information in AWS by Stephen WynkoopAmazon Web Services provides two encryption key management options:

  • AWS Cloud HSM
  • AWS Key Management Service (KMS)

The answer to the question of key ownership depends on which service you are using. Let’s deal with the easy one first.

The AWS Cloud HSM is a physical hardware security module (HSM) that is dedicated to you. It is physically located in an AWS regional cloud data center, but only you have administrative access to the key server. Amazon is clear on the topic of encryption key ownership with the Cloud HSM service: Only you have access to the keys. Of course, Amazon has physical access to the HSM in their data center, but I think we can trust Amazon’s claim that only you have access to the actual encryption keys in a Cloud HSM server.

Now let’s turn our attention to the AWS Key Management Service, or KMS. This is a multi-tenant service provided by Amazon which is backed by an Amazon hardware security module. That is, Amazon creates a key that is only used by you, but that key is protected (encrypted) by an Amazon managed HSM. When you create a key in KMS it is called a Customer Master Key, or CMK. The CMK is actually a data structure that contains your symmetric key and meta data about the key. The CMK is protected by an Amazon HSM key. So, the answer to the question about who owns your key is straight-forward: You and Amazon share ownership of the encryption key and that ownership is equal. You both can access the raw encryption key.

Recently Amazon introduced a new “Bring Your Own Key” option for the KMS service. Does this change anything about who has access to the key? No, you are bringing your own encryption key and loading it into the AWS KMS service as a part of a CMK, but it is still protected in the KMS service by an Amazon HSM key. This means that you and Amazon share equal ownership of the key and both of you have access to the key. The only difference with Bring Your Own Key is that you retain the actual value of the encryption key outside of the AWS cloud.

So, to summarize: The AWS Cloud HSM service provides dedicated encryption keys that only you have access to. The AWS Key Management Service provides encryption keys and both you and Amazon have access to the key.

So, why is this important? Here are some comments that Enterprise customers have shared with me:

In almost every country both law enforcement and national security agencies have legal means to compel a cloud service provider to surrender data related to cloud customers. Certainly in the US this is the case, and it is true in most other countries. In the US it is additionally true that law enforcement and national security agencies may access this information and prohibit the cloud service provider from notifying you – the customer – that access has been granted. Cloud service providers like Amazon and others naturally abide by the laws of the countries in which they operate. But this means that your encryption keys in AWS KMS can be surrendered without your knowledge. You may not like this aspect of your country’s legal system, but it is a fact of life.

Why is this of concern to Enterprise customers? It is because significant law enforcement or intelligence service activity concerning your employees or customers may take place without your knowledge. If you are an executive in a large Enterprise you really want to know if there are potential problems in your workforce, or significant problems with a customer or service provider. Questions like these might arise:

  • Do I have an employee engaging in illegal activity?
  • Do I have multiple employees colluding together to engage in illegal activity?
  • Is one of my customers engaging in criminal activity that may compromise my business?
  • Are there managers in my organization that are breaking the law?
  • Is there some activity that may significantly damage my business reputation?
  • How can I deal with a problem if I don’t know about it?

When your IT systems are physically located in your data center law enforcement and intelligence agencies have to contact you to get access to data. That is not the case in the cloud – you will be in the dark in many cases.

In my experience Enterprise customers will cooperate with their legal requirement to provide data to law enforcement. This is not a question of cooperating with legal requirements to surrender data in a criminal investigation. But Enterprise customers really want to know when significant legal events take place that affect their organizations.

The critical concern is visibility of law enforcement and intelligence service activity that affects you. For this reason many Enterprise customers will not use the AWS Key Management Service. And because they do not have physical access to the Amazon Cloud HSM devices, they will not use this dedicated encryption key management service either.

I hope this clarifies some of the issues related to the Amazon key management options. Of course, these issues are not exclusive to Amazon, the same issues are relevant to the Microsoft, IBM and Google cloud platforms. There are good alternative options to cloud encryption key management services and we will cover those in a separate blog.

Patrick

How to Meet Best Practices for Protecting Information in AWS by Stephen Wynkoop

Topics: Amazon Web Services (AWS), Encryption Key Management

A Brief History of KMIP

Posted by Ken Mafli on Mar 6, 2017 1:31:39 PM

KMIP Logo.pngKey Management Interoperability Protocol (KMIP) is quickly becoming the industry standard for ensuring your product or software can communicate seamlessly with cryptographic key managers.  In fact, a study by the Ponemon Institute in 2013 reported on the state of encryption trends and found that “more than half of those surveyed said that the KMIP standard was important in cloud encryption compared with 42% last year.”  This is surprising since KMIP v1.0 was first ratified three short years earlier on October 1st, 2010!

How Did it All Start?

eBook: Definitive Guide to Encryption Key ManagementThe first meeting held to start discussing the new set of standards was on April, 24th 2009 in San Francisco in conjunction with the RSA convention that year.  In attendance were representatives from RSA, HP, IBM, Thales, Brocade, and NetApp. Their initial scope was to “develop specifications for the interoperability of key management services with key management clients. The specifications will address anticipated customer requirements for key lifecycle management”

But why was KMIP necessary to begin with?  The short answer: more and more organizations were deploying encryption in multiple environments.  But with encryption comes the need to properly manage the encryption keys. With encryption increasing across multiple enterprise applications it became harder to easily manage the keys from the different enterprise cryptographic applications.  Better standards were needed to create uniform interfaces for the centralized encryption key manager.

Companies soon saw the benefits of adopting KMIP.  Both large and small organizations need their key management to work every time and need it to scale as their organization grows.  And while other work was done to address this issue, like OASIS EKMI, IEEE P1619.3,  and IETF Keyprov KMIP was designed to have a broader scope than it’s predecessors and give more comprehensive standards for the industry.


How Was KMIP Initially Received?

In 2010, KMIP debuted at RSA.  HP, IBM, and others demonstrated that their client programs using the KMIP version 1.0 protocol could “communicate securely with key management servers. The clients and servers [demonstrated] essential use cases such as generating cryptographic keys, locating existing keys, and retrieving, registering, and deleting keys.”

In 2011 at the RSA Conference major players like IBM, RSA, and HP demonstrated KMIP 1.0 compatibility with their client programs.  And again in 2012 and in 2013 even more companies like Thales, NetApp, and Townsend Security demonstrated KMIP compliance.  With all these prominent players becoming KMIP compatible, it was a major signal to the industry that KMIP was rapidly becoming the industry standard for interoperable communications for key managers.

How is KMIP Thought of Now?

Fast forward to 2014.  The The Storage Networking Industry Association (SNIA) announced a testing program for KMIP conformance for its members.  In their words, “By introducing the KMIP Test Program for the industry, we’re helping to encourage not only the adoption of enterprise–class key management, but a means for vendors to test for conformance and provide an assurance of interoperability and a layer of trust to their customers.”

At  OASIS’ Interoperability Showcase at RSA 2016 16 companies, including Townsend Security, demonstrated KMIP compatibility.  And with the likes of VMware, Oracle, Quantum, and many others  demonstrating KMIP compatibility, KMIP has become a dominant standard in key management interoperability.

Final Thoughts

Encryption is your last, best defense for data at rest.  But encryption is only as good as your key management.  If the key is exposed to hackers, the data is lost as well.  This is why key management standards like KMIP have already attracted considerable interest, and will continue to do so.  The ability to have a variety of vendor applications, platforms, and databases all able to communicate with a centralized key manager enhances the data security posture of the enterprise.  And this is what organizations should strive to achieve.

OASIS built the standard to address a broader scope of issues than what older industry standards addressed. But KMIP still is actively being matured by OASIS (we are on version 1.3) and we should expect to see further enhancements and revisions to the standard as well as broader industry adoption.  This should give us confidence that KMIP as a well-accepted, road-tested standard will continue to grow in industry popularity in years to come.

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption Key Management

How Do I Encrypt Data and Manage Encryption Keys Using Java in Amazon Web Services (AWS)?

Posted by Patrick Townsend on Aug 22, 2016 10:51:12 AM

If you are a Java developer you probably know that the Java language has full native support for AES encryption. You don’t need any third-party SDKs or add-ins to Java to use industry-standard, strong encryption. The standard Java APIs are based on industry standards and are very efficient. Don’t hesitate to use that built-in facility. You include it in your Java application like this:

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

Protecting Best Practices for Protecting Information in AWSEncryption key management is another story. To implement good encryption key management you will need to turn to an enterprise key management solution and their Java library to make this happen. Our Alliance Key Manager for AWS solution provides a Java SDK to help you with encryption key use. The Alliance Key Manager Java SDK lets you easily retrieve an encryption key for use in your application, or alternatively to send data to Alliance Key Manager on a secure connection where the encryption or decryption task can be performed directly on the key server. This encryption service is helpful in situations where you don’t want to expose the encryption key in your application or server environment.

Many developers use the Java Keystore (JKS/JCEKS) facility for storing encryption keys. The Java key store is more a key storage facility rather than a key management facility and rarely meets compliance regulations for separating keys from the data they protect, providing for separation of duties, and dual control. If you are currently storing encryption keys in a JKS repository you may want to consider moving them to true key management solution like Alliance Key Manager.

One of the advantages of the Alliance Key Manager SDK is the built-in high availability failover facility. By using the Alliance Key Manager SDK in the event of a network or other failure you automatically fail over to a secondary HA key server in real-time. This means your application keeps running even though a network or system error prevents access to the primary key server.

The Java SDK for Alliance Key Manager includes all of the support needed to make a secure connection to the key server, retrieve an encryption key, access the encryption and decryption services on Alliance Key Manager, and perform other common functions. By using the SDK the Java developer can avoid writing all of the code needed to perform these tasks – the work needed to retrieve an encryption key is reduced to a few lines of code.  We think this is a big bonus for the Java developer and helps make their lives easier. And sample source code will really speed along the process.

Here is an extract of the sample source code showing the retrieval of an encryption key from Alliance Key Manager, an encryption of some plaintext, and the decryption of that ciphertext:

// Note: Full sample source available (this is just an extract)

import javax.crypto.Cipher;

import javax.crypto.spec.IvParameterSpec;

import javax.crypto.spec.SecretKeySpec;


import com.townsendsecurity.akmcore.AkmException;

import com.townsendsecurity.akmcore.AkmUtil;

import com.townsendsecurity.akmcore.AkmRequest;


import com.townsendsecurity.akmkeys.AkmKeyRequest;

import com.townsendsecurity.akmkeys.AkmSymKey;


// The AKM configuration file

String sCfgFile = "/path/jakmcfg.xml"


// Create a key request object initialized from the configuration file

AkmKeyRequest keyRQ = null;

keyRQ = AkmKeyRequest.getInstance(sCfgFile);


// Define the key instance (version) name

String sInstance = "some-name"


// Retrieve the encryption key from Alliance Key Manager

AkmSymKey symkey = null;

symkey = keyRQ.retrieveSymKey(sKey, sInstance);


// Create a context

EncryptDecryptCBC cryptor = new EncryptDecryptCBC(symkey.getKeyBytes());


// Let’s encrypt some plaintext

byte[] ciphertext = null;

ciphertext = cryptor.encryptSymmetric(plaintext.getBytes());


// Let’s decrypt the ciphertext

byte[] plainbuf = null;

plainbuf = cryptor.decryptSymmetric(ciphertext);

There is no charge for the Java SDK and all Alliance Key Manager customers have access to the Java SDK and sample code. AWS customers must register on the Townsend Security web site to get access to the Java code. You can do that here.

Meeting Best Practices for Protecting Information in AWS

Topics: Alliance Key Manager, Amazon Web Services (AWS), Encryption Key Management, Enryption

How Can I Be Sure I Never Lose My Encryption Keys in Amazon Web Services (AWS)?

Posted by Patrick Townsend on Aug 12, 2016 11:00:00 AM

As organizations move to the cloud, the topics of encryption and key management are top concerns.  "How can I be sure that I never lose my encryption keys?" is one that we hear a lot.  With Alliance Key Manager (AKM), Townsend Security's FIPS 140-2 compliant encryption key manager, you never have to worry about that! There are several layers of protection that help put this worry to rest. Let’s take a look at them in order.

Backup and Restore

Protecting Best Practices for Protecting Information in AWSThe first layer of protection is that Alliance Key Manager gives you a complete backup and restore facility -including both a manual and automated facility. At any time you can run the manual backup operation to back up your key database, certificates, configurations and access control definitions. This backup can be sent to your own secure server either in the AWS cloud or in your own data center. You can also create the backup image and download it directly to your own server for safekeeping.

Alliance Key Manager also supports the ability to automatically backup to a secure server at an interval you specify. You can back up your encryption keys daily, weekly, monthly or at an interval you specify. Secure off-line backup is the first layer of protection.

High Availability

Most of our customers in AWS will deploy a second instance of Alliance Key Manager as a high availability failover key server. You can deploy the HA instance of the key server in a different region, or even completely outside of the AWS cloud. Once you deploy the secondary HA instance of the AKM key server you can start mirroring your data keys from the primary production instance of the key server to this secondary HA instance of the key server. Keys and access policies are securely mirrored in real time and the mirror architecture is active-active. This means that if you fail over to the secondary key server, create keys or make changes to key access policies, these will be mirrored back to the production key server in real time. Key mirroring provides a second layer of protection from key loss.

For customers concerned about protection from failures of the AWS cloud platform itself, you can mirror encryption keys to a key server outside of the AWS cloud. That secondary mirror key server can be located in your data center, in another cloud service provider platform, or in a hardware security module (cloud HSM) in a hosting center. Note that there is no limit to the number of backup mirror key servers that you can configure. Alliance Key Manager supports a many-to-many architecture for key mirroring.

Export Encryption Keys

A third layer of protection is provided by the key export facility of Alliance Key Manager. You can securely export individual encryption keys to your own internal systems. The key export facility also provides you with the ability to share an encryption key with another user or organization.

Separation of Duties & Dual Control

Using Separation of Duties and Dual Control can provide a fourth layer of protection for encryption keys. This level of protection is especially helpful for protecting from insider threats. You can create a separate AWS account for use by your security administrators to create and manage encryption keys. These key management administrators would have no access to normal AWS instances where you store sensitive data, and your normal AWS administrators would have no access to the key management account. By activating Dual Control in Alliance Key Manager at least two security administrators need to authenticate to the server to make changes or delete encryption keys.

Stand-alone Instance

Lastly, Alliance Key Manager runs as a stand-alone EC2 instance in the AWS cloud. You are automatically taking advantage of the security, resilience and recoverability provided by Amazon. Always use good AWS account security and management practices to help protect your sensitive data and encryption keys!

It may theoretically be possible to lose an encryption key, but you are going to have to work very hard to do so! Alliance Key Manager takes the fear of key loss out of your encryption strategy in AWS.

You can find more information about Alliance Key Manager for AWS here.

Meeting Best Practices for Protecting Information in AWS

Topics: Amazon Web Services (AWS), Encryption Key Management

Who Has Access to My Encryption Keys in Amazon Web Services (AWS)?

Posted by Patrick Townsend on Aug 5, 2016 9:23:56 AM

One of the most common questions we get here at Townsend Security is something like “Who has access to my encryption keys in AWS?” It is a natural question to ask and it can be hard to determine the answer to this question with many key management solutions - including the key management services provided by Amazon. Let me try to answer this question for our Alliance Key Manager for AWS.

Protecting Best Practices for Protecting Information in AWSAlliance Key Manager for AWS runs as a stand-alone EC2 instance in Amazon Web Services. There is no component of Alliance Key Manager that is shared by other users of AWS, and there is no component of Alliance Key Manager that uses encryption key management services provided by Amazon in AWS. Neither Amazon nor Townsend Security hold any credentials that grant access to the key manager solution, and there are no “backdoors” to the key manager. You, the AWS customer, solely and exclusively manage it.

Encryption keys in Alliance Key Manager are managed by the Alliance Key Manager Administrative Console. This is an application that you install on your PC and which accesses one or more instances of Alliance Key Manager in AWS. While you could install the administrative console in an EC2 instance in AWS, we recommend that you install it on a secure PC outside of AWS. You maintain full control over the application used to manage keys.

The administrative console connects to Alliance Key Manager over a secure TLS session using certificates that are issued by the Alliance Key Manager instance. That is, only administrators using PKI certificates known and authenticated by the specific key manager are allowed to perform management functions.

The use of encryption keys by applications or users inside of AWS or outside of AWS is likewise controlled by secure TLS sessions that are also validated to the specific key manager instance and certificate authority. Just having a valid certificate from Verisign or other certificate authority is not adequate to gain access to encryption keys.

An additional layer of encryption key access control allows you to restrict an encryption key to a user or group as defined on the client-side certificate. This level of key access control leverages to Common Name (CN) and Organizational Unit (OU) of the client-side certificate to control access to a key. If you specify that a key can only be accessed by user “Bill” in the group “Sales”, then Alliance Key Manager will inspect the connecting session to be sure that the certificate Common Name contains the value “Bill” and that the certificate Organizational Unit is “Sales”. Access is denied unless this rule is met.

Lastly, if an unauthorized user gains access to the Alliance Key Manager encryption key database they will not have access to the actual encryption keys. Data encryption keys (DEK) are encrypted by key encryption keys (KEK) which are stored separately. A stolen backup or copied key database file will be insufficient to gain access to the encryption keys.

You should be aware that any cloud service provider has low level access to your virtual machines and storage. That is true of Amazon’s cloud platform as it is with any other cloud platform. And you should also be aware that Amazon and other cloud service providers must obey the laws and regulations of the countries in which they operate. You cannot exclude the possibility that Amazon will provide access to your key management EC2 instance if required to do so under the law. In some countries this means that law enforcement organizations, national security agencies, and other governmental actors may have access to your encryption keys. And, while very unlikely, you cannot exclude the chance that an Amazon employee might make an unauthorized access to the EC2 instance of your key server. If these possibilities make you feel uncomfortable you should consider hosting your key management server outside of AWS. Townsend Security's Alliance Key Manager solution can be hosted in your data center or in a hosting facility that you designate for this and provide keys to your AWS applications.

You can find more information about Alliance Key Manager for AWS here.

Meeting Best Practices for Protecting Information in AWS

 

Topics: Alliance Key Manager, Amazon Web Services (AWS), Encryption Key Management

Key Management: The Hardest Part of Encryption

Posted by Luke Probasco on Jun 3, 2016 7:19:00 AM

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends." 


2016 Encryption Key Management Industry Perspectives and Trends eBookWhile organizations are now committed to implementing encryption, they are still struggling with getting encryption key management right. With all major operating systems, cloud platforms, and virtualization products now supporting encryption, it is relatively easy to make the decision to activate encryption to protect sensitive data. But an encryption strategy is only as good as the method used to protect encryption keys. Most audit failures for customers already using encryption involve the improper storage and protection of encryption keys.

Ignorance and fear are the driving reasons for this core security failure. Many IT professionals are still not versed in best practices for encryption key management, and IT managers fear that the loss of encryption keys or the failure of access to a key manager will render their data unusable. This leads to insecure storage of encryption keys in application code, unprotected files on the data server, and poor protection of locally stored keys.

Most encryption key management solutions have evolved over the last decade to provide unparalleled reliability and redundancy. This has largely removed the risk of key loss in critical business databases and applications. But the concern persists and inhibits the adoption of defensible key management strategies.

Take Aways

  • Protect encryption keys with single-purpose key management security solutions.
  • Never store encryption keys on the same server that houses sensitive data.
  • Only deploy encryption key management solutions that are based on FIPS 140-2 compliant technology.
  • Only deploy encryption key management solutions that implement the KMIP industry standard for interoperability.
  • Avoid cloud service provider key management services where key management and key custody are not fully under your control.

Cloud Migration and Key Management Challenges

Cloud migration continues to a be a high priority for organizations large and small. The benefits for migrating to the cloud are clear. Reduction in cost for computing power and storage, leverage of converged infrastructure, reduction of IT administrative costs, on-demand
scalability, and many other benefits will continue the rapid migration to cloud platforms. As cloud platforms such as Amazon Web Services (AWS), Microsoft Azure, Google App and Compute Engine, and IBM SoftLayer mature we can expect the pace of cloud migration to accelerate.

While cloud service providers are providing some encryption key management capabilities, this area will continue to be a challenge. The question of who has control of the encryption keys (key custody) and the shared resources of multi-tenant cloud service providers will continue to be headaches for organizations migrating to the cloud. The ability to exclusively manage encryption keys and deny access to the cloud service provider or any other third-party will be crucial to a good cloud key management strategy and end-customer trust. The attempt by governments and law enforcement agencies to access encrypted data through access to encryption keys will make this issue far more difficult moving forward.

Unfortunately most cloud service providers have not adopted common industry standards for encryption key management. This results in the inability of customers to easily migrate from one cloud platform to another resulting in cloud service provider lock-in. Given the rapid evolution of cloud computing and the infancy of cloud computing, customers will have to work hard to avoid this lock-in, especially in the area of encryption key management. This is unlikely to change in the near future.

Take Aways

  • Avoid hardware-only encryption key management solutions prior to cloud migration. Make sure your key management vendor has a clear strategy for cloud migration.
  • Ensure that your encryption key management solution runs natively in cloud, virtual and hardware platforms.
  • Ensure that your encryption key management solution provides you with exclusive management of and access to encryption keys. Neither your cloud service provider nor your encryption key management vendor should have administrative or management access to keys. Backdoor access through common keys or key management code is unacceptable.
  • Avoid cloud service provider lock-in to proprietary key management services. The cloud is still in its infancy and retaining your ability to choose and migrate between cloud platforms is important.
Encryption Key Management Trends Perspectives

Topics: Encryption, Encryption Key Management

Key Management Systems Integration & Management Remain a Challenge

Posted by Luke Probasco on Apr 25, 2016 9:47:00 AM

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."


2016 Encryption Key Management Industry Perspectives and Trends eBookEncryption and key management should move from an IT project to an integrated and seamless part of the IT infrastructure. Organizations need to be able to deploy encryption with ready-to-use infrastructure so that encryption ceases to be a barrier. In order to accomplish this encryption and key management solutions must be embedded in the IT infrastructure and enabled by policy. Key management solutions must implement the automation infrastructure that enables this type of deployment. All aspects of the provisioning of an encryption key server from network configuration, system logging, user administration, generation and distribution of credentials, key mirroring, backup and restore, and encryption key management must become API driven through standard web services.

Unfortunately, standards bodies and vendors have been slow to address this critical aspect of key management. While there is some movement to de ne some aspects of encryption key management through web services or add-on solutions like Chef, the net- work and services aspects of key managers have not been adequately addressed. This will continue to make it difficult to move key management into the realm of seamless and invisible critical infrastructure.

Take Aways

  • Ask your key management vendor how they implement APIs for server configuration, deployment and management.
  • Understand the key management vendor’s road- map and plans for key management automation.
  • Ask the key management vendor for examples of customers using their Web services features.
  • Understand any vendor licensing restrictions for installing management utilities.

There is No Single Source for Best of Breed Security

Understandably, customers long for a single vendor who can solve all of their security needs. Currently the process of deploying best of breed security involves working with multiple vendors whose products do not interoperate. It means spending a lot of IT resources managing a large variety of vendor products and services. While there are a handful of larger vendors attempting to provide a complete set of products, their marketing language does not match reality and there is no indication that it will for some time to come. 

Looking ahead, organizations should expect to work with a number of security vendors in order to deploy best of breed security for their sensitive data. It is unlikely that this will change in the near future. Smart organizations will identify best of breed applications that are easy to use, and make the resource investments needed to acquire and manage these solutions.

Take Aways

  • Always try to deploy the best of breed security solutions and understand that this means dealing with multiple vendors.
  • Prioritize your security needs according to risk, and tackle the highest priority items first.
  • Understand and empower your IT organizations to acquire and deploy the best solutions. It is always more cost effective to prevent a problem than remediate it after the fact.
Encryption Key Management Trends Perspectives

Topics: Encryption, Encryption Key Management

Encryption and Key Management for MySQL Developers

Posted by Patrick Townsend on Mar 11, 2016 1:08:00 PM

Excerpt from the White Paper "MySQL & VMware - Encryption and Key Management for Developers."


Whether you develop mostly on Linux or Windows, you can achieve a compliant implementation of encryption with the MySQL database and variations of MySQL like MariaDB. This blog looks at some key decisions you will need to make about the encryption approach, and how we help our customers get encryption right.

Using the MySQL Built-in Encryption Primitives

MySQL and VMware EncryptionMySQL supports a number of encryption and encoding operations directly from the SQL language. When encrypting a column you can use the ENCRYPT function, AES_ ENCRYPT function, the older DES_ENCRYPT function, or the encoding or compression algorithms. If you want to use this approach to encryption and decryption, I would recommend that you use AES_ENCRYPT and AES_DECRYPT. For this, primitive MySQL uses the industry standard 128-bit AES algorithm, which is considered strong encryption and meets compliance regulations.

While the DES_ENCRYPT support is still a part of recognized industry standards, you will have a performance benefit when using the stronger 128-bit AES support and are not likely to run into the problem of a future deprecation of the Triple DES algorithm used by the MySQL DES_ENCRYPT method.

Here is an example of a MySQL insert statement that uses AES_ENCRYPT with a hex representation of the encryption key:


INSERT INTO t
VALUES (1,AES_ENCRYPT(‘text’,UNHEX(‘F3229
A0B371ED2D9441B830D21A390C3’)));


Of course, hard-coding the encryption key is poor security practice.

Encryption at the Application Layer

Encrypting and decrypting directly in your SQL statements is not always possible or optimal. Don’t worry, you can also implement encryption in your application code if that makes more sense. Our Alliance Key Manager includes several language-specific software libraries for developers. For example, if you are a Java developer you can install and use our Java .jar files for full support for encryption key retrieval and on-device encryption. If you are a Windows C# developer you can add our Windows .NET Client to your Visual Studio project and have full support for key management. Both Java and C# have great support for encryption - you won’t need support from third parties for AES encryption - but you will need to implement encryption key management the right way.

What are some reasons you might want to do encryption at the application layer?

  • Minimize the changes to SQL for different databases.
  • Take advantage of the stronger 256-bit AES encryption method.
  • Use an AES mode of encryption that uses an Initialization Vector such as Cipher Block Chaining (CBC) mode.
  • Embed information in the encrypted field about the key used, the version of the key, and the IV.
  • Create custom logic for encrypting larger blobs in the database.

Whatever the reason or combination of reasons, implementing encryption at the application layer is an easy choice to make with the Alliance Key Manager language SDKs.

Where are the Encryption Keys?

The single biggest challenge a developer will face when deploying encryption for MySQL is how to properly manage encryption keys. Not getting it right leaves the organization open to security failures, audit failures, and litigation. Here are some ways NOT TO STORE encryption keys:

  • As a part of the SQL statement (see above).
  • In the application code.
  • In a file on the same server.
  • In a file on a separate server.
  • In a separate table in the MySQL database.

All of these approaches have been the cause of security audit failures for our customers. Don’t let this happen to you.

Summary

Developers are the tip-of-the-spear when it comes to protecting their organizations from data breaches. When they are aware of the critical success factors for an encryption strategy they can dramatically improve the overall security posture of their companies.

At Townsend Security we provide developers with the tools they need to be successful and to get encryption right. Our key management solution, Alliance Key Manager, runs in all of the platform environments that developers need. The applications and software development kits that come with Alliance Key Manager run in VMware, the cloud and everywhere else you might deploy the MySQL database.

MySQL and VMware Encryption for Developers

Topics: Encryption Key Management, MySQL

 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all