Townsend Security Data Privacy Blog

Customers who need to encrypt data in Microsoft SQL Server databases know that they must protect the encryption key with appropriate controls to meet compliance regulations and to achieve safe harbor in the event of a data breach. Townsend Security's Alliance Key Manager solution provides the Extensible Key Management (EKM) software to make proper key management a breeze. Called Key Connection for SQL Server, this EKM Provider software is installed on the server hosting the SQL Server database and it talks seamlessly to one or more Alliance Key Manager servers running in a separate server instance. Customers get proper key management that meets compliance regulations such as PCI-DSS in an easy-to-deploy solution.

Performance is always a consideration when it comes to enabling encryption, so customers naturally ask us about key caching. Does Key Connection for SQL Server cache the encryption keys to enable better performance?

The short answer is Yes, it does.

How it does key caching depends on whether you use Transparent Data Encryption (TDE) or Cell Level Encryption (CLE). Let’s drill into each of these cases.

Transparent Data Encryption (TDE)
The implementation of TDE by Microsoft involves encrypting the entire table space and the database logs. It is the easiest type of encryption to deploy as it requires no changes to the actual application that uses the SQL Server database. You can implement TDE encryption by installing the Key Connection For SQL Server software and issuing four commands through the SQL Server management console. Restart logging to insure that it is encrypted and you are done.

So with TDE, how are keys managed? The TDE architecture involves SQL Server generating a symmetric key (usually a 256-bit AES key) and then asking Alliance Key Manager to encrypt it with an RSA key. This encrypted symmetric key is then stored on the server that hosts the SQL Server database. When you start SQL Server (or restart it, as the case may be) the SQL Server instance asks Alliance Key Manager to use RSA decryption to decrypt the symmetric key. Once that is complete the SQL Server instance has the key it needs and no longer needs to communicate with Alliance Key Manager. There is no need for key caching and the key will be decrypted the next time that SQL Server starts.

Cell Level Encryption (CLE)
The implementation of CLE by Microsoft SQL Server is quite different than for TDE. The EKM Provider software is still responsible for managing the symmetric encryption key, but it is accomplished in a different way. You must make small changes to your application SQL statements to request encryption and decryption of the cell contents. When CLE is activated the Key Connection for SQL Server software is called for each column and row that needs to be encrypted or decrypted. This means a lot more calls to the EKM Provider software and this is where key caching is very important.

The Key Connection for SQL Server software in this case does cache the symmetric encryption key (usually a 256-bit AES key) in order to improve performance. The key is cached using an equally strong RSA key to prevent key capture by malware. When SQL Server calls the Townsend Security EKM provider the software retrieves the key from the key server and will cache it locally for a 24 hour period. For the next 24 hours all subsequent requests for encryption or decryption are satisfied locally without the need to retrieve the key again. After 24 hours, the key is discarded and a fresh key is retrieved from the key server. If the connection to the key server is not available error messages are written to the Windows Event Log, but encryption processes will continue using the locally cached key, once the 24 hour period expires, network connectivity will need to be restored for a fresh key to be retrieved and operations restored. With key caching database encryption, performance is much better.

The architecture of the Alliance Key Manager EKM provider implements other core features needed to help protect your database. These include:

• Separation of Duties between Key Administrators and Database Administrators
• Dual Control for key management operations
• Built-in logging to the Windows Event Manager
• High availability failover to one or more secondary key servers
• Automatic recovery of failed EKM Provider services
• Security of credentials through Windows Certificate Store
• Easy key rollover using native SQL Server commands

Key caching is important for performance, but this is just one part of an overall key management strategy for Microsoft SQL Server.

As customers move to virtualized and cloud environments, Alliance Key Manager and the Key Connection for SQL Server EKM Provider software will move with you. In addition to traditional IT data centers, all Townsend Security encryption and key management solutions run in VMware (vSphere, ESXi, etc.), Microsoft Azure, Amazon Web Services, and in any cloud service provider vCloud environment.

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).

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

Periodically changing the encryption key for protected data is a security best practice and a part of many compliance regulations like the PCI Data Security Standard (PCI DSS).

This encryption key change is sometimes referred to as “Key rotation” or “Key rollover” and these terms mean the same thing. When performing a key change operation you generate a new encryption key, decrypt the protected data with the old encryption key, and then encrypt the data with the new encryption key. After the defined cryptoperiod for the key you archive or escrow the key and it is no longer be used.

Townsend Security's Alliance Key Manager helps you with key rollover by allowing you to specify a cryptoperiod for any symmetric key, and then automatically generating a new key for you at the end of the cryptoperiod. In Alliance Key Manager the cryptoperiod is specified as the number of days from the key creation date. At midnight on the last day of the cryptoperiod, a new version of the key is created and it becomes the default encryption key. The old key is retained and is fully active so that data can still be decrypted with that key.

Like most enterprise key management solutions Alliance Key Manager provides a user-friendly name for an encryption key, and a version identifier. The key name is a normal character name and might be something like Credit card, Human resources, and so forth. The name is meant to provide an easy way for a user or security administrator to locate and use a key.

In Alliance Key Manager the version of the key is called the “Key instance” and is a unique character string. When managing keys the key instance name might look something like this: TGV0IGZyZWVkb20gcmluZw==. Key instance names are always unique and a key may have any number of key instances.

The most recent version of the key is the default, or current, instance of the key. When you retrieve a key in your application, you can leave the key version blank and you will automatically get the most current version of the key. When Alliance Key Manager performs key rollover the new version of the key becomes the current version of the key.

Alliance Key Manager supports three rollover settings for each symmetric key:

• Automatic key rollover at the interval you specify
• Manual rollover that you initiate through the security console
• No key rollover

Whatever key rollover strategy you decide to implement, Alliance Key Manager will provide the tools you need. You can fully automate key rollover, roll keys manually at your convenience, or dis-allow key rollover so that new versions of the key are never generated.

This is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP.  Nick is an IT Security Architect at Coalfire Labs.

For those protecting the front lines of our credit card data in merchant environments, few other things keep those in charge (as well as IT administrators) awake at night than the threat of a breach. Questions often arise along the lines of: Will my company be able to survive? What can I do to protect myself? How do I prevent my company from being next? And how do I limit any losses should it happen to us?

One of the key components to the protection of cardholder data at any merchant location is the use of strong cryptography along with just-as-strong cryptographic key management procedures. PCI DSS Requirement 3 outlines what the PCI council believes to be the baseline for strong cryptographic key management procedures and is a key element of any PCI DSS audit.

Successful key management with a strong cryptographic algorithm is the best place to start with getting encryption of your cardholder data correctly protected while it is contained within your environment. But key management can be confusing, difficult and downright impossible depending on the size of your environment. Figuring out if your keys are strong enough, or if they are rotated often enough or if they are protected from would-be hackers. On top of that, figure in the ever-increasing complexity of today’s business systems to include cloud, virtual computing, data mining, and others, the ability to quickly and easy manage encryption keys across several platforms and environments becomes key for PCI DSS compliance.

This is where a tool like Townsend Security's Alliance Key Manager (AKM) comes in to play. Available as a physical hardware security module (HSM), a cloud HSM, a virtual appliance (VMware) or in the cloud (AWS, Azure), Alliance Key Manager can help merchants meet PCI DSS requirements for encryption key management by creating, managing, and distributing AES 128-bit, 192-bit or 256-bit encryption keys all without the risks involved with clear-text key administration.

As a QSA, it is certainly encouraging to see a complete encryption solution that removes some of the worries of traditional manual clear-text key management procedures. AKM can relieve pressure to meet portions of PCI DSS Requirement 3 such as the need to render Personal Account Numbers (PAN) unreadable using strong cryptography with associated key-management processes and procedures (PCI DSS 3.4). It directly meets PCI DSS Requirement 3.5.2 to store keys within a secure cryptographic devices such as a HSM along with additional encryption requirements such as 3.6.2 – Secure Key Distribution, and 3.6.3 – Secure Key Storage. In addition, AKM can make PCI DSS Requirements 3.6.6 for Split Knowledge and Dual Control not applicable as there are no manual key-management operations involved. This (virtual) device is a useful cost-effective tool to help meet your PCI DSS compliance.

For more information on using AKM to meet PCI DSS compliance specifically within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI DSS 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.

In this age of “Bring Your Own”, we see the acronyms BYOD (device), BYOE (encryption), and BYOK (key) showing up all over the blog-o-sphere. BYOK is a cloud computing security model that allows cloud service customers to use the provided server-side encryption software and (bring) manage their own encryption keys.

The idea of encryption (cryptography) is almost as old as the concept of written language: if a message might fall into enemy hands, then it is important to ensure that they will not be able to read it. Most typically, encryption relies on some sort of "key" to unlock and make sense of the message it contains, and that transfers the problem of security to a new level – now the message is secure, the focus shifts to protecting the key. In the case of access to cloud services, if we are encrypting data because we are worried about its security in an unknown cloud, then why would we trust the same cloud to hold the keys without using a key management solution?

BYOK can help an organization that wishes to take advantage of cloud services to address both regulatory compliance and data privacy concerns in a third-party multi-tenant environment. This approach allows a customer to use the encryption technology that best suits the customer's needs, including the cloud provider's underlying IT infrastructure. For example, Amazon’s Simple Storage Service (S3) is about protecting data-at-rest using server-side encryption with customer-provided encryption keys (SSE-C) or “BYOK”. With the encryption key you provide as part of your data request, Amazon S3 then manages the encryption (as it writes to disks) and decryption (when you access your data). You don't need to maintain any code to perform data encryption and decryption in S3. The only thing you do is manage the encryption keys you provide to the Amazon Simple Storage Service. When you upload an object, Amazon S3 uses the encryption key you provide to apply AES-256 encryption to your data and then removes the encryption key from memory. When you retrieve data, you must provide the same encryption key as part of your data request. Amazon S3 first verifies that the encryption key you provided matches, and then decrypts the data before returning it to you.

Important to Note: Amazon S3 does not store the encryption key you provide. Instead, they store a randomly salted HMAC value of the encryption key in order to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.

Any time a company decides it wants to host its applications in the cloud, or use a SaaS application where the company’s data will be stored in the cloud, their IT security professionals have to ask a series of questions.

• Can we encrypt the data? If so, who will have access to the keys?
• How will we perform key rotation and manage the lifecycle of the encryption keys?
• Is the cloud vendor using a proprietary encryption technology that prevents us from moving our data to another vendor?
• If we use 10 SaaS applications, will we have to administrate 10 different key management solutions?

These questions are tough enough to answer when the data and encryption technologies are in a company’s own data center where it has complete control over everything. In many cases, if encryption is provided, the cloud provider holds or has access to the keys, which creates another set of problems for the end user. For one thing, a third-party having access to data in the clear is a violation of regulations such as PCI-DSS, HIPAA, GLBA and others. Also, customers have yet to establish trust in cloud platforms or SaaS providers to protect their data. There have been many high profile data breaches that make end-users nervous. Customers also fear the U.S. government will subpoena access to their data without their knowledge or permission. For companies outside the U.S. that choose to use a U.S.-hosted cloud or app, there are data privacy and residency concerns. Instinctively it feels a lot more secure to manage your own key and use BYOK instead of leaving it to the cloud provider.

A few things have become crystal clear:

1. You need to know where your sensitive information is. Period.
2. You need to know who has access to it. Not who you think has access to it, but who really has access to it.
3. Wherever you put your sensitive information, you need to protect it. The most critical thing you need to do is to apply a strong defense in depth approach to data security, including the use of encryption and access controls.
4. You need to be able to document, through audit logs and reports, who has actually accessed your information. This is true (and important) for sensitive data, as well as for compliance-regulated data.
5. If you think that having your cloud service provider encrypt your data provides adequate security for your information, you probably need to rethink this.

It all boils down to this: When encrypted data is stored or processed in the cloud, the data and the keys must be kept separate and only the end-user should control the encryption keys.

Cloud storage options bring new economies and business efficiencies, but security can’t be ignored, and it can’t be simply outsourced to some other party. We believe that it is fundamental to good security to control all access to your data, including managing your own encryption keys. Managing encryption keys may sound daunting, but it doesn’t need to be. Our technology makes data security and encryption key management simple and straightforward. Our key management solution addresses all of the issues described above and can protect your data everywhere you have it stored.

Encryption & Key Management… why that ampersand is so important!

We frequently talk about a variety of different data security measures and the difficulty of making information truly secure in a multi-tenant environment. What steps are we taking to protect the most valuable assets we have as companies, such as our customer’s Personally Identifiable Information (PII)? Are we starting with the most critical steps in the process and then building out from there?  Let’s make sure we have the basics covered!

Encryption is the first step to keeping information secure from anyone who accesses it maliciously, it is also a clear compliance requirement and critical part of protecting data in any environment. Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael) which is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms. Make sure your security partner will supply you with all of the sample code, binary libraries, applications, key retrieval and other tools you need to implement encryption and key management fast and easily. Whether your data resides in the cloud, in a virtual environment, or in your own data center; always make sure you are using the right type of encryption to protect it.

The second step to the security solution is Encryption Key Management. While encryption is critical to protecting data, it is only half of the equation. Most regulations require that encryption keys must be stored and managed away from the data they protect because storing encryption keys with the data they protect, or using non-standard methods of key storage, will not protect you in the event of a data breach. When encrypting information in your applications and databases, it is crucial to protect encryption keys from loss and securely managed from key creation, management, distribution, and archival or destruction (the full key lifecycle). In the past, key management used to be a complex and difficult task that required hardware and a team of security specialists to implement. Our key manager is available as a ready-to-use, easy-to-deploy solution that is compliant with the NIST FIPS 140-2 standard in a variety of instances:

In the Cloud - If you're running on Microsoft Azure, 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.

VMware - Businesses are able move their VMware infrastructure beyond traditional data centers and into the cloud with VMware’s vCloud.  By using the same FIPS 140-2 compliant software found in physical appliances, enterprises can provably meet compliance requirements with a VMware based encryption key manager running in the cloud.

A 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.

A 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 RAID (Redundant Array of Independent Disks) disc drives, dual power supplies, dual network interfaces, and is deployed in your IT data center. Cloud applications can connect to a remote HSM over a secure, encrypted connection.

Do you have the basics covered? If you are unsure about the status of your defense-in-depth strategy to data security, contact one of the experts on the Townsend Security team. We have a variety of resources to help you answer your most pressing questions and a variety of solutions to make sure you are protecting your data the best way possible. At Townsend Security we also take 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 application or connection 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 and simplified deployments. We also provide ready-made client-side applications, encryption libraries, source code samples, as well as SDKs for developers who need them.

Easier Encryption and Key Management for SQL Server Standard & Web Editions

Your IT environment is ever changing. As technologies evolve, you constantly have to upgrade systems and migrate to new platforms to accommodate these changes. This often results in complex IT environments that are comprised of multiple platforms and operating systems, and data located in disparate locations. Protecting sensitive data in a multi-platform environment that’s made up of both old and new technologies can be one of the most frustrating aspects of data security.

One of Townsend Security’s core missions is to help customers protect sensitive data, regardless of where that data resides, in a cohesive way. One area where we’ve seen the need to improve upon this is around encrypting data in Standard versions of Microsoft SQL Server. Because Microsoft does not provide transparent data encryption (TDE) capability on SQL Server Standard and Web editions, Microsoft customers using these older editions struggle with implementing easy and fast transparent encryption.

In order to simplify the encryption process for Standard and Web Edition users, we have partnered with NetLib, a database encryption solution provider that supports easy and automatic folder, file, and application encryption in Windows as well as database and column level encryption for all Microsoft SQL Server editions. NetLib Encryptionizer easily protects data in SQL Server (2000-2014), Standard, Web, Workgroup and Express Editions. NetLib provides column level encryption as well using triggers and views without the need to write SQL statements or any other development.  

NetLib’s customers choose NetLib Encryptionizer for their FIPS 140-2 compliant encryption solution, for which they require FIPS 140-2 compliant encryption key management as well. As a critical step in our partnership, Townsend Security built Key Connection for Encryptionizer, a no-cost plug-in module that allows Encryptionizer customers to easily secure encryption keys using Townsend Security’s Alliance Key Manager.  

System audits and logging are critical to detecting and alerting you to malicious activity in your systems. Key Connection for Encryptionizer allows users to fully audit the encryption and key management process. Encryptionizer audit logging of user-file interaction as well as audit logging of the key life cycle in Alliance Key Manager provides a comprehensive logging service. Additionally, encrypting data on SQL Server Standard and Web editions typically involves some level of development. With NetLib Encryptionizer, users can encrypt data using a simple point-and-click configuration.

Townsend Security is proud to partner with NetLib to provide an easier method to encrypting data in Microsoft SQL Server Standard and Web editions. To learn more about managing encryption keys for data encryption in complex environments, download the white paper, Key Management in the Multi-Platform Environment.