+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

Ken Mafli

Recent Posts

vSphere Encryption—Creating a Unified Encryption Strategy (Part 1)

Posted by Ken Mafli on Oct 22, 2019 6:00:00 AM

What is VMware’s vSphere Encryption?

VMware’s vSphere encryption, first introduced in vSphere 6.5, enables the encryption of virtual machines (VMs) and vSAN. vSphere’s encryption protects your existing VMs, new VMs, vSAN clusters, as well as associated files. It is relatively easy to set up and with the use of a compliant key management server—secure.

 

(Part one of this series deals with VM encryption. Part two will cover vSAN encryption)

A Unified Way to Encrypt VMs

VMware’s vSphere encryption

 

“Dance like nobody’s watching. Encrypt like everyone is.”
~Werner Vogels, CTO at Amazon.com

Data is a bedrock asset for today’s enterprise business. Its value is too great to ignore. Data security, then, is mission critical for those looking to maintain brand integrity, intellectual property confidentiality, and customer trust.

VMware vSphere 6.5 gave its users powerful data security tools; among them AES-NI encryption. The reason this is great news: instead of an ad-hoc approach to encrypting sensitive data where individual sources of encryption are found for each type of database or application, you can now encrypt directly in VMware’s hypervisor creating a unified source for encrypting and managing that encryption. And through their KMIP interface, managing your encryption keys is pretty painless. But more on that later.

vSphere encryption, then, allows the enterprise business to uniformly manage their encryption for both VMs and vSAN and ensure that all sensitive data within VMware is secured. This enables companies to create an encryption strategy for their sensitive data. Let’s look at some of the main advantages, specifically VM encryption, that vSphere encryption provides.

 

Expert Weigh-in:
The huge benefit of vSphere Encryption is the fact that data is encrypted when it leaves its source. This results in data traveling encrypted to its destination, allowing for the highest level of security, all while maintaining simplicity in terms of management and configuration.
~Duncan Epping, Chief Technologist HCI, VMware

 

Expert Weigh-in:
A major advantage of VM Encryption is that it is Guest OS agnostic. Whether the virtual machine is Windows, Linux or any of the other operating systems supported in vSphere, the encryption is the same. There’s no change to the guest OS and no “in guest” monitoring or configuration. Additionally, reporting on which virtual machines are encrypted or not is just one line of PowerCLI!
~Mike Foley, Staff Technical Marketing Architect - vSphere Security

 

The Advantages of Using VM Encryption

Advantages of VMware’s vSphere encryption

 

With VMware vSphere 6.5 and up, you are able to encrypt individual VMs. The main difference between VMware encryption and other encryption methods is ease

vSphere Encryption Key Management Webinarof management. As VMware puts it, because “VMs are treated as objects that can have a policy applied to them, there is no need to manage them individually.”

Here are some of the advantages that this brings:

  • Encryption is configured and managed at the hypervisor level, not within an individual VM.
    • vSphere encryption is agnostic in regards to what is stored within the VM.
    • There are not multiple encryption products for each guest OS, database, or application.
  • Encryption is policy based. Applying it, then, can be done to as many or few VMs that you want.
  • You can bring your prefered key manager to manage your encryption keys. Since vSphere encryption is KMIP 1.1 compatible, you are free to use a FIPS 140-2 compliant encryption key manager, like Alliance Key Manager.

Expert Weigh-in:
One thing few people think about with encryption is disaster recovery. Because of the reliance on an external KMS, you can place replicating Key Managers in various locations. vCenter will see them as a “KMS Cluster”. Should your primary site go down and you need to recover encrypted VM’s it’s as simple as connecting a new vCenter to the KMS cluster and adding the VMs to the inventory. The impact of IT operations is minimal. 
~Mike Foley, Staff Technical Marketing Architect - vSphere Security

 

Expert Weigh-in:
Policy Based encryption and Managed Encryption keys means the difference between an organization protecting their information and exposing their information. Removing the chance of end-users to not-encrypt information means the Business can have assurances they can take to the bank, which is essential in a world of compliance, GDPR, and not to mention security risks or exposure.
~Christopher Kusek, vExpert and Tech Evangelist

 

Now that we know some of the advantages of using VM encryption, let’s looks what is (and is not) encrypted. Why? VMware did a great job making sure all sensitive information can be secured. The list below will go to illustrate that.

 

What Is/Is Not Encrypted

What can be encrypted in vSphere

 

According to VMware, here are the items that can be encrypted (and those that can’t) with vSphere’s VM encryption:

What can be encrypted:

  • VM files
    • Note: Most VM files can be encrypted. This set of files can include the NVRAM, VSWP, and VMSN files. If you use the vSphere Web Client to create an encrypted VM, all virtual disks will be encrypted as well.
  • Virtual disk files
    • Note: Data in an encrypted VMDK file is never written in plaintext to storage or a physical disk, and is never transmitted in plaintext. The VMDK descriptor file, however, is not encrypted and contains a key ID for the key encryption key (KEK) as well as the encrypted data encryption keys (DEKs).
  • Host core dump files
    • Note: When you enable encryption mode on an ESXi host the core dump is always encrypted.

What is not encrypted (and why):

  • Log files
    • Why: these are not encrypted because they contain no sensitive data.
  • VM configuration files
    • Why: the VM configuration information, stored in the VMX and VMSD files, contains no sensitive data.
  • Virtual disk descriptor files
    • Why: the descriptor file is omitted from encryption/decryption functions to support disk management without a need for an encryption key.

 

Expert Weigh-in:
I like vSphere encryption because there’s nothing in the guest OS or at the user-level that might go wrong. vSphere encryption encrypts what needs to be encrypted - your company’s data - that’s stored inside the VM disk.
~David Davis, vExpert and vSphere video training author at Pluralsight.com

 

How it Works

Now that we know some of the advantages of VM encryption and what can and cannot be encrypted; here is the last reason to use vSphere to create a unified encryption strategy—it is easy to set up. Here is a quick video showing how easy it is.

 

Here are those steps for those that would like to just read it:

  • First, install and configure your KMIP compliant key management server, such as our Alliance Key Manager, and register it to the vSphere KMS Cluster.
  • Next, you must set up the key management server (KMS) cluster.
    • When you add a KMS cluster, vCenter will prompt you to make it the default. vCenter will provision the encryption keys from the cluster you designate as the default.
  • Then, when encrypting, the ESXi host generates internal 256-bit (XTS-AES-256) DEKs to encrypt the VMs, files, and disks.
  • The vCenter Server then requests a key from Alliance Key Manager. This key is used as the KEK.
  • ESXi then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk along with the KEK ID.
  • The KEK is safely stored in Alliance Key Manager. ESXi never stores the KEK on disk. Instead, vCenter Server stores the KEK ID for future reference. This way, your encrypted data stays safe even if you lose a backup or a hacker accesses your VMware environment.

 

Expert Weigh-in:
vSphere encryption makes securing your data easier than I think most of us thought possible. With vSphere encryption all you do is right-click on a VM and apply the encryption storage policy. Boom! Encryption is done!
~David Davis, vExpert and vSphere video training author at Pluralsight.com

 

It really is that easy. Not only can govern your encryption at the hypervisor layer, deploy standards based AES encryption on a per VM basis (allowing you to secure only those workloads that require it), but you can do so quickly. It is a great encryption option for any business.

Final Thoughts

VMware vSphere VM encryption creates a unified strategy for protecting your sensitive data within vSphere by using the hypervisor to perform the encryption. This means that you do not need to first consider what is in the VM (guest OS, specific databases, etc.) in order to encrypt it. According to VMware, this yields the following benefits:

  • No modification to OSs within VMs
  • No changes needed to existing applications
  • No specialized hardware or infrastructure required
  • Policy-based enforcement that is supported by vSphere

All this and more means that it is easier than ever to secure your company’s sensitive data. Once you have configured your vSphere vCenter Server to enable encryption, simply choose which VMs you want to encrypt and your data is secured. It’s that easy.

According to RiskBased Security, for the first half of 2019, over 3,800 breaches were reported, breaching over 4.1 billion records. When you compare that to the first half of 2018, “the number of reported breaches was up 54% and the number of exposed records was up 52%.” With the pace of breaches only accelerating, the time to create a unified encryption strategy for your sensitive data is now.

 

New call-to-action

Topics: VMware, vSphere, vSphere Encryption

2019 Encryption Key Management Survey Results

Posted by Ken Mafli on Sep 11, 2019 9:56:26 AM

Recently, we here at Townsend Security had the opportunity to poll the fans of our Newsletter to see how folks are doing with encryption and key management for their data-at-rest. We conduct this survey, and surveys like it, so that the larger InfoSec community can get a snapshot of how businesses, in general, are doing in securing their sensitive data. Below are a few key findings, hope you enjoy!

 

Overall Results

Using Encryption

First, the good news: 73% of respondents report that they encrypt their sensitive data while at-rest. This makes sense as all the respondents are fans of our Newsletter; the group is a little self-selecting in that they have already expressed an interest in data security. Of course, we would like to see the number at 100%, but that would mean our work is already done—and we know we still have a long way to go.

To give a bit of perspective, we conducted two additional surveys that represent a more general audience that we published, here and here. In those two surveys the adoption rate for encryption is closer to 50%. So, hats off to our fans for being above the curve!

Using Key Management

Now, the bad news: Only 50% of respondents say that they use proper key management to secure their encrypted data-at-rest (again, a little self-selecting in that, as part of the reason they like our Newsletter is that they are learning more about key management). Interestingly, even if you adjust the data to only look at those who replied that they do use encryption, the number only jumps to 66%.

As a comparison with the wider community, only about 30% of respondents in our other two polls (referenced above) said that they use encryption key management to securely manage their keys.

Expert Weigh-In: Patrick Townsend, CEO of Townsend Security
"Encryption is not enough. In order for encryption to be secure, the keys must be properly managed—100% of the time. If you don’t properly manage your encryption keys, it is like placing your house keys under your welcome mat. Every good thief knows to look in the obvious places for easy entry. Hackers do as well."

 

Encryption and Key Management Use, per Database/Blob Storage

Using Encryption per Database

It is no surprise to see that, overall, if a database/blob storage reports a rise/fall in the use of encryption, there is also a corresponding rise/fall in the use of proper key management. What is interesting, however, is the databases/blob storage where the respondents reported the widest gap in adoption of key management in comparison to the adoption of encryption. Here are the top five databases and their corresponding adoption gaps:

Database Gap in Encryption to Key Management Adoption
SharePoint: 40%
SAP: 28%
SQL Server Enterprise Edition: 26%
MySQL, SQLite, PostgreSQL, etc: 26%
MongoDB: 24%

 

Encryption & Key Management for SQL Server - Definitive GuideWhat may or may not be surprising is that SharePoint leads the pack in lack of key management adoption (compared to encryption adoption) and SQL Server Enterprise Edition comes in third. SharePoint is built on top of Microsoft SQL Server as its datastore (for structured data, at least). For SQL Server 2008 Enterprise edition and up, you now have the ability to not only take advantage of SQL Server’s Transparent Data Encryption (in SharePoint and SQL Server), but you also can leverage the power of a third-party encryption key manager using Extensible Key Management (EKM). This means it is incredibly easy to not only deploy encryption but also proper manage the encryption keys.

What is less surprising is the other three that made the top of the list. All these come with free editions that do not come with encryption libraries, let alone the ability to properly manage the keys. So anyone spinning up a free version of these databases will, by their very nature, not be able to secure their data.

Expert Weigh-In: Tim Roncevich, Partner at CyberGuard Compliance
"Many Enterprise editions of databases come with robust AES encryption and a way for a third-party vendor to manage the encryption keys. If you are storing sensitive data in an open-source, or free, version of a database, upgrade today. Hacks similar to the Cathay Pacific breach of 2018 were due to the company not upgrading to the Enterprise edition to take advantage of the encryption and key management that were available to them."

 

What Virtualization Do You Use?

Virtualization Used

About three-quarters of respondents said that they use VMware in their environment. The other quarter reported using Hyper-V, Red Hat Virtualization, Citrix Hypervisor, or KVM. Less than 10% said they used multiple virtualization platforms.

This is great news for the majority of businesses, then, in terms of encryption and key management. VMware’s vSphere 6.5 and up come with encryption ready to use. Not only that, but using a third-party encryption key manager is easy to set up and deploy.

Expert Weigh-In: Sharon Kleinerman, Director of Sales at Townsend Security
"For those organizations struggling to secure their data-at-rest with encryption and key management, doing so has never been easier. If you have VMware 6.5 and above, you simply set up your third-party key manager through vSphere’s KMS Cluster KMIP interface, tell vSphere which VMs you want encrypted, and your data is encrypted. Same with vSAN. It really is easy to encrypt with VMware as your virtual environment."

 

Backup & Recovery Solutions

Backup and Recovery Used

Backup and recovery solutions are an integral part of business continuity. In fact, Allied Market Research estimates that the market will grow by almost 25% year over year through 2023. In the next few years, however, Gartner estimates that 50% of companies will augment or replace their current backup solution with another.

Our findings fall roughly in line with Gartner’s research. According to our survey, about 40% of respondents say they will, or don’t know if they will, replace their current backup and recovery solution.

Expert Weigh-In: Steve Brown, Partner at Rutter Networking Technologies
"For those thinking of switching your B&R solution, it is important to make sure that the solution you are switching to provides encryption and a way to manage your encryption keys. Encryption should not be an afterthought. Instead, it should be one of the main drivers as to why you would either stay with your current solution or look farther afield."

 

Conclusion

The rate at which data breaches are happening is not slowing down. We all know this. But the adoption rate of best practices is still lagging. While it is heartening to see our blog’s fanbase beating the overall average for using encryption and key management to secure sensitive data-at-rest, We still have a long way to go.

The good news, it is easier than ever to adopt best practices. If you are thinking about truly defending yourself with a defense-in-depth strategy, talk to us today.

 

Encryption

 

Topics: Encryption Key Management

MongoDB World 2019 Encryption Survey

Posted by Ken Mafli on Aug 8, 2019 8:42:34 AM

This June we had a chance to participate in MongoDB World 2019 in New York City as an exhibitor. It was a great time as MongoDB professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

 

MongoDB-Survey-2019

 

If you are looking to protect your encryption keys for your sensitive data in MongoDB, you need a FIPS 140-2 compliant centralized key manager that:

  • Never charges you additional fees for connecting a new end-point.
  • Never limits the number of end-points based on the model of the KMS.
  • Never limits the number of encryption keys generated or stored.
  • Never forces you to pay extra fees for software patches.
  • Never forces you to pay extra fees for routine software upgrades.
  • Always gives you unmatched customer service.
  • Always protects your keys, 24/7.

You need Alliance Key Manager for MongoDB.

Encryption and key management for MongoDB

 

Topics: MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

2018 SQL Server Encryption Survey

Posted by Ken Mafli on Jan 21, 2019 6:51:00 AM

This last November (Nov. 6-9, 2018) we had a chance to participate in the 20th annual PASS Summit in Seattle as an exhibitor. It was a great time as SQL Server professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

 

SQL-Server-Survey-2018

 

A special thanks to our contributors for their expertise and guidance. You all are clear-minded professionals that have a lot to offer those looking to better secure their data:

-Sebastian Meine, Ph.D., sqlity.net
-Steve Brown, Rutter Networking Technologies
-Tim Roncevich, CyberGuard Compliance
-Sharon Kleinerman, Townsend Security
-Patrick Townsend, Townsend Security

If you are looking to protect your encryption keys for your sensitive data in SQL Server, you need a FIPS 140-2 compliant centralized key manager that:

  • Never charges you additional fees for connecting a new end-point.
  • Never limits the number of end-points based on the model of the KMS.
  • Never limits the number of encryption keys generated or stored.
  • Never forces you to pay extra fees for software patches.
  • Never forces you to pay extra fees for routine software upgrades.
  • Always gives you unmatched customer service.
  • Always protects your keys, 24/7.

You need Alliance Key Manager for SQL Server.

Alliance-Key-Manager-for-SQL-Server 

 

 

Topics: Key Management, Extensible Key Management (EKM), SQL Server 2008, Microsoft, Info-graphic, SQL, Encryption Key Management, SQL Server, Transparent Data Encryption (TDE), SQL Server encryption

Three Ways to Fast Track Your Encryption and Key Management Project

Posted by Ken Mafli on Jan 2, 2019 6:21:00 AM
Three_Ways_to_Fast_Track_Your_Encryption_and_Key_Management (2)-1

 

Both encryption and proper key management are a crucial part of defending your sensitive data. Consider the massive Marriott/Starwood Resorts data breach that was announced at the end of November, 2018. Attackers were able to first gain access to their systems in 2014, almost a full four years before they were detected in September of 2018.

eBook: Definitive Guide to Encryption Key ManagementTo date, it is estimated that over 500 million records were compromised. 327 million of which contain personally identifiable information (PII) like names, physical addresses, birthdays, etc. In a statement put out by their parent company, Marriott, they noted that, “for some, the information also includes payment card numbers and payment card expiration dates, but the payment card numbers were encrypted using Advanced Encryption Standard encryption (AES-128). There are two components needed to decrypt the payment card numbers, and at this point, Marriott has not been able to rule out the possibility that both were taken.” (italics and bolding mine)

So, while the information was encrypted, the company cannot rule out that “two components needed to decrypt” were not taken. One of these needed components would be the encryption keys. No one knows for sure why they they cannot rule this out, but if the encryption keys were properly managed, the potential for them being stolen along with the data would be highly unlikely. Encryption is crucial to securing sensitive information. Just as important: properly managing the encryption keys.

But encryption, and by extension key management, have a bad reputation for being difficult to deploy in the enterprise. Encryption projects used to be costly as well as time and personnel intensive. While many databases came with encryption as part of their native libraries, it was a largely manual process not for the faint-of-heart—and add on top of that finding ways to properly manage the encryption keys; most developers would put it off for another day.

The good news, much has changed in the last 10+ years. Deploying encryption and key management can take a fraction of the time it normally took. But that doesn’t mean to you don’t have to work smart. Coming at an encryption project in a haphazard way could cost you time, money, and sensitive data not getting the proper protection it needs.

Follow along for three tips you need to get your encryption project off on the right direction.

Create a Unified Policy for Encrypting Data-at-Rest

The first step in any project is to get agreement between stakeholders as to what data-at-rest should be encrypted. Some of the obvious contenders would be any cardholder data (CHD) you have in you environment, personal health information (PHI) or personally identifiable information (PII) that needs to be kept safe. Many time this information falls under a compliance regulation like PCI DSS or HIPAA. The choice to encrypt this data is clear.

But less clear is data, that if exposed, would leave your company exposed to brand damage, lawsuits, or loss of competitive advantage. Whether it's the plans for a new product, proprietary schematics for an existing product, or information that exposes your business processes, business has a lot of information they want kept secret.

In fact, Deloitte estimates that Intellectual Property data can constitute more than 80 percent of a enterprise company’s value. Below is a short (and certainly not exhaustive) list of items that your company should be encrypting:

  • Product/Solution Documents: If your product or service relies on proprietary information to give you a competitive advantage in the marketplace, you need to encrypt anything that would give your competition a window into how your products or solutions work.
  • Research and Development (R&D) Data: In the same vein, any R&D you are conducting is your advantage in tomorrow's competitive landscape. Don't let it be stolen from you because you did not properly secure it.
  • Financial Reports: If you don’t want your competitors spying on your financial information, encrypt it.
  • Legal Documentation: There is a lot of documentation, that if made public, could tarnish a company's reputation. Harassment settlements, sexual misconduct accusations, financial misdealings, even benign partner agreements—all these need to be kept private and out of the public's eye.

Just as crucial as protecting PII and IP data is protecting any client data you are responsible for. Making sure that client data is safe is of utmost importance. Just one breach could cause major reputational damage and see a loss of current and future contract revenue.

Use Existing Encryption

Most databases now (like SQL Server and MongoDB), as part of their Enterprise editions, come with Transparent Data Encryption (TDE). This encryption encrypts the entire database while at-rest and normally uses either AES or 3DES encryption. This typically takes less time to deploy than column level encryption as there is less configuration to do.

If upgrading to an Enterprise edition is not in the budget, some third party encryption products may be an option. NetLib, for example, file level encryption for SQL Server. It supports all versions of SQL Server from 2000 to 2017 and can save you the upgrade costs from going from Standard or Dev editions to Enterprise.

Learn More: SQL Server Encryption Survey 2018

Use an Established Third Party Vendor for Encryption Key Management

The most important part of a data encryption strategy is the protection of the

encryption keys. Because encryption key management is crucial to data protection, the National Institute of Standards and Technology (NIST) provides guidelines on best practices for key management. NIST Special Publication SP-800-57 provides recommendations for encryption key management.

What this means to you is that managing your encryption keys is not a simple process. Why? Because you must create a defense-in-depth system for your encryption keys. Remember, hackers don’t break your encryption, they steal your keys. And the only way you keep your keys safe is to layer them in protection so that only authenticated and authorized personnel have access to them.

The good news is, there are vendors at the ready who already comply with the highest standards and have both virtual and hardware options. The real trick also is finding one that is both dedicated and affordable. Of course, there are some key manager options provided by public clouds, but they are not a dedicated key manager (i.e. you own the key manager) but rather your keys are housed are a multi-tenant environment as well as the public cloud provider having administrative access. This can get tricky as a public key manager may be compelled by the government to hand over your keys, without your knowledge, and unlock your data. Worse yet, if your data is stored in the same public cloud, the cloud provider would have access both to your keys and data. Unsafe! To learn more, check out our recent blog post on PCI SSC guidance around this issue.

Here at Townsend Security we do things differently. Not only is our Alliance Key Manager a dedicated key manager, you can purchase our key management platform of your choice and use it the way you want. It is that simple. From that point on:

  • We never charge you fees for connecting a new end-point.
  • We never limit the number of end-points based on the model of the KMS.
  • We never limit the number of encryption keys generated or stored.
  • We never force you to pay extra fees for software patches.
  • We never force you to pay extra fees for routine software upgrades.

We do things a little differently here at Townsend Security and we think that makes encryption just a little easier.

 

eBook: Definitive Guide to Encryption Key Management

 

 

Topics: Encryption Key Management, Enryption

SQL Server TDE vs Cell-Level Encryption: A Brief Comparison

Posted by Ken Mafli on May 31, 2017 2:21:18 PM

In 2008, Microsoft introduced Transparent Data Encryption (TDE) to its Enterprise and Datacenter Editions of SQL Server. Billed as a way to seamlessly deploy SQL Server encryption, users now had the choice of full database-level encryption, instead of just the previous choices of cell-level encryption (CLE), Encrypting File System (EFS), or Bitlocker. With its rapid deployment, ease-of-use, and enhanced security TDE has been a staple for every version of SQL Server Enterprise Edition (and Developer Edition) ever since.

Versions of SQL Server Enterprise with TDE:
2008, 2008 R2, 2012, 2014, 2016

Encryption & Key Management for SQL Server - Definitive GuideSQL Server TDE has become a favorite for bulk encryption in meeting regulatory compliance (like PCI DSS) or internal corporate data security initiatives. But while TDE has it’s advantages, it is not a cure-all. Sung Hsueh did a great job explaining the advantages and disadvantages of TDE as compared to CLE. The following is a curated look at that whitepaper. Let’s take a quick look:

What is Transparent Data Encryption?

TDE fundamentally is full database-level encryption. It functions at the Input/Output (I/O) level. Any data written into the database is automatically encrypted. Backups are also automatically encrypted. Data in use is decrypted by TDE as they are read by a user or application and stored, in clear text, in memory. Since the data-in-flight is decrypted; TLS or SSH (or now, “Always Encrypted”) should be enabled to protect the data while in motion.

What is Cell-Level Encryption?

Introduced in 2005, CLE is implemented as a series of built-ins. It is a manual process “that requires a re-architecture of the application to call the encryption and decryption functions.” Hsueh also notes that “the traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques [of TDE] can be used.” 

CLE vs. TDE

The advantages of CLE:
  • Since it is column level encryption, it encrypts only the sensitive information in a table.
  • With CLE, the data is still encrypted even when it is loaded into memory.
    CLE allows for “explicit key management” giving you greater control over the keys and who has access to them.
  • CLE is highly configurable, giving you a high degree of customization (especially when your applications require it).
  • Queries may be faster with CLE if the encrypted column(s) is not referenced in the query. TDE will always decrypt the entire row in the table. CLE will decrypt the column value only IF it is a part of the data that is returned. So in some cases CLE implementations provide much better overall performance.

The disadvantages of CLE:

  • One of the main disadvantages of CLE is the high degree of fully manual application changes needed to use it. TDE, on the other hand, can be very simple to deploy with no changes to the database, tables or columns required.
  • CLE can also have high performance penalties if search queries cannot be optimized to avoid encrypted data. “As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse [than TDE].”

The whitepaper goes on to note that with CLE performance impacts “are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted.” TDE, on the other hand, only had a 3-5% average performance impact compared to a non-encrypted database.

Final Thoughts

A case could be made for using CLE in conjunction with TDE as a defense-in-depth strategy. By selectively encrypting columns with CLE, encrypting the full database with TDE, and then managing the separate keys with a centralized key manager; it would ensure that crucial data was protected, even while loaded into memory.

But, in general, TDE and CLE are used for different purposes. If you are looking to encrypt a small amount of data, if your application “has custom design requirements,” or if performance is not a much of a concern, CLE may have advantages over TDE. But, if performance is a concern or you would like to avoid manually implementing encryption (normally a time-consuming process) then TDE is the way to go.

For more information on both types of encryption and how they relate to Extensible Key Management, visit our Definitive Guide to SQL Server Encryption & Key Management.

Encryption

Topics: SQL Server, Cell Level Encryption, Transparent Data Encryption (TDE), SQL Server encryption

Trying to Outfox the Other - A Brief Look at Cryptography and Cryptanalysis

Posted by Ken Mafli on Mar 31, 2017 10:35:55 AM

 A few months ago I wrote a definitive guide to Cryptographic Key Management. In it I wrote a section: A Brief History - the Need for Encryption Key Management. I wanted to expand upon the Classical Era of cryptography a bit because the story of data security goes back for millennia, and the twists and turns of this story can be felt even today.

Introduction

eBook: Definitive Guide to Encryption Key ManagementThere has been a competition playing out through the centuries all the way from the highest corridors of power down to the shadiest back alleys. It is a struggle of those with a secret and those who want to uncover it. It is the story of cryptography and cryptanalysis.

As with every competition, each side is constantly trying to outfox the other. Peter Baofu described the competition this way, it is “the never ending cycle of replacing old broken designs” of cryptography and “new cryptanalytic techniques invented to crack the improved schemes.” In fact, “in order to create secure cryptography, you have to design against [all] possible cryptanalysis.” This means that both sides are in a never-ending arms race.

In his book, “The Future of Post-Human Mass Media,” Peter Baofu describes two main types of cryptanalysis: Classical and Modern Cryptanalysis. Let’s take a look at the Classical Period to see how this cat and mouse game has played out through the centuries:

The Classical Cat-and-Mouse Game

Classical Cryptography

One of the earliest forms of “secret writing” is the Substitution Cipher where each letter of the message is systematically replaced by another set of predetermined letters. In it’s most famous form, the Caesar Cipher, used by Julius Caesar himself (1st century, B.C.E):

“each letter in the plaintext is 'shifted' a certain number of places down the alphabet. For example, with a shift of 1, A would be replaced by B, B would become C, and so on.”

Another technique was Steganography, which literally means: “covered writing,” is the art of concealing a message in plain sight. Mehdi Khosrowpour recounts one of the first recorded instances (in the 5th century, B.C.E):

“Demaratus, a Greek who lived in Persia, smuggled a secret message to Sparta under the cover of wax.” It “ was to warn Sparta that Xerxes, the King of Persia, was planning an invasion ... by using his great naval fleet. He knew it would be very difficult to send the message to Sparta without it being intercepted. Hence, he came up with the idea of using a wax tablet to hide the secret message. In order to hide the secret message, he removed all the wax from the tablet, leaving only the wood underneath. He then wrote the secret message into the wood and recovered the tablet with the wax.”

Classical Cryptanalytic Response

While steganography is only hard to crack if you don’t uncover the message; substitution ciphers were meant to remain a secret even if the message fell into enemy hands. It remained a fairly reliable means of securing messages, so long as the cipher was not revealed.

All that changed with the first recorded technique of cryptanalysis: Frequency Analysis. This technique “can be traced back to the 9th-century [C.E.], when the Arabian polymath Abu Yusef Yaqub ibn Ishaq Al-Kindi (also known as ‘Alkindus’ in Europe), proposed in A Manuscript on Deciphering Cryptographic Messages.” It comes from the observation that certain letters appear more often than others in a given language (the letter “E,” for example, occurs most often in English). There also also common letter pairings (like “TH” in English).

So, in the case of the Caesar Cipher where the plaintext message is :

meet me at the theater

If each letter is shifted one letter in alphabet, it becomes:

nffu nf bu uif uifbufs

Frequency analysis would note that the most common letter in the ciphertext is “f” (which would suggest it is an “e”) and only letter pairing is “ui” (which would suggest the “u” is “t” and the “i” is “h”). If we replace these portions of the ciphertext we reveal:

_eet _e _t the the_te_

With these two facts of frequency analysis alone we have more than half the message deciphered. With a few logical leaps we could decipher the remaining the five letters. The simple substitution cipher was rendered useless.

The Classical Cryptography Counterattack

Polyalphabetic.jpg

Over the centuries other ciphers were introduced like the Polyalphabetic Substitution Cipher where a repeating, offset key is used to encrypt the plaintext (see picture, courtesy of the Library of Congress). First perfected by Johannes Trithemius in 1518 (although other variants existed beforehand), the person encoding the message would switch alphabets for each letter of the message.

So, “meet me” would now become: “lcbp gy,” a ciphertext that simple frequency analysis could not break since most of the letter and pairing statistics of a given language are not easily recognized.

Although, in time, this type of cryptography was broken by the likes of Charles Babbage using modular arithmetic, the existence of his cryptanalytic techniques remained a military secret for some years.

Final Thoughts

Fascinatingly, it was the use of math to break a cipher that led to our current arms race in data security. The use of math and algorithms to break cryptography means you need longer keys to encrypt the data and prevent a brute force attack; which, in turn, means you need faster computers to break the encryption; which, in turn, means you need longer keys; etc.

Unlike today, however, it took centuries to break a cipher back then. Now, it is just decades. From the Hebern Electric Super Code Cipher Machine in the 1920s, to the Enigma Machine of the 1930s and 40s, to the Data Encryption Standard (DES) of the 1970s and 80s, each seemed invincible until enhanced cryptanalytic techniques or greater computing power toppled it. Our current cryptography is reliable and secure, but quantum computers loom on the near horizon and their non-binary logic could brute force attack our current public key cryptography and make them insecure.

And so the arms race continues. Fortunately, NIST has already forecasted this threat and called for replacements to our current standards, well before it is a crisis.  

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption

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

Hillary's email data breach taught us all the wrong lessons

Posted by Ken Mafli on Feb 28, 2017 9:11:00 AM

In an unprecedented October surprise, Wikileaks dumped thousands of emails onto the internet from the Democratic National Committee (DNC), most of them concerning Hillary Clinton’s presidential campaign.  Later, in defending this move, Wikileaks founder Julian Assange, in an interview with FOX News, “said a 14-year-old could have hacked into the emails of Hillary Clinton's campaign chairman,” reported the Daily Mail.  Assange later revealed in the interview that John Podesta’s, Hillary’s campaign chairman, password was 'password.'  Politifact has gone on to challenge that assertion, saying that “Podesta was using a Gmail account, and Google doesn’t allow users to make their passwords ‘password.’”

Whatever John Podesta’s password was, it has sparked a good deal of renewed interest in good password management.  And far be it from me to downplay this crucial bit of data security.  We still have a long way to go.  In fact, SplashData just completed their survey of over 5 million people’s passwords and found that over 10% of people still use the most commonly guessable passwords like:

  • password
  • 123456
  • qwerty
  • passw0rd
  • Password1
  • zaq1zaq1

If you use any of these, stop it. Now.

But if that is all that we learn from the hack and subsequent data breach, we have missed the lesson.  As far back as June of 2016, it was widely reported, by the likes of Brian Krebs and Jeremy Kirk, that the DNC was vulnerable to attacks do to systemic weaknesses in cybersecurity.  In fact, in Jeremy Kirk’s article, it was noted that a press assistant emailed everyone a new password after a recent breach (a strong password at that: 'HHQTevgHQ@z&8b6').  The irony is, some of the email accounts had been compromised.  The hackers needed only to open the email and use the new password.

Strong passwords are not enough to rebuff the efforts of hackers to gain entry and to render the data useless in case of a breach.  We need proven security measures in order to keep the data safe.  

The data security measures below reflect specific things you can do to secure your data-at-rest in general. While there are more more specific measures you can take for email servers, it is important to remember that organizations have sensitive data everywhere, not just in emails.  That being said, since even seemingly benign emails at the DNC can blow up into political controversy, they probably need to follow these along with more email specific recommendations.  Follow along to find some of the best methods your organization should be using today to better secure your data security posture.

Multi Factor Authorization

2FA.pngAs we have already mentioned, usernames and passwords, by themselves, are not enough to authenticate users.  Truly strong passwords are hard to manage and remember.  And once a system is compromised, login credentials can be scraped with keyloggers, malware, or other such attacks.

You need an external verification process.  You need multi factor authentication (MFA). MFA has traditionally relied on verifying you by two of three ways:

  • Something that you know (i.e.: username, password, challenge questions/responses, one-time-use code, etc.)
  • Something that you have (i.e.: token, RFID cards or key fobs,  mobile phones, etc.)
  • Something that you are (biometrics)

Each of these methods have their advantages and drawbacks. For example:

  • Challenge Questions:
    • PRO: do not require any physical equipment on the user side
    • CON: do rely on the user’s memory, which can be fuzzy when it comes to precisely writing the correct response
    • CON: are vulnerable to deduction through inspection of social media accounts, etc.
    • CON: are “something you know” and so fall into the same category as login credentials, thereby not taking advantage of any other kind of authentication
  • Physical Equipment: (like RFID cards and tokens)
    • PRO: do not rely on a person’s memory
    • CON: can be stolen or lost
    • CON: require active device management from an administrator

One method of authentication that is gaining ground because of its ease of use is authentication that relies on OAuth (an open standard for authorization).  It does not rely on physical fobs (which can be lost) or an SMS text (which can be intercepted).  It, instead, relies on cryptographic code that generates a time specific one-time-use codes based on the user’s secret key and the time. Since the code operates simultaneously (and separately) on the user’s device (typically a mobile phone) and on an internal server, with no need for an internet connection; it greatly reduces downtime because of internet issues and hackers intercepting the one-time-use code.

Encryption

lock.pngStrong, Advanced Encryption Standard (AES) encryption as put forward by NIST should be used to encrypt all sensitive customer and company data.  In 2001 NIST formally adopted the AES encryption algorithm.  Since then, it has been proven countless times to render the data useless in the event of a breach.  In fact, it would take the fastest supercomputer 375 x 1050 years to brute force AES encryption by running through all permutations of an AES 256-bit encryption key.  In comparison, the Sun will reach its Red Giant stage in 54 x 108 years, engulfing Mercury, Venus, and possibly Earth.  In other words, the Earth will be incinerated by the then rapidly expanding Sun before a hacker could effectively crack AES encryption through brute force.

The good news, AES encryption comes standard in most database’s native encryption libraries.  Along with those free versions, there are a number of commercial products that rely on AES encryption available.  So finding a way to secure your data with AES encryption will be fairly easy.  That being said, it is important to understand the development time and performance hits each solution takes. Native encryption libraries are generally free but take a bit of development time.  Commercial solutions take less time to deploy but many times are file/folder level encryption products and have performance hits because they take a longer to encrypt/decrypt than column level encryption products.

Centralized Encryption Key Management

key.pngAs we mentioned, AES encryption is extremely difficult to brute force attack.  It’s strength lies in its ability to encrypt the data with a very long key (typically 256-bit). But it’s strength is also its weakness.  If your encryption key becomes known to a bad actor, your encrypted data becomes compromised.  That is why any encryption strategy worth its salt will include proper, centralized encryption key management.  

When defending your encryption key with full lifecycle key management, consider these things:

  • The encryption keys should be logically or physically separated from the encrypted data.  This way, if the encrypted data is compromised, they will not be able to decipher it.
  • The encryption keys should only be generated with a cryptographically secure pseudo-random number generator (CSPRNG).
  • Restrict administrator and user access to the keys to the least amount of personnel possible.
  • Create clear separation of duties to prevent improper use of the keys by database administrators.
  • Manage the full lifecycle of the keys from key creation, activation, expiration, archive, and deletion.

For a more comprehensive view of encryption key management, please view the Definitive Guide to Encryption Key Management.

Real Time Log Monitoring

Forrester, in 2013, promulgated the cybersecurity model of “Zero Trust.”  In it, they put forward the motto: “never trust, always verify.”  By this, they mean that all users should be authenticated, restricted to the least amount of data possible, and verified that they are doing the right thing through real-time monitoring.  Of which, they advocate for:  

  • Real Time Event Collection in which you collect and log all events, in real time.
  • Event Correlation in which you analyze all events and narrow in on the ones that do not conform to expected patterns.
  • Resolution Management in which you investigate all suspect behavior and either classify them as either benign or a possible threat for further investigation.

There are many Security Information Event Management (SIEM) tools available that accomplish this.  For more information, refer to Gartner’s SIEM Magic Quadrant to find the tools that fit your needs.

Final Thoughts

Defending data-at-rest is a never ending struggle of building robust defenses and continuous improvement.  But, it's not a question of if, but when, a data breach will happen.  And if the DNC data breaches taught us anything is that breaches can be embarrassing and costly.  Since  hackers are only growing more sophisticated in their techniques, it is incumbent upon us to respond in ever increasing levels of agility and sophistication of our own.

The old models of the high, guarded perimeter with complex passwords to gain entry are just not enough.  We need a higher degree of authentication, sensitive data rendered useless, and constant real-time monitoring of all traffic.  You data depends on it.

Turning a Blind Eye to Data Security eBook

Topics: Data Security

Three Core Concepts from "Zero Trust" to Implement Today

Posted by Ken Mafli on Feb 1, 2017 12:57:58 PM

 

“There are only two types of data that exist in your organization: data that someone wants to steal and everything else.”

Forrester Research

eBook The Encryption GuideIn 2013, Forrester released an outline of their proprietary “Zero Trust Model” of information security to The National Institute of Standards and Technology (NIST).  Their model seeks to change “the way that organizations think about cybersecurity,” execute on higher levels of data security, and all the while “allowing for free interactions internally.”

But, when looking to better secure your organization’s data security posture, it is good to start with what has changed.  In the report, Forrester concluded that the old network security model was that of “an M&M, with a hard crunchy outside and a soft chewy center.”  It is the idea of the hardened perimeter around the traditional, trusted datacenter.  This old model is fraught with vulnerabilities as the traditional model is not equipped to handle new attack vectors with IoT, workforce mobility, and data centers moving to the cloud. It is increasingly becoming outmoded and weak.

In it’s place must come a data security model that takes into account the current network landscape and its vulnerabilities.  Enter, Zero Trust.  It builds upon the notion of network segmentation and offers key updates all under the banner: "never trust, always verify."

Below are the three main concepts to Zero Trust.  Follow along as we break down the trusted/untrusted network model and in its place rebuild a new trust model.

 

Assume All Traffic is a Threat

The first rule of “never trust, always verify” is that all traffic within the network should be considered a potential threat until you have verified “that the traffic is authorized … and secured.” Let’s look at these two components:

  • Authorized Traffic: Each end user should present valid (and up-to-date) login credentials (i.e. username and password) as well as authenticate themselves with multi factor authentication for each session logging into the network.  Usernames and passwords are not enough.  Only multi-factor authentication can reduce the risk of a hacker obtaining and misusing stolen login credentials.
  • Secured Traffic: All communication, coming from inside and outside of the network, should be be encrypted.  It should always be assumed that someone is listening in.  Using SSH or TLS and keeping abreast of their potential vulnerabilities is the only way to reduce the risk of exposure.

 

Give Minimal Privileges

The only way to minimize the risk of employees, contractors, or external bad actors misusing data is to limit the access each user/role is given to the least amount of privileges possible.  With this, it is a forgone conclusion that all sensitive data is already encrypted and minimal privileges are given as to who can decrypt it.  We implement a minimal privileges policy so that “by default we help eliminate the human temptation for people to access restricted resources” and the ability for hackers to access a user’s login credentials and thereby have access to the entire network.

Role-based access control (RBAC) model, first formalized by David Ferraiolo and Richard Kuhn in 1992 and then updated under a more unified approach by Ravi Sandhu, David Ferraiolo, and Richard Kuhn in 2000 is the standard today.  It’s ability to restrict system access only to authorized roles/users makes it the ideal candidate for implementing this leg of Zero Trust.  While Zero Trust does not explicitly endorse RBAC, it is best game in town, as of today.  For a deeper dive, visit NIST’s PDF of the model.

 

Verify People are Doing the Right Thing

Once we have authenticated each user and restricted them to the least amount of data possible to adequately do their job, the last thing to do is “verify that they are doing the right thing” through logging and inspection.

Here is a short (and certainly not exhaustive) list of techniques used to inspect all events happening in your network.  

  • Real Time Event Collection: the first step is to collect and log all events, in real time.
  • Event Correlation: Next you need to analyze all of the events and narrowing in on the events that need greater scrutiny.
  • Anomaly Detection: In a related move, you will want to identify the events that do not conform to the expected pattern and investigate further.
  • Resolution Management: All events that do not meet the expected pattern should be investigated and either classified as benign or deemed a possible threat and given for further investigation.

Note: There are many tools available that accomplish these.  Please refer to Gartner’s Security Information Event Management (SIEM) Magic Quadrant to find the tools that may interest you.

 

Final Thoughts

It's not a question of if, but when, a data breach will happen. Hackers grow more sophisticated in their attacks and threaten everything from intellectual property to financial information to your customers Personally Identifiable Information (PII).  The old model of the high, guarded perimeter with the trusted, internal network no longer functions as a secure model.  Zero Trust offers a more comprehensive approach to today’s data security needs.  As you look to deploy this model, begin to seek out tools that will help you.  Here is a short list of some of the tools to consider:

  • Log Collection Tools: Some platforms, like the IBM i, have proprietary formats, that are difficult for SIEMs to read.  Make sure your SIEM can fully collect all needed logs.  If it cannot, find or make a tool that will properly capture and send the logs onto your SIEM.
  • SIEM Tools:  As mentioned earlier in the article, there are many good SIEM tools out there to help you collect, analyse, and monitor all events on your network.
  • Encryption (data-in-flight): Fortunately, there are many open source protocols for secure communications like SSH and TLS.
  • Encryption (data-at-rest): Advanced Encryption Standard (AES) encryption is ubiquitous in most platform’s native encryption libraries.  There are also a number of products that offer column level to folder/file level encryption.
  • Centralized Key Management: The encryption you deploy is only as good and the level of protection you give to the encryption keys.  Therefore, robust encryption key management is a must.
  • User Access Management: Managing privileges, credentials, and multi factor authentication can be a daunting task.  The more more you can automate this, the better.

In many cases, adopting this approach will not be about bolting on a few products onto your existing data security framework but completely renovating it.  Don’t let expediency force you to defend your data with only half measures.  Take a deep dive into Zero Trust’s approach and see where you may be vulnerable.

 

The Encryption Guide eBook

Topics: Data Security

The Definitive Guide to AWS Encryption Key Management
 
Definitive Guide to VMware Encryption & Key Management
 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all