Townsend Security Data Privacy Blog

MongoDB and Encryption Key Management for Compliance

Posted by Patrick Townsend on May 9, 2016 1:00:00 AM

MongoDB: Encryption Best Practices 

As the importance of encryption increases across the regulatory spectrum, it is heartening to see database vendors implementing encryption and encryption key management that meet security best practices. MongoDB Enterprise is one of the most popular modern databases and has given its customers the ability to quickly and effectively implement encryption and good key management at the level of the database itself. This means that MongoDB Enterprise customers can transparently implement encryption directly in the database without deploying third party file or volume based encryption products to accomplish this task. MongoDB customers enjoy rapid deployment of encryption, a unified management interface to the database, high performance encryption, and integrated encryption key management based on the industry standard Key Management Interoperability Protocol (KMIP).

Securing Data in MongoDB podcast By basing key management on the OASIS KMIP standard MongoDB is providing real benefits to their customers. These include:

  • Rapid implementation of key management with no need for developer resources.
  • No requirement for server-side software libraries, updates, and patching.
  • Secure encryption key retrieval services based on TLS.
  • Vendor neutrality for encryption key management services.
  • Vendor portability and avoidance of vendor lock-in.
  • Seamless migration from one key management solution to another.

MongoDB Enterprise is a case-study in the benefits of using open standards for encryption and key management. MongoDB’s customers can choose the key management solution that makes the most sense for them, and having choices reduces the cost of encryption key management.

MongoDB: Encryption Key Management Made Easy

Townsend Security's Alliance Key Manager solution works out of the box with MongoDB Enterprise to help customers meet compliance regulations which require encryption of sensitive data. It takes just a few minutes to deploy Alliance Key Manager and to configure MongoDB for key management. On first boot, Alliance Key Manager creates a set of strong encryption keys including a 256-bit AES key that can be used with MongoDB, and it creates a set of PKI certificates used for TLS authentication. The PKI certificates are copied to the MongoDB server to secure the connection to the key manager. A quick command or two from the MongoDB command line console and, Voila! Your MongoDB encryption key is now fully protected by a key encryption key on Alliance Key Manager. You have an encrypted MongoDB database and a highly redundant and recoverable encryption key management infrastructure. From the technical team at MongoDB:

“The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a file system perspective, and data only exists in an unencrypted state in memory and during transmission.”

After installing the key manager certificates on the server hosting the MongoDB database, here is an example of the command to enable encryption:

mongod --enableEncryption --kmipServerName akmmongo --kmipServerCAFile /etc/mongodb-kmip/AKMRootCACertificate.pem --kmipClientCertificateFile /etc/mongodb-kmip/AKMClientCertificate.pem --dbpath /var/lib/mongodb/

It’s that simple.

With Alliance Key Manager you have your choice of network-attached hardware security modules (HSMs), VMware virtual machines, and dedicated cloud instances in Microsoft Azure and Amazon Web Services. The key manager works the same way in all environments so you can even mix and match hardware, VMs, and cloud instances to achieve the level of security that is right for your organization. All instances of Alliance Key Manager are dedicated to you with no access by cloud service providers or third parties. Key custody remains exclusively under your control.

Many MongoDB customers deploy the database in VMware environments. Alliance Key Manager also runs in VMware as a virtual machine. You can deploy the key manager in a VMware security group and protect one or more instances of MongoDB across the entire VMware environment. If you are running on a VMware vCloud platform the same support is provided for key management.

For compliance, Alliance Key Manager is validated for PCI-DSS compliance in the VMware platform. This will help you achieve PCI-DSS compliance for your MongoDB database and applications. The PCI-DSS statement of compliance is here.

MongoDB is rapidly becoming the high performance, scalable, NoSQL database of choice for organizations large and small. As such it becomes a part of the critical infrastructure for business applications. Alliance Key Manager also implements high availability features such as automatic, real-time encryption key mirroring, and backup. For customers deploying the hardware version of Alliance Key Manager, there is redundancy at the hardware level with dual hot-swappable RAID disks, redundant power supplies, and redundant network interfaces. All of these features mean that your key management infrastructure will be resilient and reliable.

Alliance Key Manager will help you will meet common compliance regulations such as PCI-DSS, HIPAA, FFIEC, FISMA, the EU General Data Protection Regulation (GDPR), and other compliance schemes. Alliance Key Manager regardless of platform is based on the same FIPS 140-2 compliant software found in our enterprise level HSM. With no restrictions or license costs for client-side connections, you can protect as many MongoDB databases as you like with one Alliance Key Manager.

The product team at MongoDB did a great job of implementing encryption and key management for their customers. They deserve to be applauded for basing their solution on industry standards like KMIP. This will lower the bar for getting encryption right in the database. With Alliance Key Manager, getting encryption right means rapid deployment, conservation of developer resources, lower administration costs, and provable compliance.

A match made in techno-heaven.

Patrick

Securing Data in MongoDB

Topics: Alliance Key Manager, Compliance, MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

EU Data Privacy, Safe Harbour and Encryption

Posted by Patrick Townsend on Oct 7, 2015 12:19:00 PM

In a ruling that shocked Internet service providers and businesses in the US and abroad, the European Court of Justice ruled this week that current data Safe Harbour rules may not be adequate to protect the privacy of EU citizens and that individual countries may make their own rules about data privacy. Anyone who has lived in Europe and knows the historical context of governmental tracking and abuse of individual rights will certainly not be surprised by this ruling.

But why is this such a big deal?

Download the EU Data Privacy White Paper Have you noticed how good Google, Facebook, Microsoft, Amazon, Yahoo and others are at showing you advertising that reflects your interests? They are really good at this because they are the ultimate data aggregators. They use their vast network of global systems to bring data about you together and then perform sophisticated analytics. This means that most Internet service providers are moving data across country boundaries into the United States or areas controlled by the US where that data is subject to government inspection.

Beyond the obvious advertising aspects of Internet services, many backup and archival systems are built on Internet-based storage services. This means sensitive backup data moves over the Internet and may move to servers or networks outside of the host country. Internet service providers have been working hard to make their systems resilient and this often means integrating across borders.

In fairness, it is not just the US government that snoops on individual activity - many governments around the world do the same thing. And that is the concern of the European courts.

If data can’t leave a country, that will have a major impact on Internet service providers. And, of course, that will have a major impact on the small and large businesses that use these services. It’s potentially a very large problem!

In a Computer Weekly interview with Andy Hardy, Managing Director of Code42, he noted the importance of encryption and key management in meeting the new requirements. Andy said:

“It need not be the end of business as we know it in terms of data handling. What businesses need to do now is safeguard data,” he said.

According to Hardy, businesses must ensure they can keep company and customer data private, even when backed up into a public cloud.

“The right technology will ensure data it is encrypted before it leaves the endpoint device, so that it cannot be decrypted in the cloud and hence remains private. The best technologies will ensure that encryption keys are kept by our customers on-premise, so only they can decrypt the data and that no one else can access it unless with prior direct request. This is the only way to ensure privacy in the public cloud post-Safe Harbour,” he said.

I think Andy has this exactly right. When encryption is done right it makes the data unintelligible to anyone without the encryption keys. Using a key management solution that is resident in the EU, which is dedicated to the data holder, and which does not allow third party administrative access will be crucial to meeting the new EU privacy laws.

That’s exactly what we do with our encryption solutions that integrate with Alliance Key Manager and we are already helping EU customers protect their data with strong encryption. EU customers can locate Alliance Key Manager within their own data center, or in a country-specific hosting center, or even in a cloud service provider platform where there are adequate guarantees around in-country hosting.

EU Data Privacy Protections and Encryption

Topics: Compliance, EU Data Privacy Protection

Understanding Encryption and Key Management for VMware

Posted by Michelle Larson on Apr 3, 2015 11:33:00 AM

How to implement solutions that are based on compliance standards and meet security best practices.

As more and more Enterprise businesses move into virtual and cloud environments, they face challenges and security issues in these multi-tenancy situations. VMware customers benefit from the many operational and cost efficiencies provided by VMware virtualization technologies both in traditional IT infrastructure and in cloud environments. VMware Resource Kit for Encryption and Key Management As VMware customers deploy data encryption solutions as a part of their defense-in-depth strategy, the need for compliant encryption key management can present barriers to a good encryption implementation. It is possible to deploy a proper encryption key management solution within the VMware infrastructure without the need for traditional hardware security modules (HSMs) when this approach is appropriate to the security needs of the organization.

Here is some high level guidance on how to deploy and protect a solid encryption and key management solution for VMware within your virtual or cloud environment. While these recommendations are general in nature (actual VMware deployments will use different VMware applications and architectures to meet specific user, application, and security needs) they can provide a good roadmap.

Seven General VMware Recommendations

1. Identify and Document Trusted and Un-Trusted Applications

Properly identifying application groups based on the level of trust is critical for a secure implementation of virtualized applications and encryption key management services. Create and isolate a management cluster for your core VMware applications such as vSphere, vShield, etc. Identify application groups and their associated level of trust, and isolate applications into appropriate workgroups. Avoid mixing trusted and untrusted applications in a workgroup.

You should consider creating a security workgroup to contain your third party security applications such as encryption key management, authentication services, active directory, system logging, and other applications whose primary function is to assist in securing your applications in your VMware environment.

In preparation for properly securing these environments, create an inventory of all Virtual Machines managed in each workgroup. For each workgroup and virtual machine, identify the security controls that will be required for each one (network segmentation, storage segmentation, system logging, active monitoring, etc.). VMware flow tools can assist with this documentation.

2. Restrict Physical Access

Fundamental to all IT security implementations is proper security of the physical environment. This means proper physical security controls and physical monitoring of the data center as well as good auditing and procedural controls. These physical controls should also apply to access of VMware management and security applications. You can look to the PCI Data Security Standards and guidance for information on appropriate physical controls. You can also refer to standard security guidance in SOC 2 and SOC 3 assessments for information on physical controls. When deploying on a cloud platform it is always a good idea to ask the Cloud Security Provider (CSP) for a copy of the PCI letter of attestation, or an SOC 2 / SOC 3 report.

3. Isolate Security Functions

Because security applications are often a target of cyber-criminals, you should isolate them into their own security workgroup and implement the highest level of VMware security. Only trusted VMware administrators should have access rights to the encryption key management solution, system logs, and audit reports. Be sure to actively monitor access to and use of all encryption key management, key retrieval, and encryption services.

4. Change VMware Default Passwords

Review all VMware applications used to secure and manage your VMware environment and change the default passwords as recommended by VMware. The failure to change default passwords is one of the most common causes of security breaches.

5. Implement Network Segmentation

Network segmentation is easy to accomplish with VMware network management and security applications and you should implement network segmentation to isolate applications that process sensitive information from applications that do not require as high a level of trust. Additionally, you should provide network segmentation for all third party security applications such as your encryption and key management solution. Network segmentation should include all high availability and business recovery infrastructure. Do not rely on virtual network segmentation alone; use firewalls that are capable of properly securing virtual networks.

6. Implement Defense in Depth

The VMware management and security applications provide for a high level of security and monitoring. They also provide hooks and integration with third party security applications that provide system log collection, active monitoring, intrusion detection, etc. Encryption is a critical part of a defense-in-depth strategy, and protecting encryption keys is the most important part of an encryption strategy. Regardless of the operating systems in your application Virtual Machines, your solution should provide encryption key management, key retrieval, and encryption services for your business applications and databases running in your VMware infrastructure.

7. Monitor VMware Administrative Activity

Use an appropriate SIEM solution to collect VMware application and ESXi hypervisor system logs and perform active monitoring. The log collection and SIEM active monitoring solutions should be isolated into a security workgroup that contains other third party security applications such as Townsend Security’s Alliance Key Manager.

For additional information on securing Alliance Key Manager for VMware, our encryption key management solution, request the VMware Resource Kit containing the Guidance Document and other valuable resources:

Resource Kit: Encryption and Key Management in VMware

As solutions and implementations vary a great deal, always consult with a security specialist and compliance auditor for specific guidelines for your industry and environment! Just contact us to get started!

Topics: Compliance, Data Security, Encryption Key Management, Defense-in-Depth, VMware, Resource Kit

Basics of the EU Data Protection Working Party

Posted by Michelle Larson on Mar 26, 2015 1:19:00 PM

Article 29 Security Guidelines on Data Protection



The Article 29 Working Party is composed of representatives of the national data protection authorities (DPA), the European Data Protection Supervisor (EDPS), and the European Commission. It is a very important platform for cooperation, and its main tasks are to:

  1. Provide expert advice from the national level to the European Commission on data protection matters.
  2. Promote the uniform application of Directive 95/46 in all Member States of the EU, as well as in Norway, Liechtenstein and Iceland.
  3. Advise the Commission on any European Community law (so called first pillar), that affects the right to protection of personal data.


Download the EU Data Privacy White Paper

Under EU law, personal data can only be gathered legally under strict conditions, for a legitimate purpose. Furthermore, persons or organisations which collect and manage personal information must protect it from misuse and must respect certain rights of the data owners which are guaranteed by EU law.

Every day within the EU, businesses, public authorities and individuals transfer vast amounts of personal data across borders. Conflicting data protection rules in different countries would disrupt international exchanges. Individuals might also be unwilling to transfer personal data abroad if they were uncertain about the level of protection in other countries.

Therefore, common EU rules have been established to ensure personal data enjoys a high standard of protection everywhere in the EU. The EU's Data Protection Directive also foresees specific rules for the transfer of personal data outside the EU to ensure the best possible protection of sensitive data when it is exported abroad.

In order to help address these EU objectives, Patrick Townsend, Founder and CEO of Townsend Security recommends the following data protection best practices:

  • Encrypt Data at Rest
    Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups.
  • Use Industry Standard Encryption
    Advanced Encryption Standard (AES, also known as Rijndael) is recognized world-wide as the leading standard for data encryption.
  • Use Strong Encryption Keys
    Always use cryptographically secure 128-bit or 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys.
  • Protect Encryption Keys from Loss
    Encryption keys must be stored away from the data they protect.  Keys must be securely managed and should be compliant with the industry standards such as NIST FIPS 140-2 which is recognized and accepted worldwide.
  • Change Encryption Keys Regularly
    Change your encryption keys on a quarterly or semi-annual basis. Using one encryption key for a long period of time can expose you to a breach notification for historical data.
  • Use Strong, Industry Standard Hash Algorithms
    Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.
  • Use Keys or Salt with Your Hashes
    You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For more detailed information on these recommendations, download the white paper on the "EU Data Privacy Protections and Encryption":

Click to Request the EU Data Privacy White Paper

Topics: Compliance, Data Security, EU Data Privacy Protection, Encryption Key Management, Defense-in-Depth, White Paper

PCI Compliance and the Assessment Process

Posted by Michelle Larson on Dec 4, 2014 1:30:00 PM

Understanding PCI Merchant Levels and how an assessment can help your business

If your business takes credit cards for payment, then you are subject to the Payment Card Industry – Data Security Standards (PCI-DSS).

Companies of all sizes must comply with PCI DSS to ensure that their customers' data is protected during the processing and transmission of credit or debit card transactions and securely stored within any internal databases. PCI categorizes businesses into different classification levels based on the number of transactions and dollar amounts they processes each year.

Download Whitepaper on PCI Data Security

Level 1 – All merchants processing more than 6 million card transactions annually

Level 2 – All merchants processing between 1 million and 6 million card transactions annually

Level 3 – All merchants processing between 20,000 and 1 million card-not-present only transactions annually

Level 4 – All other merchants

Level 1 companies are most likely well versed in the annual PCI audit process as they have a certified onsite audit annually with a Qualified Security Assessor (QSA). Level 2, 3, 4 merchants are not required to hire an onsite QSA, but can have a certified Internal Security Assessor (ISA) do the PCI self assessment annually. However, a small business preparing a self-assessment to participate in their first PCI review may find it a little daunting. If you're feeling that the PCI assessment process is overwhelming and complicated, understanding this process may be the first step toward putting your mind at ease. If you are a Level 1 merchant, the PCI assessment is a process carried out by a QSA to establish whether or not a business is compliant with security standards relating to the processing of transactions made via a credit or debit card (payment card). PCI compliance assesses your business point of sale system, payment applications, and all interconnecting systems with these goals in mind: (1) to examine your system, (2) to identify vulnerabilities, and (3) to prevent data from being compromised.

It’s not a matter of “IF”, but “WHEN”

If you have already suffered a data breach, working closely to review your assessment and put data security best practices into place will provide you with a roadmap to help avoid future losses. If you have not yet been breached, undergoing an assessment and reviewing your risk tolerance can still be stressful. Understanding the process may alleviate some of that stress and help you to maximize your use of the information in the PCI DSS assessment report

How can a PCI audit help my business?

PCI compliance auditing helps businesses to ensure they are providing the most secure environment for their customers to process payments and ensures that transactions are less likely to result in a compromise in the customers' data.

Ensuring that you meet PCI compliance and have a solid infrastructure for managing data security will increase customer confidence in your business and ensure that you're not exposed to security breaches that could have been avoided. 

To learn more about meeting PCI compliance requirements, download the whitepaper Meet the Challenges of PCI Compliance and find the answers to the following questions (and more):

  • What will my auditor look for?

  • How can I ensure my customers' data is secure?
  • What is the difference between tokenization and encryption?
  • What is encryption key management and why are auditors looking at this?

  download the Whitepaper: Meet the Challenges of PCI Compliance

 


Topics: Compliance, Data Security, PCI DSS, Best Practices, Encryption Key Management, White Paper

Why is Encryption & Key Management So Important?

Posted by Michelle Larson on Nov 20, 2014 12:50:00 PM

Shayna at SecureWorld Seattle 2014

More Questions from the Tradeshow Floor (Part 2)

In our last blog we touched on a few of the questions asked at events we attended in November.  There were so many great conversations that I’ve decided to share a few more!Session on encryption and key management

With the various platforms that I can deploy an encryption key manager in, how do I know which one is right for me?

There are several factors that will come in to play when deciding where you deploy your key management:

  • Compliance regulations that you need to meet can be a factor in whether you deploy an Hardware Security Module (HSM) or a cloud HSM or a virtualized instance. If you are working with an auditor or going through a QSA audit, you'll want to have a conversation with them to understand their expectation from a compliance point of view around where you deploy your encryption key manager.
  • Risk tolerance will also come into play. You may have a security group within your organization with strong feelings about how to deploy encryption key management and how to mitigate risk. If you have large amounts of sensitive data to protect you might decide to deploy an HSM in your secure data center. If you're dealing with a very small amount of data and you do not process credit cards or personally identifiable information, your risk assessment may indicate a cloud deployment.
  • Budget is certainly always a factor to consider. It is important to consider the cost benefits of security however, we all understand that leaving our data in the clear is no longer an option. It is a matter of understanding your industry regulations and risk assessment, then deciding what encryption and key management to deploy.

While they are generally the most secure solution, Hardware Security Modules (HSMs) can be more expensive than a virtual environment, dedicated cloud instance, or virtual private cloud. Once you look at all the factors that affect your company, we will be there with the right solution that will work for your needs.

Tell me more about all these different options you have for the Alliance Key Management Solution… are they all going to help me meet compliance requirements?

There are still our original hardware security modules (HSMs) and now there are new options for deployment of cloud-based HSMs, virtual appliances (VMware), and true cloud instances of encryption and key management in AWS and Microsoft Azure.

  • Hardware Security Module (HSM) is a physical appliance or security device that is protected and tamper evident. Built for high resiliency and redundancy it has hot swappable rated disc drives, dual power supplies, dual network interfaces, and is deployed in your IT data center.
  • Cloud HSM is a physical appliance hosted in a secure cloud with real-time encryption key and access policy mirroring.  Dedicated HSMs are hosted in geographically dispersed data centers under an ITIL-based control environment and are independently validated for compliance against PCI DSS and SOC frameworks. No access is available to the cloud vendor or any unauthorized user.
  • Virtual Appliances are the exact same key management solution - the same binary software that runs inside the hardware HSM - available as a VMware instance.
  • In the Cloud - If you're running on Microsoft Windows Azure, vCloud, or in Amazon Web Services (AWS),the encryption key manager can run as a true cloud instance in a standard cloud or deploy in a virtual private cloud for added data protection for sensitive applications.

Because encryption and key management is so important, we offer all of the options listed above as NIST and FIPS 140-2 compliant solutions.

How is Alliance Key Manager Priced?

We have a wide set of options for our customers, and are dedicated to helping find affordable solutions. We have perpetual license or subscription options for classic HSMs, Cloud HSM, and virtualized environments. Our cloud offerings are true usage-based subscriptions, so if you're used to deploying in Amazon Web Services or Windows Azure, our encryption & key management solutions will fit that same strategy for pricing.  

We really believe that the encryption should go everywhere you need it to go! Your key management should work across a wide set of application environments, and it must be affordable, so that we can all get where we need to be in terms of protecting sensitive data. Regardless of where your data is or what platform you are using, there's a key management solution that can work for you!

How can Encryption and Key Management improve my bottom line?

Whether you choose a designated hardware security module (HSM), something designed specifically for virtualized environments (VMware), or data storage in the cloud, encryption and key management solutions can help you:

  • Gain competitive advantage and build loyalty by protecting your customers data against access by unauthorized users
  • Reduce hardware costs by leveraging virtual environments in the cloud
  • Significantly improve your data security strategy while satisfying data compliance and privacy requirements

Overall, data encryption offers many benefits and provides solid protection against potential threats or theft. In addition to the many benefits, encryption is also efficient, easy to use, and affordable!

What sets Townsend Security apart from other key management vendors?

We want to protect data and make sure encryption is available everywhere you need it, so at Townsend Security we have a very different philosophy and approach:

  • We think that when you buy an encryption key manager, you should be able to easily deploy the solution, get all your encryption projects done properly, and have very affordable and predictable costs.
  • We understand that we live in a world where budget matters to our customers, so we do not charge client-side fees.  
  • We know that IT resources are limited and have done a huge amount of work to make our solutions easy with out-of-the-box integrations, simplified deployments, and also provide along with our solution ready-made client-side applications, encryption libraries, source code samples, as well as SDKs for developers who need them to get their projects done very quickly.

Want to learn more about how to properly secure your data and protect your business against a data breach? Download our eBook “The Encryption Guide”:

The Encryption Guide eBook


Topics: Alliance Key Manager, Compliance, Data Security, Encryption, eBook, Encryption Key Management, Trade Shows

What You Need To Know About Encryption & EU Data Privacy Protections!

Posted by Michelle Larson on Sep 16, 2014 2:31:00 PM

Here is a sneak peek at the introduction for the latest regulatory guidance white paper from Townsend Security. For detailed information, download the entire document: Download the EU Data Privacy White Paper

On March 25, 2014, the Article 29 Data Protection Working Party of the European Union issued new guidance on data breach notification and the use of data protection technologies such as encryption and encryption key management. Extending beyond just Internet Service Providers, the new regulations cover all organizations that process, store, or transmit private information of EU citizens. Along with these new regulations, there are substantial financial penalties for failing to protect sensitive information. These penalties can reach into the 10’s of millions of Euros depending on the organization’s size and amount of data compromised.

The European Union does not mandate that all organizations immediately encrypt sensitive data, but the only exclusion for subject data breach notification and financial penalties will be for those organizations who use encryption and other security methods to protect the data. Applying these security methods after a breach will not remove the notification requirements and penalties.

EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. The following guidelines will help meet these new EU objectives:

Encrypt Data at Rest

Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups. Personal data should always be encrypted as it flows through your systems, and when you transmit it to outside organizations.

Use Industry Standard Encryption

Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael). AES is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms.

Use Strong Encryption Keys

Always use cryptographically secure 128-bit and 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys. Encryption keys based on passwords will never meet minimum standards for strong encryption keys. Keys should be generated using a cryptographically secure random bit generator (CS-RBG) validated to international standards.

Protect Encryption Keys from Loss

Encryption keys must be stored away from the data they protect and must be securely managed. Manual procedures cannot accomplish the goal of proper encryption key management. Use a professional encryption key management solution to protect keys and provide different keys for different data protection needs. Key management solutions should implement key creation, management, and distribution and be compliant with the NIST FIPS 140-2 standard recognized and accepted worldwide.

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. A good key management solution can automatically change encryption keys at an interval you define.

Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.

Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For details on the EU Data Protection Directive...


Click to Request the EU Data Privacy White Paper

Topics: Alliance Key Manager, Compliance, Encryption, Alliance AES/400, EU Data Privacy Protection, Encryption Key Management, White Paper, Salting, AES Encryption, Hashing

What are the Differences Between DES and AES Encryption?

Posted by Michelle Larson on Sep 4, 2014 3:46:00 PM
Updated 4-1-2020 - to include illustrative graphics

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.


eBook The Encryption Guide Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

  • The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
  • In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
  • The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

How-Long-to-Brute-Force-DES-encryption

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

  DES AES
Developed 1977 2000
Key Length 56 bits 128, 192, or 256 bits
Cipher Type Symmetric block cipher Symmetric block cipher
Block Size 64 bits 128 bits
Security Proven inadequate Considered secure

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?

how-long-to-crack-aes-encryption


The Encryption Guide eBook

Topics: Compliance, Data Security, Encryption, NIST, Defense-in-Depth, White Paper, AES, AES Encryption

GLBA/FFIEC Compliance = Encryption & Key Management

Posted by Michelle Larson on Jul 3, 2014 11:03:00 AM

Compliance regulations and security best practices require the encryption of sensitive financial data and the protection of encryption keys with proper key management.  

Financial Industry

The financial industry includes banks, credit unions, and other financial organizations, including venture capital firms, private equity firms, investment banks, global investment firms, bank holding companies, mutual funds, exchanges, brokerages, and bank technology service providers, among others. In order to meet compliance regulations, information security programs must be in place to ensure customer information is kept confidential and secure, protected against potential threats or hazards to personal information (cyber-attack, identity theft) and protected against unauthorized access to or use of a customer's personal information. For business owners, database administrators, or developers who need to protect their customers’ sensitive data with encryption; storing the encryption keys within the same database puts that information at risk for a breach.

If you fall within the financial sector, the following will apply:

The Gramm-Leach-Bliley Act (GLBA) - 15 USC 6801 - of 1999 first established a requirement to protect consumer financial information.

TITLE 15 , CHAPTER 94 , SUBCHAPTER I , Sec. 6801. US CODE COLLECTION
Sec. 6801. - Protection of nonpublic personal information

(a) Privacy obligation policy
It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal information.

(b) Financial institutions safeguards
In furtherance of the policy in subsection (a) of this section, each agency or authority described in section 6805(a) of this title shall establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards.

The Federal Financial Institutions Examination Council (FFIEC) supports the GLBA mission by providing extensive, evolving guidelines for compliance and evaluating financial institutions. Financial services regulations on information security, initiated by the GLBA, require financial institutions in the United States to create an information security program to:

  • Ensure the security and confidentiality of customer information
  • Protect against any anticipated threats or hazards to the security or integrity of such information
  • Protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to any customer

Federal Reserve Board Regulations - 12 CFR - CHAPTER II - PART 208 - Appendix D-2
-- Interagency Guidelines Establishing Standards For Safeguarding Customer Information--

… III. Development and Implementation of Information Security Program

… C. Manage and Control Risk

Each bank shall:

… c. Encryption of electronic customer information, including while in transit or in storage on networks or systems to which unauthorized individuals may have access.

Enforcement of these financial industry compliance guidelines fall to five agencies: the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Office of Thrift Supervision (OTS). In collaboration, these agencies have developed a series of handbooks that provide guidance, address significant technology changes and incorporate a risk-based approach for IT practices in the financial industry. The "Information Security Booklet" is one of several that comprise the FFIEC Information Technology Examination Handbooks, and references encryption in detail.

Summary: Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

  • Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
  • Effective key management practices
  • Robust reliability
  • Appropriate protection of the encrypted communications endpoints

To meet the growing need for NIST validated and FIPS 140-2 compliant encryption and key management, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now when nonpublic personal and financial information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed.

To learn more, download the ebook: Encryption Key Management Simplified

Encryption Key Management Simplified eBook


Additional Resources:

Federal Financial Institutions Examination Council (FFIEC)

FFIEC Information Technology Examination Handbooks

Gramm-Leach-Bliley Act (GLBA)

Federal Reserve System (FRB)

Federal Deposit Insurance Corporation (FDIC)

National Credit Union Administration (NCUA)

Office of the Comptroller of the Currency (OCC)

Office of Thrift Supervision (OTS)

Topics: Compliance, Data Security, Encryption, eBook, Encryption Key Management, GLBA/FFIEC

PCI DSS Compliance = Encryption & Key Management

Posted by Michelle Larson on Jul 1, 2014 2:13:00 PM

Many compliance regulations and security best practices require the encryption of sensitive data and the protection of encryption keys with proper key management.

Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Anyone who needs to protect sensitive data in their database, needs to know that storing the encryption keys within the same location puts data at risk for a breach.  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.


PCI Compliance Regulations require encryption and key management

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement.

Let’s take a brief look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

Requirement 8: Identify and authenticate access to system components

Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data

Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel


Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website (http://www.pcisecuritystandards.org) contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations.

* Requirement 3 addresses the need for encryption and key management, stating:

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”


The PCI Security Standards Council also issues their Cloud Computing Guidelines (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf) and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.


Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected properly with encryption and key management. To meet the growing need for NIST validated and FIPS 140-2 compliant solutions, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now sensitive information can easily be encrypted and the encryption keys properly managed. 

For more information on encryption, download the latest eBook, The Encryption Guide:

The Encryption Guide eBook

Topics: Compliance, Encryption, eBook, PCI DSS, Encryption Key Management