+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

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 Encryption Keys 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 Encryption Keys 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 Encryption Keys 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

A Data-centric Approach to Securing Sensitive Data

Posted by Michelle Larson on Feb 25, 2016 1:11:00 PM

Data-centric security means planning for and implementing encryption and the proper management of encryption keys regardless of the environment.Request the Podcast: Compliance for Coders

All data security plans should constantly evolve to reflect changes in business and compliance regulations, as well as policy and infrastructure changes. Because of this evolution, developers are often called upon to modify existing applications, and to implement new or better security solutions. They also are often required to add new security applications in order to meet data protection best practices or prepare for an audit to meet compliance requirements (PCI DSS, HIPAA, FFIEC, etc.).  

What do developers need to know about coding for compliance?

From the ground up, regardless of the platform or language you use, it is the data security mindset that is critical. Developers need to be aware of protecting sensitive data when writing code because ever-evolving compliance requirements call for that disposition. There should be an emphasis to meet industry compliance standards from the beginning design stages. Code needs to be built with those data protection requirements in mind so that is doesn’t have to be reengineered. Projects can sink or fail due to inadequate data security measures, which can put a whole organization at risk.

Whether you are working in hardware, virtual, or cloud environments, understanding and identifying where sensitive data will reside is very important from day one. There needs to be an understanding of the criminal mindsets that will be trying to breach the systems you create, proper preparation for security audits, and a full knowledge of the compliance guidance available to meet industry standards. Developers should also develop for every possible platform/application that the project might be deployed on. As applications move more to multi-tenant cloud environments, you want to make sure you are not locked into or out of a particular platform. You want your code to be compatible from day one with hardware, VMware virtual environments, and cloud platforms. As more organizations move away from using only hardware, VMware technology is at the center of a revolution around virtual and cloud environments. VMware (the company) has done a great job with providing educational materials, helping developers program in a compliance fashion, and producing reference architecture for PCI compliance.

As developers know, their customers want “out of the box” third-party solutions that already meet required security validations. A few of the fundamental basics to keep in mind when developing for data security compliance:

    • Use encryption standards such as AES encryption for data-at-rest.
    • Use proper Encryption Key storage and management tools
    • Do not burn the keys in code
    • Do not store keys on the same server as the protected data
    • Plan for a compliance audit from the beginning stages

It is also important to look for solution providers that will talk with you before just giving you an instant trial download, it is a good idea to make sure their solution is a technical fit, and not a waste of your time. This is something we do here at Townsend Security with all of our products. We offer a 30-day full version trial of all our software so that you can do a full proof-of-concept and test in your environment. We also feel it is important to supply client-side applications, SDK’s and modules that fit naturally into the platforms and languages that match your development environment. I encourage you to take a little time to listen to this podcast and hear from Patrick Townsend, the Founder & CEO of Townsend Security, on his perspective for developers.

Request the Podcast: Compliance for Coders

Topics: Data Security, Developer Program, Encryption Key Management, Defense-in-Depth, Podcast, Key Life Cycle

To Key or Not to Key: That is the Question

Posted by Luke Probasco on Jan 8, 2016 8:26:00 AM

"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."


What Data Needs To Be Encrypted In Drupal?To keep something safe, you protect it under lock and key, right? Same is true in Drupal and WordPress. Except in these CMSs, that key is unfortunately often hidden under the “Welcome” mat called your database. Not always a very secure place for such important items. So, the question is, what can you do to keep the key safe?

Let’s back up a few steps. Why are there keys and where are they in the first place? 

Private API Keys

Private API keys are actually used frequently within a CMS by services like Authorize.net, PayPal, MailChimp, etc., and stored in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Let’s take MailChimp, for example:  If your MailChimp API key becomes compromised, hackers could send out emails as if they appeared from you, leaving customers surprised to learn that you just got into selling Viagra.

Encryption Keys

In Drupal, for example, there are several modules (EncryptField EncryptionEncrypted Files, etc.) that allow you to encrypt various types of data. This is a very necessary step to keeping your data secure, however what happens to the key to unlock that data? Typically, developers will store their encryption keys locally in either a file protected on the server, in the database, or in Drupal’s settings file. Not very secure places. Further, for companies who fall under data security compliance requirements like HIPAA, FISMA, or PCI DSS, key management requirements are pretty clearly spelled out, and these default methods don’t even come close to being sufficient. Essentially, the compliance requirements all say the same thing: encryption keys should never reside in the same environment or server as the encrypted data. This is a technical way of saying, don’t leave your key under the doormat a hacker walks in over.

Unfortunately in WordPress, there are isolated solutions, but no plugin that provides and manages the encryption process. The team working on the Drupal encryption modules are also working to bring the same functionality to WordPress.

Now that we have established storing sensitive keys within the CMS is not secure, what should we do with them?

Key Management

Keys need to be stored outside of the CMS and developers need to consider how they’ll manage all of these keys. Most encryption modules are designed to create a new key each time the encrypted data is accessed and re-encrypted. As you can imagine, versions of keys add up quickly and managing them is quite a task—not something that you’d want to do manually (luckily your server can’t put a sticky note of keys on its hard-drive).

There are solutions and services designed specifically for key management that can run on a wide variety of platforms ranging from in the cloud, to VMware, to a physical hardware security module (HSM). These solutions can safeguard your API keys, as well as manage encryption keys through the entire lifecycle—from creation to destruction.  Additionally, an external key manager will allow for:

  • Key naming and versioning

  • Key change and rotation

  • Secure key retrieval

  • Key mirroring

  • Key import and export

  • Password and passphrase protection

  • User and group control for key access

Modules and Plugins for Key Management

Luckily, for Drupal users, there is a super easy way to integrate external key management (and follow security best practices). This can happen by way of the “Key” module. Key acts as a central routing API for keys and is easily extended to integrate with your key management vendor of choice.

These modules act as the bridge between the various encryption/API modules and an external key manager. They give site administrators the ability to define how keys are stored, which provides an increased level of security and allows sites to meet compliance requirements and security best practices. With these modules installed, users no longer need to settle for storing their keys in insecure places.

While there currently isn’t a Key equivalent for WordPress, efforts are being made to remedy this.  By early 2016, we can expect to see great progress in the way of managing encryption and API keys in via a plugin similar to that in the Drupal environment.  For now, WordPress developers need to rely on an  external service such asLockr to secure these keys.

Who Holds the Keys to Your Kingdom?

There are three important questions that need to be asked when considering your key management strategy:

  1. Do I want to manage the keys myself or use a service?

  2. Do I need to meet any compliance requirements?  

  3. What is my budget?

Your budget and needs can play a large part in determining which route you take. With a low entry price point, a multi-tenant managed key service (where your keys are stored alongside other companies’ keys on the same key manager) is a great option. These services typically operate in the cloud and allow businesses to remove their keys from under the “Welcome” mat and store them in a more secure environment. As businesses or security needs grow, managed key services can easily scale and migrate users to a dedicated, FIPS 140-2 compliant key manager that can help them meet compliance (PCI DSS, FISMA, etc.).

For users who feel more comfortable with a hands-on approach—or don’t trust anyone but themselves with their keys)—a dedicated and self-managed option may be right for them. Dedicated key managers are available virtually (AWS, Azure, VMware) or physically as a Cloud HSM or HSM, and have a wide variety of licensing options.

To Key or Not to Key?

By now the choice should be fairly obvious. Protecting keys is an important aspect of  a strong security posture. As the headlines show, data breaches are a reality—regardless of the size of your business. They can happen as a result of a hacker or disgruntled employee.  Properly protecting API and encryption keys is a very easy way to manage the risk and severity of a data breach.

Townsend Security’s dedicated Alliance Key Manager is in use by over 3,000 customers worldwide and is the only dedicated key manager with Drupal integrations. Cellar Door Media also recently launched Lockr, a managed key service for Drupal and WordPress that’s free during development, and once deployed to a site, pricing starts at $30 per month. Lockr also offers managed dedicated key service for enterprise customers.

What Data Needs Encrypted In Drupal?

Topics: Encryption Key Management, Drupal

Looking Back on 2015 Data Breaches

Posted by Michelle Larson on Jan 5, 2016 8:08:00 AM

Data Breach Statistic for 20152015 was a year of large and sometimes very controversial data breaches across a broad industry spectrum.  The Identity Theft Resource Center 2015 Breach List contains 780 breaches and 177,866,236 exposed records. Here are just a few that everyone should be aware of:

HEALTHCARE

Anthem

    • 78.8 million highly sensitive patient records
    • 8.8 to 18.8 million non-patient records
    • Names, birth dates, Social Security numbers, addresses, employment information, and income data

Premera

    • Over 11 million subscribers
    • Names, birth dates, Social Security numbers, member identification numbers, and bank account information.

Excellus

    • 10 million members
    • Names, birth dates, Social Security numbers, member identification numbers, financial account information, and claims information

ENTERTAINMENT

Avid Life Media (ALM), the parent company of Ashley Madison

    • 37 million user accounts
    • Email addresses, first and last names, and phone numbers.

VTech

    • 6.4 million children accounts
    • 4.9 million customer (parent) accounts
    • Photos, names, passwords, IP addresses, download history, and children’s gender and birth dates.

Hello Kitty (SanrioTown)

    • 3.3 million customers, including children
    • Full names, encoded by decipherable birth dates, email addresses, and encrypted passwords, along with password reset questions and answers.

TECHNOLOGY

T-Mobile via Experian

    • 15 million records
    • Names, birth dates, addresses and social security numbers and/or an alternative form of ID, such as drivers’ license numbers. (This was an unusual hack because the company itself (in this case T-mobile) didn’t have a data breach rather Experian (a credit reporting company) had a data breach which leaked T-mobile’s consumers’ data)

TalkTalk

    • 3 breaches affecting up to 4 million user records
    • Names, addresses, dates of birth, phone numbers, email addresses, TalkTalk account details and payment card information

Comcast

    • Over 200,000 users
    • Login credentials were sold on the dark web

GOVERNMENT

Office of Personnel Management (OPM)

    • Over 4 million personnel files
    • Over 21 million federal employees and contractors
    • Social Security numbers, security clearance information, fingerprints, and personal details that could leave federal personnel vulnerable to blackmail.

Internal Revenue Service (IRS)

    • Over 100,000 taxpayers
    • Online transcripts and significant personal information was accessed as a result of access to previously stolen identity information.

Wrapping up the year; on December 20th, 191 million registered U.S. voter records were exposed online. The database that was discovered contained more than the voter’s name, date of birth, gender, and address; which on their own is a good amount of personally identifiable information (PII). It also include the voter’s ethnicity, party affiliation, e-mail address, phone number, state voter ID, and whether he/she is on the “Do Not Call” list.

As we head into 2016, we will be focused on prevention and how we can best provide information and solutions to protect your sensitive & valuable data.

Let us know how we can help you!

The Encryption Guide eBook

Topics: Data Security, Encryption, eBook, Encryption Key Management, Data Breach


Subscribe to Email Updates

Posts by Topic

see all