Townsend Security Data Privacy Blog

If you’ve been following this blog recently you know that I’ve been advocating for the use of encryption to help prevent ransomware attacks. Ransomware attackers have been adapting to the new reality that a lot of companies have deployed good backup strategies to recover their files. Without that leverage the attackers can’t extort payments for recovery of your systems.

So, what are they doing now? They are exfiltrating your sensitive data and using that as additional leverage. 

Oh, you have backups and you don’t want to pay? OK, we took your sensitive data and we are going to publish it. Do you have secret intellectual property or business plans? Do you have sensitive medical information on your patients? Do you have sensitive information about children in your care? 

Under this kind of pressure many ransomware victims decide to pay the ransom. 

That’s why it is important to encrypt your data before a ransomware attack. If the attacker can’t read your data because it is encrypted they can’t threaten to release it.

It has been frustrating to me that most security recommendations on how to protect yourself from a ransomware attack omit the step of encrypting your data first.

But that has now changed! And it is long overdue.

Here is what President Biden’s new executive order recommends (emphasis added):

What we urge you to do now:

Implement the five best practices from the President’s Executive Order:President Biden’s Improving the Nation’s Cybersecurity Executive Order is being implemented with speed and urgency across the Federal Government. We’re leading by example because these five best practices are high impact: multifactor authentication (because passwords alone are routinely compromised), endpoint detection & response (to hunt for malicious activity on a network and block it), encryption (so if data is stolen, it is unusable) and a skilled, empowered security team (to patch rapidly, and share and incorporate threat information in your defenses). These practices will significantly reduce the risk of a successful cyberattack. 

And  more ...

And this:

For Federal Agencies:

Modernize and Implement Stronger Cybersecurity Standards in the Federal Government. The Executive Order helps move the Federal government to secure cloud services and a zero-trust architecture, and mandates deployment of multifactor authentication and encryption within a specific time period. Outdated security models and unencrypted data have led to compromises of systems in the public and private sectors. The Federal government must lead the way and increase its adoption of security best practices, including by employing a zero-trust security model, accelerating movement to secure cloud services, and consistently deploying foundational security tools such as multifactor authentication and encryption.

Encryption is not the only thing you need to do, but it is a critical part of a ransomware protection strategy. It is heartening to see this being recognized.

There is some good news: Encryption is fast, easy and affordable. If you are a small or midsize organization you will be glad to know that there is an affordable solution for your encryption strategy. Encryption and encryption key management are no longer the headaches they once were. You or your IT Support organization can address your encryption needs in a rapid manner. 

If you are an IT Support Provider or Managed Service Provider trying to help your customers with security, you are going to love our MSP Partner program. Affordable key management for VMware and the cloud, usage-based billing, and no upfront fees. You will be profitable from the first customer. More information here: 

https://townsendsecurity.com/msp

Ransomware attacks can be devastating to an organization, but you have tools to protect yourself. Give us a call.

Patrick

References:

https://image.connect.hhs.gov/lib/fe3915707564047b761078/m/1/8eeab615-15a3-4bc8-8054-81bc23a181a4.pdf

https://www.whitehouse.gov/briefing-room/statements-releases/2021/05/12/fact-sheet-president-signs-executive-order-charting-new-course-to-improve-the-nations-cybersecurity-and-protect-federal-government-networks/

The Colonial Pipeline ransomware attack and resulting crisis that affected millions of people was shocking because of its scale and impact. Shocking, but it was not surprising. We have been watching an increase in the number of ransomware attacks over the last few months. No organization, large or small, has been immune from the attacks. Hospitals, schools, local governments, national agencies – even police departments and courts – have suffered from debilitating ransomware infections. Colonial Pipeline was the first publicly known attack on critical energy infrastructure, but it won’t be the last.

Most modern ransomware attacks have two components:

• Encryption of your systems to deny you operational access, and
• Theft of unencrypted sensitive data.

The attackers encrypt your data with a secret key and then promise to restore it when you pay the ransom. This is the well-known part of a ransomware attack. You typically must pay the ransom to a secret Bitcoin account controlled by the attackers. After payment, if you are lucky, the attackers will give you the secret key to unlock your data.

There is another, less well-known aspect of ransomware attacks. And that is that the attackers often steal sensitive data before they encrypt it. Why do they do this? Well, if you are able to restore your systems without paying the ransom, they can then use the threat of releasing that data to extort the payment from you. And it is very effective. More on protecting yourself from this aspect of ransomware below.

There is good guidance from security groups and governmental agencies on how to protect yourself from a ransomware attack. Having good backups that are not connected to the network is an important part of that guidance. You should also deploy other security measures like active monitoring for anomalous behavior, appropriate segmentation of users, proper network controls, and so forth. And, never forget that training users in good security hygiene is absolutely essential.

I think a number of organizations have gotten reasonably good at this part of ransomware protection. There are still big gaps, of course. And smaller to midsize organizations are lagging in the deployment of these basic protections. But what to do is no longer the question. Getting it done and doing it right is the challenge.

But what about the second part of the ransomware attack? What happens when the attackers steal your unencrypted sensitive data?

We have to give credit where it is due. Cybercriminals who deploy ransomware are very good at what they do. They’ve learned to adapt to a changing landscape. As you got better at doing backups and recovering your data in a timely fashion, they added another technique to extort a payment – They are taking your very sensitive data. If you refuse to pay the ransom they threaten to release the data. To prove their point they will often release a very small amount of your data.

Imagine your shock when you see highly sensitive medical information showing up on the attacker websites. Or sensitive information about students, or sensitive court records. Suddenly the urgency is much greater, and many pay the ransom when this happens.

Having a good backup is not going to help you now. So, what can you do? It is time to add another tool to your defenses – encryption of your own sensitive data.

You should encrypt your sensitive data to deprive the attackers of access to it. If the attacker steals your data in an encrypted state, it is not usable. Encryption is the security control that you need to add to your ransomware strategy. I know, you’ve been putting implementing this important security control. But the stakes are higher now. If Sony or Equifax had encrypted their data, we would not still be talking about the massive loss of data and the disruption they experienced.

Here are some basics to keep in mind as you deploy encryption:

• Create a map of your sensitive data, and a plan. You should encrypt the most sensitive data first.
• Encryption key management is critical to your security. Use a professional key management system to store keys away from the data. Never store encryption keys on the same server that hosts the data.
• Restrict access to the databases with sensitive data. Only those people in your organization who have a need to access sensitive data should be able to do so. Your DBA will know how to do this.
• Monitor user access to your sensitive data and take immediate action for unautorized access. Use a professional SIEM solution to do this.
• Monitor access to your encryption key management solution. Your KMS is a critical part of your encryption strategy.
• Take advantage of database and storage vendor support for encryption and key management. Using VMware for your infrastructure? Implement encryption of VMs and vSAN. Using Microsoft SQL Server? Implement Transparent Data Encryption with an external KMS for the keys. It is fast and easy, and supported by the database vendor.

There are a lot of reasons why organizations are lagging in terms of encrypting their sensitive data. Fears about performance, fears about lost encryption keys, fears about the cost of key management systems, and so forth. All of these challenges have been overcome in recent years. Put your fears aside and protect your data.

Here is a hint:

Don’t let the PERFECT be the enemy of the GOOD. For example, you don’t have to encrypt everything at one time. Tackle the most sensitive data first, and tackle the easy projects first in order to build experience. Then tackle the remaining projects as quickly as you can. Also, don’t be afraid to deploy key management solutions from different vendors. KMS systems are so easy to manage now that having more than one system rarely increases administrative costs. Find the best, most cost effective KMS solution for your database and use it!

Encryption is your friend when you control it. It can provide protection from cybercriminals who attempt to steal your data in order to extort a payment. You can get encryption done quickly and at a reasonable cost. You don’t have to pay exorbitant licensing fees for a good key management system. If you have cost concerns, give us a call.

If you are a managed service provider trying to help protect your customers, you might like to know about our MSP Partner program. Give us a shout to learn more.

Patrick

Managed Service Providers have a real challenge when they try to talk to their customers about the benefits of encrypting their sensitive data. If your experience is like mine, pretty soon their eyes glaze over and they are wanting to change the subject. I get that - encryption is a subject that only nerds can love. But we also know how important encryption is. So how do we convey that?

One of our MSP partners shared this bit of wisdom:

“Ask them if they carry cyber insurance”.

“Why?” I asked, more than a little confused about how this related to encryption.

“Have you read your policy?” she asked. “Take a look at the section on encryption.” And then she shared a short form application for cyber insurance from a large carrier.

Wow! I’ve had my head in the technical weeds of encryption and compliance for too long. Here is an extract from a short form insurance application:

Indicate whether the Applicant encrypts private or sensitive data:

1. While at rest in the Applicant’s database or on the Applicant’s network __Yes __No
2. While in transit in electronic form __Yes __No
3. While on mobile devices __Yes __No
4. While on employee owned devices __Yes __No
5. While in the care, custody, and control of a third party service provider __Yes __No

I am guessing that many organizations just answer “Yes” to all of these questions without thinking about it. As my MSP partner pointed out, if you respond incorrectly on an insurance application you negate any benefits you might receive. Are they covered in the event of a data breach or ransomware attack? Maybe not. That can be a shocker to the end customer.

Rather than talk about encryption in an abstract way, this MSP talks about their cyber insurance policy and what they need to do to ensure coverage. She said that this is the most effective method she has ever used to get agreement from a customer to implement encryption of their data at rest. She’s never had someone decline to implement this important security control once they realize what is at stake.

My takeaway is this:  not everyone is as excited or interested in encryption as I am. But everyone knows how important it is to have insurance coverage. MSPs know that encryption is a core part of a defense against cyber attacks including ransomware. Modern ransomware attacks include encrypting your data to deny you access, as well as stealing your data and holding you hostage with the threat of making it public. You might have a good backup plan to recover your data, but you can’t defend yourself from the threat of public release if the hacker has your unencrypted data. If the attacker can’t read your data because you encrypted it, they can’t release it to the public.

I hope this practical example helps you talk with your customers about the importance of encryption.

How are we at Townsend Security helping MSPs get the job done?

Our MSP partner program helps MSPs protect VMware infrastructure by providing our key management solution, Alliance Key Manager, on a low cost, monthly usage basis. You can encrypt VMs, vSAN and deploy vTPM easily. Imagine offering encryption to your end customers and not incurring any upfront costs or annual minimum payments for the KMS. Imagine turning encryption into a profit center for your benefit and for your customer’s benefit. Imagine offering encryption to even your smallest customers and knowing that they can afford it!  And, imagine doing this for your hosting platform, for the cloud, and for your customer’s on-premise infrastructure.

Imagine the relief of your customers after a data breach when they learn that cyber criminals did not steal unencrypted data!

Our MSP partners are doing this every day.

If you are a Managed Service Provider and want to know more about our partner program, you can learn more here.

If you are an MSP I hope you will take advantage of our MSP partner program. Talk to us to find out more.

Patrick

I might as well start the New Year with an admission and an apology. Let’s clear the slate.

In the past I’ve minimized the use of encryption as a specific way to deter Ransomware attacks. My thinking was that encryption would not really help you if your systems are compromised by Ransomeware. After all, my thinking was, the data is still on your servers it just isn’t accessible because it is now encrypted with a key that you don’t have. Of course, you can pay the ransom to unlock your data. There are lots of good reasons to encrypt sensitive data, but I was not seeing encryption as a specific way to specifically minimize the risks associated with Ransomware.

I believed that your best defense against ransomware was to have good backups and be prepared to restore systems quickly from those backups. A lot of our customers had become lax in their backup strategy, and this left them exposed to Ransomware attacks. They just weren’t able to quickly restore from backups, or those backups did not exist, or they were not current enough.

I failed to understand the evolving nature of Ransomware threats. It simply did not occur to me that a cybercriminal would BOTH lock your data AND steal the data and threaten to release it if the ransom payment was not made. That is exactly what is happening now. 

It is now clear to me that encrypting your sensitive data is an important part of your defense against Ransomware attacks. If the attacker cannot access the data, they can’t threaten its release to put pressure on you. So it is time to revisit your security strategy around Ransomware:

• Backups are still important. They are a first line defense against Ransomware.
• Your backup strategy is not complete until you fully test the restore process. You will always find glitches during the test of the restore operation. You don’t want to be finding these glitches during a Ransomware recovery process.
• Encrypt all sensitive data to deny its use by attackers.
• Use proper encryption key management as a part of your encryption strategy. Locally stored encryption keys (SQL Server, MongoDB, MySQL, and so forth) are easy to recover. If you are not protecting the encryption keys you don’t have an encryption strategy.

There is much more that you need to do to protect against Ransomware, but these items are crucial to your strategy. 

Encryption has many other benefits including helping you meet compliance regulations (California CPA, etc.), helping you minimize reputational damage, helping you protect digital assets and business secrets, and much more. It is time to review your encryption strategy and plug any holes.

If you are a small organization you don’t have to feel left out in the cold. Here at Townsend Security we help small organizations get encryption and key management right. You are NOT priced out of the market. If you are a small organization ask us about our SMB plan.

Patrick

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

The Rise of Storage Area Networks

Nowadays, VMware vSAN provides hyper-converged storage for the enterprise business. As VMware puts it, “in addition to being incredibly simple to deploy and provision, Virtual SAN allows you to scale storage and compute resources, eliminating costly forklift upgrades.”

But, as most know, vSAN, first released in 2014, did not grow in a vacuum. Physical SANs started to gain traction in the early 2000’s as our need for data storage exploded. The SANS Institute, in 2002, highlighted these trends and the advantages that a SAN provided:

• Higher availability of systems and applications
• Costly IT purchases reduced
• Higher scalability of storage architecture
• Increased IT staff efficiency
• Higher ability to utilize the full value of a company’s information assets

But even though a SAN brought these advantages to its user, it had one major limitation: Storage administrators were still tied to managing the data via where it physically lived, needing to pre-allocate storage on various servers.

vSAN, however, overcomes the limitations of a purely physical SAN. Since vSAN is a software layer that sits on-top of the server, it allows for greater flexibility of your storage capacity. According to MicroAge:

“vSAN is software-defined storage that enables organizations to pool storage capabilities and automatically provision virtual machine storage. They can dynamically scale performance and storage capacity as needed and render underlying physical storage accessible to virtual machines through a policy-driven control pane. [O]rganizations use SANs to interconnect shared pools of storage devices to different servers. vSAN extends this local storage to a shareable storage in each server, enabling other servers to access data over the LAN without a traditional shared storage device.”

Another advantage of vSAN: greater (and much easier to implement) data security. With version 6.6 of vSAN, VMware introduced native encryption for your data-at-rest. vSAN encryption is baked right into vSAN and, as Jase McCarty of VMware puts it, “with a couple of clicks, it can be enabled or disabled for all items on the vSAN datastore, with no additional steps.”

This gives the enterprise business much greater control in how and when they secure their data. That said, let’s take a look at some additional advantages of using vSAN encryption.

The Advantages of vSAN Encryption

Minimizes Impact on Performance

With encryption there will always be a performance impact. It is just the nature of the beast. But with vSAN encryption, VMware reports:

• Minimal impact to CPU cycles while data is being encrypted.
• A 5-15% CPU penalty and no performance overhead. This overhead is representative of running vSAN with dedupe and compression turned on.

This is great news for those needing to encrypt large amounts of stored data. You can now protect your data and, in large part, maintain the integrity of your performance.

Streamlines Operations

As mentioned earlier, vSAN encryption is easy to configure and entire clusters can be encrypted with just a few clicks. There is zero guess-work with:

• No third-party encryption to install, configure, and maintain.
• No encryption at the hardware layer. Encryption at the hypervisor layer (vSAN encryption) has considerably less overhead than deploying encryption at the hardware layer.

Bring Your Own Key Manager

You can bring your preferred key manager to manage your encryption keys. Since vSAN encryption is KMIP 1.1 compatible, you are free to use a FIPS 140-2 compliant encryption key manager, like our Alliance Key Manager.

How Do I Enable vSAN Encryption?

The last and biggest advantage: vSAN encryption is easy to enable and use. This means that securing your sensitive data with AES encryption is not a time-intensive task. To prove the point, here is a quick guide to getting encryption up and running for your vSAN clusters:

• First, install and configure your key management server, or KMS, (such as our Alliance Key Manager) and add its network address and port information to the vCenter KMS Cluster.
• Then, you will need to set up a domain of trust between vCenter Server, your KMS, and your vSAN host.
• You will do this by exchanging administrative certificates between your KMS and vCenter Server to establish trust.
• Then, vCenter Server will pass the KMS connection data to the vSAN host.
• From there, the vSAN host will only request keys from that trusted KMS.
• The ESXi host generates internal keys to encrypt each disk, generating a new key for each disk. These are known as the data encryption keys, or DEKs.
• The vCenter Server then requests a key from the KMS. This key is used by the ESXi host as the key encryption key, or KEK.
• The ESXi host then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk.
• The KEK is safely stored separately from the data and DEK in the KMS.
• Additionally, the KMS also creates a host encryption key, or HEK, for encrypting core dumps. The HEK is managed within the KMS to ensure you can secure the core dump and manage who can access the data.

That’s it! VMware has made encrypting your data in vSAN both simple and secure.

Final Thoughts

Let’s face it, storage area networks are a target-rich environment for malicious actors. Whether it’s:

• Customer data
• Intellectual property
• Financial transactions
• Legal records
• Patient information
• And much, much more….

It all needs to be protected. Network administrators, though, face these challenges:

• They have little control over what gets put into storage.
• Sensitive data, many times, is stored by end users with little thought to encrypting it.
• There is a dizzying array of compliance regulations, internal security standards, and best practices that must be complied with.

vSAN encryption can help. With a few clicks in vSAN entire virtual disks can be encrypted. And with a FIPS 140-2 compliant encryption key manager, like Alliance Key Manager, the keys for your AES-NI encryption will be properly protected and full lifecycle managed.

If you are not protecting your data in vSAN, get started today! It’s not a matter of if your data will be hacked, but when.

You may be using VMware’s vSAN technology and not even know it. vSAN is the core technology in most of the Hyper-Converged Infrastructure (HCI) solutions on the market today. If you are running VMware for your on-premise or cloud infrastructure, you have vSAN at your fingertips. So, how can you leverage vSAN to meet compliance regulations and save money? Let’s take a deeper dive.

First, why is it important to encrypt our data?

Almost all compliance regulations require that you protect the sensitive information of your customers, employees, and service providers. This includes the California Consumer Privacy Act (CCPA), the Health Insurance Portability and Accountability Act (HIPAA), the EU General Data Protection Regulation (GDPR), the New York Department of Financial Services act (23 NYCRR 500), the Gramm Leach Bliley Act (GLBA), and many, many others. As we now know a major data breach that loses unprotected sensitive data will have severe impacts on any organization whether public or private. Encryption is now a core requirement of any security strategy, so how do we get there?

Can’t I use the native encryption facility in my database?

Almost all commercial and open source databases provide a path to using encryption that is built right into the database. Unfortunately, getting access to the encryption feature usually means upgrading to the Enterprise version of the database—and this can be an expensive proposition. This is true of Microsoft SQL Server, Oracle Database, MySQL, and many others. Of course, an upgrade to the Enterprise version usually gets you a lot more capability than encryption. An upgrade brings a lot of additional value, but the reality is that a database upgrade is beyond the budget of many small to midsize companies. So what can you do?

How can vSAN encryption help?

Beginning with version 6.6, VMware vSAN provides for built-in encryption support and a link to vSphere for proper encryption key management. By default, vSAN virtual disks are not encrypted. However, it is really easy to configure a vSphere KMS Cluster, deploy a key management server (KMS), and turn on vSAN encryption. You don’t need to reload your vSAN virtual disks and it is fast to deploy. With very little time and effort you can achieve encryption at rest for your database and other files.

To enable VMware vSAN encryption you only need a key management system that supports the OASIS standard Key Management Interoperability Protocol (KMIP). Our Alliance Key Manager fits the bill perfectly, and there are other solutions. You just deploy the key manager, grab the key manager certificate and private key, install them on your vCenter cluster, configure a KMS Cluster in vSphere, and enable encryption. Voila, you are done in a short period of time.

Do you know what else is cool? You can use the same KMS Cluster configuration to encrypt your VMs and to enable VMware vTPM in your virtual machines. That’s a lot of capability with very little time, effort and expense.

Is it risky to run my database in a vSAN volume?

The VMware vSAN facility is mature and now trusted by large and small Enterprises. As mentioned above, vSAN is a core component of almost all of the major Hyper-Converged Infrastructure (HCI) solutions. You may be using vSAN and not even be aware of it. There is also some good news—VMware has published a number of solution briefs and architecture guides to help you deploy Oracle Database, Microsoft SQL Server, and other databases directly on vSAN. Of course, you need to be aware of high availability requirements for both vSAN and for your KMS, but the existing vSAN documentation is quite good on this front. And deploying a high availability instance of our Alliance Key Manager solution is easy, too. More information here.

Today, you can confidently deploy your relational and NoSQL databases onto encrypted vSAN virtual disks safely and easily.

Saving money with vSAN encryption

We all live with constraints on our IT budget and our management team wants to see a good return on our IT investments. If you find that you don’t have the budget needed to upgrade your database for native encryption, deploying vSAN encryption is a great alternative. vSAN is a VMware facility that you already have and adding a key management solution is now very affordable. You can deploy our affordable Alliance Key Manager solution and avoid future upgrade and build-out costs. vSAN encryption and good key management is within the reach of every IT budget.

Ouch, I have vSAN but I don’t have a place to run a KMS

VMware vSAN is popular in many cloud and edge computing environments, but you might not be deploying VMs in that environment. Our key manager runs as a VMware virtual machine, so this can be a bit problematic in these environments. But there is an elegant solution to this—run the key manager in the cloud. For example, you can launch our Alliance Key Manager as an EC2 instance in AWS, or as a virtual machine in Azure, and use it to protect your vSAN volumes in edge environments. Alliance Key Manager works the same way in the cloud as it does as a VMware VM. And you can use one key management instance to serve multiple vSAN edge deployments. Problem solved!

Some precautions

There are some common sense precautions related to vSAN encryption. One is to be sure that you don’t deploy your KMS virtual machine onto a vSAN volume that it is protecting. If you have issues with the vSAN volume you don’t want it to impact the KMS, and vice versa. Also, as in all production environments where you deploy encryption and key management, be sure to deploy a failover key management server. It is easy to do with Alliance Key Manager and it will help you recover quickly and easily.

Alliance Key Manager for vSAN

Alliance Key Manager is certified by VMware for use with vSAN and vSphere encryption. All versions of vSAN and vSphere that support encryption are certified. In addition to VMware certification, Alliance Key Manager is validated to meet the PCI Data Security Standard (PCI-DSS), is KMIP compliant, and is FIPS 140-2 compliant. You can run Alliance Key Manager as a VMware virtual machine, as a cloud instance (Azure and AWS), in a Docker container, or as a hardware security module (HSM). No charge evaluations are available directly from the Townsend Security website, and we welcome partner inquiries. More information here.

In our practice here at Townsend Security we engage with a lot of startups and mature ISVs who are trying to grow their business and customer base, leverage their technologies into new opportunities, and grow or migrate to the cloud. We know how difficult it is to start and grow a company, and what a wide set of business challenges have to be overcome. Our hats are off to every entrepreneur who has created a successful company, and every ISV who has kept it going!

I want to share a few thoughts on some pitfalls that can damage your ability to grow your company with a focus on the encryption of sensitive data. Too many promising companies flounder because of poor security implementations, and failing to get encryption right can lead to lost opportunities - maybe even the loss of that breakout sale you need to land a global company. Some early thought and planning about data security can help you weather your migration up the food chain and avoid such losses.

Number 1: Failure to encrypt sensitive data

The single biggest failure of data security is not doing it at all. Even in this age of massive public data breaches, and the damage that they do to companies of all sizes, most startups and ISVs are not implementing encryption of sensitive data. When product managers and developers work on their next big idea, they focus on exciting features in their product and often ignore the work it takes to implement encryption. They instead rely on access control lists and other mechanisms to protect data. These are, of course, important things to do. But the failure to encrypt sensitive data leaves a big hole in your security strategy.

What can go wrong if you haven’t implemented encryption? LOTS !!!

• The publicity around a data breach can tarnish your reputation and kill opportunities.
• The lack of encryption may cause compliance regulation failures making it impossible to enter new markets.
• You may not be able to pass a security review of your software by that large global Enterprise.
• You may not be able to enter government channels where encryption is a mandate.
• If your customer experiences a data breach you may encounter substantial litigation costs that damage your financial resources and delay critical development.
• You may fail to secure that next round of funding when an investor discovers the security gaps in your product.

When these kinds of events damage your ability to grow your company, it can be hard to mitigate them in a timely fashion. And you often won’t know about these dangers until you get fairly far down the road with your business plan.

Number 2: Failure to get key management right

For startups and ISVs who DO understand the need for encryption of sensitive data, the next biggest pitfall is the failure to protect encryption keys properly. Almost every database that supports encryption also supports the ability to protect the database encryption keys with a key manager. But that doesn’t mean that good key management is the default! In most cases the default database key management option is to store the encryption keys on the same server as the sensitive data. Sometimes the database will even store the encryption key locally and in the clear! So getting encryption key management right is critical to your security strategy. It won’t help to have encryption of your data enabled, and then have a cybercriminal steal your data along with the encryption key.

Related to key management here are some things to look for when you consider databases for your application:

• Does your database have built-in encryption? Relying on third-party encryption solutions at the file/folder level will certainly cause deployment and scalability problems.
• Does your database support integration with third-party key managers? If there is no easy way to integrate proper key management into the database, this will also cause deployment and technology delays.
• Does your database support open standards for key management? For example, the Key Management Interoperability Protocol (KMIP) defines how applications like databases can easily integrate a key manager.
• Does your database support key management failover? Remember that protecting encryption keys with a key manager also brings along the question of high availability and failover.

HINT:

If you are a startup be sure to choose a database that supports built-in encryption and proper key management. You have lots of good choices in both commercial and open source solutions. So go with a database with native, built-in encryption and key management!

Number 3: Failure to get FIPS 140-2 right

There are important standards and certifications for key management solutions. The most important of these is the National Institute of Standards and Technology’s (NIST) FIPS 140-2 standard. In addition to being a published standard, there is also a validation process for key management systems. The standard, and the validation to that standard, are critically important to your data security strategy. All professional key management solutions have been validated to the FIPS 140-2 standard and you should be sure to deploy a validated key management solution. This will help you avoid failing a security audit by that important new customer!

In addition to ensuring that your key manager is validated to FIPS 140-2, be sure that the entire key management solution is validated. There are many cases where the encryption library alone is validated to FIPS 140-2, but the key management application is not. It is good to have validated encryption, but that is just the start! Encryption key management has its own validation points and you will need both.

Snake Oil Alert !!!

Unfortunately, there are some key management solutions that make unwarranted claims about FIPS 140-2 compliance and validation. Here are a few warning signs to look for when you evaluate a key management solution:

• A vendor makes compliance claims, but there is no validation. Some vendors claim to be “FIPS 140-2 compliant” but in fact have never completed a FIPS 140-2 validation. Security is hard, and unsubstantiated claims should be a red flag.
• A vendor claims FIPS 140-2 compliance, but the validation is “in process”, but not complete. A security product can be “in process” for many months or even years. A claim of FIPS 140-2 compliance without actual completion should also be a red flag.
• A vendor makes some claims of FIPS 140-2 validation, but research shows that the key management solution was not validated by that vendor.
• A vendor makes a claim of FIPS 140-2 compliance, but the solution is only compliant when backed by a third party validated key management solution. In this case the vendor solution itself is not validated, but relies on the validation of another solution. You may be fooled into thinking that the solution itself is compliant when it is not. Especially watch for this pitfall with open source solutions.

You can always check a vendor’s claims of FIPS 140-2 compliance. Ask for the NIST FIPS 140-2 certificate number, and then Google it. NIST makes the validation certificate available to the public on their website. Copy and paste this into Google search:

NIST FIPS 140-2 certificate number 1449

That was easy!

Number 4:  Failure to make encryption and key management easy and invisible

Now that you are on the road to getting encryption and key management right, it is important to also make it easy and invisible. Your customers have a lot on their agendas, and becoming a key management expert is probably not one of them. So even if you follow the above advice and implement encryption and key management, do your customers a favor and make key management easy. The best way to do this is to bundle a key management solution into your product, and make key management automatic. You can still enable the configuration of an external key management system (some customers will want this), but you can really make it easy for most of your customers if you automate the key management tasks.

Automating key management is a great competitive advantage! One of our partners in the archival and backup space implemented this strategy and make great competitive wins on this feature alone! Their message was simple:

“We have encryption and key management. It is FIPS 140-2 validated. It is completely automatic so you don’t have to spend time fiddling around with a complex key management system.”

This strategy won them a lot of competitive deals and it was easy to talk about - and it shortened the sales cycle.  Of course, be sure that your key management solution supports this type of integration and automation!

Number 5:  Failure to segment customer data

As you move to the cloud and create shared, multi-tenant SaaS solutions, be sure to plan for and architect data segmentation into your solution. You will encounter large customers who will not want to have their data in the same space as other customers. They will want the additional security of segmenting their data into a virtual private cloud. With planning, your technical team can meet this kind of requirement, and help you close that very large deal.

Of course, a data segmentation plan requires a key management segmentation plan. For the same reasons customers want to segment their data, they don’t want to share key management with other customers. And they want to maintain full control of the key management implementation. So be sure to plan for customer-specific deployments of encryption key management and failover key management servers. A properly implemented data and key management segmentation plan will even allow for on-premise deployments that are “cloud ready.”

Number 6:  Failure to develop new market opportunities

Think about Amazon (the company) for a moment. At one point in their history they were an online bookstore. Today the company is very different. Amazon first leveraged its technologies to sell all kinds of products, and then created Amazon Web Services (AWS) to enable all of us to benefit from cloud technologies.

Are you thinking like Amazon? If not, you might be missing some big opportunities. Now that you have secure applications, are there lateral opportunities or technology licensing opportunities available to you? When you approach new opportunities and partners, don’t be afraid to talk about security. Regardless of what you’ve heard:

SECURITY SELLS!

If you are new to encryption you might be asking yourself, "what is the difference between RSA encryption and AES encryption, and when should you use them?" It’s a great newbie question, so let’s go exploring.

AES stands for Advanced Encryption Standard and is in wide use around the world. It falls into a class of encryption methods called “symmetric” encryption. That is, the same secret (an encryption key) is used to encrypt the data, and also used to decrypt the data. AES encryption is probably the most widely used encryption method for protecting data at rest. You will find it used in self-encrypting disk drives, database encryption, storage encryption, and so forth. It’s been around since about 2002, and it is an international standard. Roughly speaking, when you encrypt with AES you put data and the secret encryption key into software that implements AES encryption, and out comes the encrypted data. When you want to use that data you put the encrypted data and the same encryption key into the software, and out comes the original data that you can use.

There are other symmetric key encryption algorithms, and we’ll discuss that a bit below.

RSA encryption is named after the three inventors of the encryption method: Ron Rivest, Adi Shamir, and Leonard Adleman. RSA falls into a class of encryption methods called “asymmetric” encryption. The name asymmetric follows from the fact that there are two related secrets, or keys, used for encryption. One is called a public key, and the other is called a private key. The keys are related in the sense that if you encrypt with the public key, you can only decrypt with the related private key. And the reverse is true, too - If you encrypt with the private key, you can only decrypt with the associated public key. The math is pretty amazing and involves very large prime numbers and factorization. RSA keys are usually used when you have two physically separate endpoints. RSA encryption is often used in web browsers to connect to your favorite websites, in VPN connections, and in many other applications. We use asymmetric encryption every day.

There are other asymmetric encryption algorithms, and we’ll mention a few later.

So, when do we use AES encryption?

AES encryption is great when we have a constrained environment. For example, if we encrypt data in a database, we will decrypt data when we need to access the database. Another example is hard drive encryption - we encrypt the data written to the disk, and decrypt it when we read from the disk. Encryption and decryption will take place on the same platform and in the same context. AES encryption is great for this particular use case. That is why it is commonly used for protecting data at rest.

When do we use RSA encryption?

RSA encryption is really great when we have two physically or geographically different end-points. If I am encrypting data in San Francisco, and you are decrypting it in Dubai, I am likely to use RSA encryption because it is ideal for two separate end-points. I can encrypt data with an RSA public key at the originating end-point, send it over an unsecure web connection, and decrypt it with the RSA private key at the destination end-point, and not worry about who might intercept it in the middle. The unique public / private key aspects of asymmetric encryption helps us be secure when we are separated by many miles of insecurity and hostile internet territory.

Performance and how this affects the use of RSA encryption

RSA encryption is great for protecting the transfer of data across geographic boundaries. But we have a bit of a problem with RSA encryption - it is really poor from a performance perspective. I might want to send you my sensitive file, but encrypting that with RSA is going to be difficult due to the low performance of RSA encryption. No problem! You can combine RSA encryption with AES symmetric encryption to achieve the security of RSA with the performance of AES. This is normally done by generating a temporary, or session, AES key and protecting it with RSA encryption.

Other symmetric algorithms

AES is not the only symmetric encryption method. The older, and still standard, Triple DES (Data Encryption Standard) method is still in wide use. Triple DES is an accepted standard even though it is older than AES. However, for any new applications you should avoid the use of TDES (also called TDEA) encryption and it is likely to be deprecated as a standard soon.  Other encryption algorithms exist, such as Two Fish, Blow Fish, Ghost, and others. While they may be good encryption algorithms, they have not achieved the status of accepted standards, and so you should avoid them.

Other asymmetric algorithms

RSA is the granddaddy of asymmetric algorithms. But is is not the only accepted standard for asymmetric encryption. Elliptic Curve Cryptography (ECC) is also in wide use (usually combined with a symmetric algorithm) and is an accepted standard for asymmetric encryption. It performs better than RSA, but still lags AES in terms of performance. You should feel comfortable using ECC for asymmetric encryption needs.

AES encryption and modes of encryption

While AES encryption is the most commonly adopted encryption method, you should be aware that there are multiple modes of operation that can be used with AES. These are also specified in the standards. The raw AES mode of operation is called Electronic Code Book, or ECB. Because raw AES in ECB mode can leak pattern information when encrypting large amounts of data, it is common to use a mode of encryption that incorporates an initialization vector. The Cipher Block Chaining (CBC) mode of AES encryption is very common, as is Counter (CTR) mode. For storage devices it is common to find the XTS mode of encryption used. If data corruption is of concern, you might find the Galois Counter Mode (GCM) in use.

The evolving world of encryption

The world of encryption is always evolving. Cryptographers are working on new algorithms and improvements to existing algorithms to meet the challenges of high performance computing and quantum computing. It is an exciting time for cryptography and encryption key management. For now, you should always stick to published standards like AES, RSA and others mentioned here. Doing so brings the benefits of a consensus among a world-wide group of cryptographers, and keeps you in alignment with many compliance regulations.

Please let me know if you have any questions.

Patrick

VMware allows customers to use native vSphere and vSAN encryption to protect VMware images and digital assets.  But as we know, to truly protect private data, encryption keys must also be properly stored and managed. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security, to talk about vSphere and vSAN encryption, deploying multiple, redundant key servers as a part of the KMS Cluster configuration for maximum resilience and high availability, as well as meeting compliance regulations and security best practices for your organization.  Additionally, we talked about Alliance Key Manager for VMware and how it is helping businesses protect their sensitive data.

VMware virtualization has been a game-changing technology for IT, providing efficiencies and capabilities that have previously been impossible for organizations constrained within a traditional IT data center world.

It is really great to see VMware, as a company, stepping up to embrace encryption for vSphere and vSAN.  Introduced in vSphere 6.5 and vSAN version 6.6, encryption allows users to protect data at rest. Additionally, there is a really great key management interface, which provides an excellent path to store and manage keys.  While these versions have been out for a while, many customers are just now getting around to upgrading and can take advantage of VMware's native encryption. With VMware, organizations are able to reduce hardware costs, lower operational cost, and provides a clear a path to move to the cloud. With the addition of encryption, you can deploy secure environments where there is less risk of data loss in the event of a breach.

Let’s dive in a little more and talk about vSphere and vSAN encryption.  Can you walk me through how an organization might deploy encryption and key management?

Sure. I think in a typical VMware environment, organizations are already doing some encryption in their applications.  For example, they may be running Microsoft SQL Server in a VM and using Transparent Data Encryption (TDE) to protect the data.  With the new facilities, you now get the ability to encrypt right in the VMware infrastructure itself. There is one thing that I think VMware did really well, and they have proven this over and over again, is that they have laid out a certification process for key management vendors, which gives VMware customers confidence that they are purchasing and deploying a solution that has been vetted by VMware themselves.  Our Alliance Key Manager, for example, has been certified for:

• vSphere encryption
• vSAN encryption

In terms of deploying key management, it is easy. We recommend using both a production key server and a failover key server. vSphere supports KMS cluster configurations which allow you to have a resilient encryption and key management architecture.  Aside from just being a security best practice, we are seeing our customers deploy two servers because they never want to lose access to their encrypted data. The servers synchronize in real-time and have automatic failover capabilities.

You can’t talk about key management without talking about compliance.  Whether it is PCI DSS, GDPR, or state and federal privacy laws, who doesn’t fall under compliance these days?

Yes, good question.  That is probably a very short list these days.  When you look at all the existing compliance regulations around the world, including the new GDPR, you realize that everyone falls under some compliance regulation, and most of us fall under multiple regulations.  Enterprises, big and small, public and private, fall under the same compliance regulations. Additionally, I have heard more from privately held companies that they think they are exempt - which is not true.

So you are correct.  Compliance regulations are driving a lot of uptake in encryption and I would say that lately GDPR is driving the most interest.  If you look at Article 32 and related recitals, the requirement to protect a data subjects information, there is a clear call for encryption. GDPR has put a new focus on the need to protect private data, as well as to take a broad view at what should be considered sensitive data.  It is not just a credit card number or social security number. Information like a phone number or email address can be considered sensitive data.

How is your Alliance Key Manager helping VMware users protect their private data?

Well, we have been helping VMware customers for a number of years  who are encrypting at the application level. Our Alliance Key Manager for VMware runs as a virtual software appliance and is binarily the same as our hardware security module (HSM). What is new, is that VMware opened the vSphere and vSAN and products to support encryption key management. Now VMware users can leverage the same key management solution for both application and VMware infrastructure encryption.

People often ask us, “How is your key manager different than your competitors”?  One thing that makes us stand out is that we are very diligent about meeting compliance requirements (PCI DSS, GDPR, HIPAA, etc.) and industry standards (FIPS 140-2, KMIP, etc.). Years ago, when we partnered with VMware, one of the first things we did was work with VMware and a QSA auditor to achieve a PCI compliance statement.  Customers can now be assured that when they deploy our Alliance Key Manager in VMware that they are meeting PCI compliance.

What else do VMware customers need to know about Alliance Key Manager for VMware?

Alliance Key Manager is a mature product that has been on the market for more than 10 years. It uses the same software that runs inside our Hardware Security Module (HSM), so customers can be confident that they are running exactly the same key management software that is FIPS 140-2 compliant and in use by over 3,000 customers worldwide.  Additionally, the security posture that the key manager allows, as well as the reference architecture that VMware provides, really gives VMware customers a road map to doing a secure installation.

The other thing that I think a lot of people might not realize is, that when they deploy Alliance Key Manager, they have our entire library of client side applications, SDKs, and sample code available to them.  For example, we have a Microsoft SQL Server TDE encryption component, support for MongoDB via KMIP, and sample SDKs for languages like Java, PHP, Python, etc. All of that comes along with the key manager and makes it easy to address security requirements.

Finally, I’d like to mention our partnership with VMware.  We are diligent about maintaining our certifications with Alliance Key Manager.  Doing this brings a level of confidence to the product for our customers. Prior to starting an encryption project they may be a little leery of key management because they have heard that it may be complicated.  That was true in the past. In fact, today it is actually extremely simple to deploy. Another barrier that we have knocked down is the scalability issue. Our solution works across multiple platforms - AWS, Azure, VMware or as an HSM.  They all talk to each other, and if one goes down, another will automatically fail over. That gives VMware customers the ability to be extremely flexible about how they deploy key management. It is not uncommon that our customers will deploy an application in the cloud, deploy a key manager in AWS, and then mirror those keys back to their on-premise VMware infrastructure. All of this is really straightforward and simple to deploy.

To hear this conversation in its entirety, download our podcast Protecting Data with vSphere & vSAN Encryption and hear Patrick Townsend further discuss protecting data in vSphere and vSAN with encryption and key management.

The IBM i DB2 database team implemented column level encryption through Field Procedures (FieldProc) in release 7.1 of the IBM i operating system. It was a great step forward for those IBM i customers who need to encrypt sensitive data to meet compliance regulations and to improve overall security. With release 7.1 it was now possible to implement DB2 encryption without modifying user applications.

Prior to this enhancement to DB2 in release 7.1, implementing encryption could be a laborious process of modifying applications and performing extensive regression testing. This approach did not work well with some types of fields (date, time, etc.) and many IBM and third-party query utilities just did not work correctly. So the DB2 enhancement for Field Procedures was a great step forward.

While FieldProc worked well with native SQL applications in release 7.1, there were limitations for older RPG and COBOL applications, and many IBM query utilities did not work correctly with encrypted indexes. Many IBM i customers use IBM and third-party query programs for rapid development of reports and displays of data. Some customers that I’ve talked to have thousands of queries in their application mix, so limitations of IBM query with FieldProc represented an insurmountable challenge for many. When FieldProc was used to encrypt an index or key field, queries just would not work correctly and data was missing or out of order in reports and displays.

But there is some good news!

Starting with the 7.2 release of the IBM i operating system, many of the IBM query applications were updated to work with the native DB2 SQL Query Engine (SQE) by default. The SQL Query Engine has never had a problem with encrypted indexes. This means that the IBM query applications now work seamlessly with data that is encrypted with FieldProc in DB2. You can fully deploy column level encryption across multiple index columns with FieldProc, and your queries will work fine.

Many IBM i customers experimented with FieldProc in the first release in version 7.1 of the operating system and decided to take a pass. If you had that experience it is time to take another look at DB2 FieldProc encryption. The current version of the IBM i operating system is 7.3 and most IBM i customers have upgraded to this release. You now have good support for IBM queries, the SQL Query Engine, and DB2 FieldProc encryption.

While some challenges remain for older OPM and ILE RPG applications, we’ve been able to help a number of customers meet these challenges.

Encryption of data is a core part of a defense-in-depth strategy. We have to do a lot of things to protect our IBM i data, and one of those things is to encrypt the data at rest with industry standard encryption algorithms. DB2 Field Procedures provides the path to achieving this.

To read more about IBM i support for SQL Query Engine in query applications such as RUNQRY, OPNQRYF, and others, see this link.

Our Alliance AES/400 Encryption solution provides full support for DB2 Field Procedures, is easy to deploy, and affordable for every IBM i customer. 

For industry standard encryption key management you can deploy our Alliance Key Manager solution which is seamlessly integrated with DB2 Field Procedure encryption.

Patrick