+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

Patrick Townsend

Recent Posts

California Consumer Privacy Act (CCPA) and Lawsuits

Posted by Patrick Townsend on Feb 10, 2020 10:39:44 AM

Well, that did not take long.

34 days after the California Consumer Privacy Act (CCPA) went into effect on January 1, 2020, a lawsuit was filed against retailer Hanna Andersson and cloud service provider Salesforce for a data breach where sensitive information was not properly protected. Information about approximately 10,000 California customers were exposed on the dark web. The information apparently included customer names, addresses, credit card numbers, CVV codes, and card expiration dates. Everything a cybercriminal needs to execute financial fraud. What a haul!

Encryption and Key Management for VMware - Definitive GuideThe fine under the CCPA can be up to $750 per record, making the liability cost in this case about $7.5 million - and that is only a part of the picture. Litigation costs will be large and there may be fines from the California Department of Justice and from other governmental entities. Hanna Andersson is a relatively small retailer with approximately 60 stores, 400 employees and annual revenue around $140M. Losses of this size are painful.

Here is a good article about the data breach, and it has a link to the actual lawsuit:

CCPA Cited in Hanna Andersson/Salesforce Breach Lawsuit 

Let me share a few thoughts with you.

First, let’s not forget that the villains in this case are the cybercriminals who perpetrated this crime against Hanna Andersson and Salesforce, and ultimately against the individuals who will experience identity theft and financial fraud. Could Hanna Andersson and Salesforce have done more to prevent this data breach? Certainly yes. But in the early years of my IT career I worked for companies like Hanna Andersson. I worked with wonderful, amazing, dedicated IT professionals and my sympathies are with them, too. Salesforce has been a moral leader in an industry that has seemed at times to lack a moral compass and I admire the values that Marc Benioff and his company have promoted over these last few years.

But this lawsuit is a harbinger of things to come. Ignoring the new landscape of regulatory compliance is dangerous.

Here are some takeaways that I hope will be helpful:

  • We are all moving our IT infrastructure to the cloud. The financial and operational benefits are overwhelming and this migration to the cloud will not change. However, we have not properly accepted responsibility for the security of our applications and data in the cloud. Our cloud service provider, whomever it is, will not protect us. Own and embrace your security posture now, no one else will do it for you.
  • The California Consumer Privacy Act puts the onus on businesses to protect consumer sensitive data. This may not be fair, but it is now a fact of life and other states will certainly follow California’s lead. The CCPA mandates that businesses protect consumer information with encryption if they want to avoid these types of lawsuits. That’s where we are, and that is what you need to do.
  • We have fully arrived in the land of Zero Trust. All of your systems in the cloud and on-premise are at risk. If you haven’t done an inventory of your systems with sensitive data, this is the first thing to do. Knowing where sensitive data resides provides you with a map to address adding the protections that are needed.
  • Prioritize the systems based on risk. Which systems have the most sensitive data? Which are more exposed to a data breach? Which databases will be the easiest to mitigate? The prioritized list does not have to be perfect, but you need one as soon as possible.
  • Get started with your encryption projects. Some databases make this easy to do. If you have Microsoft SQL Server, MongoDB, or MySQL, you have a clear and fast path to add encryption through native database support. If you have databases or storage that do not support native encryption, consider migrating them to VMware vSAN encrypted storage for these applications. 
  • On your way to encrypting your sensitive data, don’t forget about encryption key management. One of the changes that came with CCPA is the requirement to store encryption keys away from the sensitive data. Most databases give you the option of storing the encryption key on the same server as the data. Don’t do this, you will lose all of the protections you need under CCPA.

Here at Townsend Security we help organizations large and small achieve the highest level of data protection. It won’t cost you an arm and a leg, either. The days of overpriced encryption and key management solutions are over. Talk to us about our Alliance Key Manager solution for protecting your data.

Patrick

New call-to-action

Topics: CCPA

AWS and Key Management and Pricing

Posted by Patrick Townsend on Feb 4, 2020 8:42:06 AM

Ahhhh, Amazon Web Services (AWS) are so delightfully inexpensive, aren’t they? The AWS Key Management Service (KMS) is one of those really inexpensive services that many of us love to use. For many AWS customers AWS KMS isn’t even noticeable on your bill.

Or, is it?

New call-to-actionAs we start to deploy data in the cloud we start to use more encryption keys. The first project might use one or two keys, and that cost is not even noticeable. What happens as you start to deploy more and more projects to the AWS cloud? Or, you adopt a strategy of assigning each user in your database their own key (a great strategy to deal with GDPR and CCPA)? The number of keys can start to go up quickly, and your AWS KMS cost goes up with them.

Here is something that happened to one of our customers who had a growing need for keys:

They decided to use a separate encryption key for each of their customers. The idea was to encrypt with an encryption key unique to each customer. When they needed to delete the customer data they only needed to delete the encryption key for that customer. With lots of customers they soon had thousands of encryption keys. And they were shocked when a really large Amazon bill came due for those keys. AWS charges $1.00 for each key and it adds up really fast. So some caution is in order.

Is there any way to avoid the high cost of AWS KMS for multiple keys?

Yes there is. Our Alliance Key Manager in AWS solution can be deployed right in the AWS cloud at a low monthly cost, with no charge per encryption key. Whether you need 10 encryption keys, or 100,000 encryption keys, the cost is the same. And we don’t count the number of endpoints, either. So, the cost remains the same even as you increase your data protection.

Besides a lower cost for key management, there are other benefits to deploying our key manager in AWS:

  • You have exclusive access to the key manager – unlike AWS KMS, it isn’t shared with Amazon (or us).
  • You can deploy redundant key managers (product and high availability) across different AWS geographic regions.
  • You can mirror your encryption keys from AWS to an on-premise key manager.
  • You can deploy replicating key managers across multiple clouds.
  • You have full support for encryption of databases like SQL Server, MySQL, MongoDB, and others.

When you need a lot of encryption keys in AWS, our Alliance Key Manager is a winner. We don’t charge per key, you have flexible options to deploy key management in the cloud and on premises, you will save a lot of money over AWS KMS, and you will have a dedicated Enterprise key management solution that you don’t share with anyone. You will be deploying a true cloud neutral key management solution.

Talk to us to find out more details about the benefits of deploying Alliance Key Manager for AWS for your organization.

Patrick

Encryption Key Management for AWS

Topics: Amazon Web Services (AWS)

California Consumer Privacy Act (CCPA) and Encryption Key Management

Posted by Patrick Townsend on Jan 31, 2020 9:46:06 AM

In October of 2019 I blogged about the California Consumer Privacy Act (CCPA) and its impacts on businesses. I knew that a lot of businesses were aware of the CCPA coming into effect on January 1, 2020, but I thought that there was a lot of misinformation and confusion about the CCPA. In that blog I laid out a number of facts about CCPA and some suggestions on actions you can take. I also noted that the law was very likely to get an update by the end of the year. You can find that original blog here:

California Consumer Privacy Act (CCPA) - Things You Need To Know

Podcast: CCPA - What You Need to KnowWell, that update to CCPA and related notification laws has happened. Several new laws were enacted in December 2019 that clarify and modify the CCPA. While the broad requirements of CCPA remain intact, there were some changes that bear noting.

One important change relates to encryption key management and breach notification. Let’s do a deeper dive.

First, it is important to note the role that encryption of sensitive information plays in CCPA. Among other things, the CCPA dramatically empowers consumers to recover damages after a data breach of unencrypted data, and limits the ability of businesses to inhibit that recovery. Here are a few aspects of CCPA law:

  • Businesses are not allowed to limit the ability of consumers to seek recovery. The widely used practice of liability limitation, arbitration clauses, and so forth are prohibited.
  • The California Department of Justice can levy steep fines on businesses that suffer a data breach and who have not adequately protected sensitive data.
  • Consumers are empowered to bring class action lawsuits around a data breach to recover damages. This kind of litigation is specifically enabled by the CCPA and should scare covered businesses.
  • However, class action lawsuits are only allowed with the loss of unencrypted sensitive data. Encryption is your friend!

So, what is different with the new laws?

AB1130 is one of those recent bills that modifies the CCPA notification requirements. It retains the litigation protections provided by encryption, but further clarifies that encryption keys must be properly protected. Here is what AB1130 says about breach notification (extracted and highlight added):

SECTION 1. Section 1798.29 of the Civil Code is amended to read:

1798.29. (a) Any agency that owns or licenses computerized data that includes personal information shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California (1) whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person, or, (2) whose encrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person and the encryption key or security credential was, or is reasonably believed to have been, acquired by an unauthorized person and the agency that owns or licenses the encrypted information has a reasonable belief that the encryption key or security credential could render that personal information readable or usable. The disclosure shall be made in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement, as provided in subdivision (c), or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system.

The full text of AB1130 is here:

https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201920200AB1130

Security professionals know that encryption is only as good as the protection you provide to the encryption key. The CCPA notification rules now embed that understanding right in the law. And you must understand what this means in terms of your litigation protections.

Let’s take one example:

Microsoft SQL Server is a widely used database for business information. SQL Server implements Transparent Data Encryption (TDE) to protect all data in the database. And it gives you two options for storing encryption keys:

  • Local storage of the key on the same server as the database.
  • Remote storage of the key by integrating with a professional key management system.

A lot of Microsoft SQL Server customers store the key locally on the same server as the database. Why? Well, it is easy and free. 

Here is the problem:

It is trivially easy for a cybercriminal to recover a locally stored encryption key if they have access to the server or a backup of the server. In fact, there are ready made programs that will just recover the key for the hacker and unlock the encrypted data, in just a few seconds. This is a prime example of where poor encryption key management will damage your ability to limit notification and liability under CCPA. Don’t expect to argue that the key was properly protected. Every security professional knows how poorly protected a locally stored key is.

Is there a way to mitigate this poor encryption key strategy?

Yes. 

Microsoft SQL server also supports remote encryption key management systems through a special interface known as Extensible Key Management, or EKM. You don’t have to store the key locally - you can easily plug in a key management system and protect the encryption key properly as the CCPA recommends. Problem solved, from a CCPA perspective. Our own Alliance Key Manager supports remote key management through the EKM interface.

Here are a few takeaways:

  • Under the CCPA, encryption is a critical part of your compliance strategy, and your strategy to limit liability after a data breach. It is hard to overstate the importance of encryption.
  • When you do encryption, you have to manage the keys properly. Use a professional key management system like our affordable Alliance Key Manager to accomplish this. Alliance Key Manager is NIST FIPS 140-2 compliant which is the gold standard for key management certification.
  • If you are currently storing the key locally, it is easy to move to a proper key management system. It usually just takes a few minutes.
  • There is no such thing as a good, secure method to store keys locally with your data. Just don’t do it.
  • Key management systems are now affordable and easy to deploy. We can prove it!

The California Consumer Privacy Act and subsequent laws change everything in terms of how we process and protect sensitive data. Encrypting that sensitive data, and protecting the encryption key, is not hard and is within reach of every business. 

Talk to us. We’ll show you how fast and easy it is to meet this part of the new CCPA and notification regulations.

Patrick

P.S. I don’t mean to pick on Microsoft SQL Server here. The same issue applies to almost every commercial and open source relational and NoSQL database! 

Podcast: CCPA - What You Need to Know

Topics: Encryption Key Management, CCPA

Ransomware and Encryption - I Was Wrong

Posted by Patrick Townsend on Jan 2, 2020 8:48:08 AM

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

eBook: Definitive Guide to Encryption Key ManagementIn 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

eBook: Definitive Guide to Encryption Key Management

 

Topics: Encryption, Ransomware

California Consumer Privacy Act (CCPA) - Things You Need to Know

Posted by Patrick Townsend on Oct 17, 2019 4:00:44 PM

California Consumer Privacy ActThe new California Consumer Privacy Act (CCPA) is a really big deal. Almost no one is ready for it, so you are not alone if you are just getting familiar with the CCPA requirements. Let’s dig into it and try to translate the law (California AB 375 and related statutes) into understandable language. I will also make some recommendations on things you can do right now to get started.

Some history might help

The law itself (AB 375) passed in June of 2018 is a pretty easy read. Interestingly, it directly points to the social and political factors that lead to the creation of the law. The increasing number of data breaches and the Cambridge Analytica scandal are specifically mentioned in the law - but if the law seems a bit rushed and incomplete, that’s because it is!

California is one of those states that make it relatively easy for citizens to gather signatures and put initiatives directly to the people. In early 2018 that is exactly what happened. An initiative related to consumer privacy gathered enough signatures to make it on the California ballot and this proposed new law frightened the technology companies located both in California and outside of the state.

In response to the initiative, the California legislators struck a deal with the initiative proponents. If the legislature could pass a strict new consumer privacy law in short order, the initiative proponents agreed not to put the initiative on the ballot - and that is what happened. Probably breaking speed records for such legislation, the California legislature created the new law in just a few days, and the governor signed it. The initiative was not placed on the ballot.

The speed of the passage of the law had one unfortunate side-effect: There is a lot of ambiguity in the law. You are going to be scratching your head about some of the requirements and definitions in the law. What is missing or undefined is almost as significant as what is in the law. The law goes into effect on January 1, 2020 but the legislature has promised to provide additional guidance in the Fall of 2019, and new clarifying law by June of 2020. More on this below.

The CCPA law, where to find it.

Podcast: CCPA - What You Need to KnowReading regulations will usually make your eyes roll back in your head. In this case the California law is a pretty easy read. I highly recommend that you do this. I read several summaries of the law in business and technology journals, but learned some important facts when I subsequently read the law directly. Here is the link (there is a PDF version available for download).

Just remember my previous comment about future clarifications of the law. There will be changes and I will try to keep you up to date. You should also check the CCPA website for updates.

Is my Organization required to meet the law? 

If you collect data on people who are in California, and meet the minimum criteria (see below), and are not explicitly excluded, you must meet the requirements of the new law. Notice that I did not say “California citizen”, but people who are in the state at the time of data collection. You are not exempt if your organization resides outside of California. If you collect data on people in California, assume you are covered by the law.

If you meet any of these criteria, you are required to meet the new CCPA law:

  • You have $25 Million or more in annual revenue
  • You collect information on 50,000 or more people
  • You derive 50 percent or more of your revenue selling personal information to third parties 

The law applies to both public and private organizations. I often hear people tell me that they are not covered by regulations because their company is “private.” Don’t make this mistake. Being a private organization does not exempt you from the new California law.

There are some exclusions in the law: If your organization is already covered by equivalent privacy regulations such as HIPAA, GLBA, and others, you may be exempt. Don’t be fooled into a sense of complacency about this. The CCPA has privacy regulations that are not covered under those laws. If you think you are exempt, I would highly recommend that you get legal advice on this point.

When does it take effect?

The law takes effect on January 1, 2020. Here are some important points to consider:

  • The law covers data collected for the previous 12 months (from January 1, 2019).
  • There will be clarifying guidance in the Fall of 2019.
  • The law is likely to be amended for clarification by June of 2020, but it is not likely to be less restrictive.
  • The law covers a much broader set of information than any other regulations, including GDPR.

I’ve heard people say that they are not worried because they meet GDPR requirements. That is a big mistake. There is certainly some overlap with GDPR, but some of the CCPA requirements are different and much broader. For example, what is considered “personal information” includes more and different information than GDPR.

What rights are granted to consumers?

Here is a short list of the rights granted to consumers under the new law (please read the law directly):

  • The right to opt-in to data sharing BEFORE you collect and share the information, and the right to opt-out of data sharing at any time. The option to opt-out of data sharing must be respected for 12 months, and subsequently there must be an explicit opt-in process before sharing.
  • The right to opt-out of data sharing using a web page or phone number (other methods may be added to these).
  • The right to a clear privacy statement on your website that specifically addresses the CCPA.
  • The right to know the intended uses of the information that is collected.
  • The right to know the categories of information you collect.
  • The right to know the specific information you collect.
  • The right to know the sources of the information that you collect (websites, third parties, etc.).
  • The right to know to whom you sell or share information.
  • The right to receive a copy of the information you collect in a user friendly format.
  • The right to have you delete their information.
  • The right to deletion of their information from any third party service providers with whom you shared the data.
  • The right to non-discrimination in terms of your services if they opt-out.
  • The individual and class action right to sue if sensitive data is lost and is not encrypted, and for other reasons (please read about encryption below).

You have 45 days to respond to a consumer’s request. With proper notice this can be extended another 45 days (90 days in total).

Try to make a sincere effort to understand the nature and intent of these requirements. The law is written to address those who try to be “cute” about meeting the requirements, and the penalties go way up for intentional avoidance of the requirements.

Note that you have the obligation to verify the identity of the consumer who is exercising these rights. Unfortunately, there is not enough guidance on the proper ways to do this. Be aware, however, that you cannot use any information provided by the consumer that is a part of the privacy request for any other purposes! 

What information does it cover?

The personal information covered by the CCPA is quite broad and extends into areas not covered under GDPR and other regulations. The current definition of sensitive consumer data includes:

  • Identifiers such as a real name, alias, postal address, unique personal identifier, online identifier IP address, email address, account name, Social Security number, driver’s license number, passport number, or other similar identifiers.
  • Personal and commercial behaviors, and inferences from them.
  • Characteristics of protected classifications under California or federal law
  • Commercial information including records of personal property, products or services purchased, obtained or considered, or other purchasing or consuming histories or tendencies
  • Biometric information
  • Internet or other electronic network activity information including, but not limited to, browsing history, search history and information regarding a consumer’s interaction with a website, application or advertisement
  • Geolocation data
  • Audio, electronic, visual, thermal, olfactory or similar information
  • Professional or employment-related information
  • Education information, defined as information that is not publicly available personally identifiable information (PII) as defined in the Family Educational Rights and Privacy Act (20 U.S.C. section 1232g, 34 C.F.R. Part 99)
  • Inferences drawn from any of the information identified in this subdivision to create a profile about a consumer reflecting the consumer’s preferences, characteristics, psychological trends, preferences, predispositions, behavior, attitudes, intelligence, abilities and aptitudes.

 This is an amazing list of data items that goes far beyond what we see in other regulations. Many companies have done a lot of work using Artificial Intelligence and Machine Learning to make inferences about consumer behavior. I hope you are not missing the fact that this type of inferential and derived data is covered under the CCPA!

What are the penalties?

The potential penalties fall into two categories: Those imposed by the California Attorney General, and those imposed by newly enabled consumer litigation.

First, let’s look at the penalties that can be assessed by the AG. The penalty range starts at $2,500 per violation. Many people think this amount is for each record that is lost or in non-compliance. It is easy to see that this could expensive very quickly. However, if the AG finds that you are “intentionally” in violation of the CCPA the penalty increases to $7,500 per record. One way to trigger this level of penalty is to ignore a formal notice by the AG that you are in violation of the CCPA. Never ignore this type of notification! The higher level of penalty can trigger an existential crisis for many companies.

The second area of penalty relates to newly enabled litigation by individuals. Under the CCPA individuals have a right to bring direct legal action against an organization. This includes the ability to bring a class action against a company. Other than fully meeting the privacy requirements of the CCPA there is no way to limit your exposure to this type of litigation. The CCPA explicitly prohibits the use of arbitration clauses and other means of contractually reducing your exposure. You have to be notified about an impending action, and you have 30 days to correct the action and respond.

These two areas of exposure should motivate you to get a plan in place to fully meet the CCPA privacy requirements, and start executing on the plan. Time is short. 

Am I required to encrypt sensitive data? 

If you want to avoid the risk of direct or class action litigation related to data loss you should encrypt the sensitive data. Individual and class action litigation only applies to unencrypted sensitive data that is disclosed or lost, for whatever reason. The CCPA is clear on the need for encryption. If you lose unencrypted sensitive data this is direct evidence that you violated your duty to provide reasonable security procedures and practices to protect the sensitive information. See section 1798.150(a)(1). 

Most modern relational and Big Data databases provide an easy path to encryption. Find where your sensitive data is stored, prioritize an encryption strategy, and move it forward. This effort may require an upgrade to your database systems to a version that supports encryption. Understand the budget requirements and add the costs for encryption key management.

What should I do now? 

Although there will be additional guidance in late 2019, and there will likely be clarifying legislation in early 2020, you should not wait to get started. There are a lot of things you will need to do to meet the CCPA privacy regulations. Here is a short list that should help you get started. There is more to do, but these will be critical steps:

  • Identify and document all of the sensitive information that you collect or derive from interpretations of the data. Document the sources of this data, how you collect it, the individual items, and then classify the data.  Pay special attention to the categories of data outlined above. In addition to your internal IT systems be sure to include your hosted and cloud applications, and your web-based SaaS systems.
  • Identify all of the third parties with whom you share information. Be sure to document exactly what information is shared.
  • Review your website to ensure you meet the explicit requirements of the CCPA. You will need to update your privacy statement per the CCPA requirements. 
  • Institute processes for handling consumer privacy requests. This will probably require new IT reporting applications as well as human processes for responding to requests. Be sure to keep an audit log of all requests from consumers, and your response.
  • For all service providers who receive information that you share, review your service agreements. Revise those agreements to bind the service provider to the new CCPA regulations. If service providers resist new contract terms, or are non-responsive, have a plan to replace those service providers. Since many service contracts renew on an annual basis, start this process now.
  • Encrypt the data and use good encryption key management. Your only safe-harbor from litigation in the event of a data loss is encryption. The time to get started is right now.

 Disclaimer

 Nothing in this article constitutes legal advice in any way. Consult with a qualified attorney for any legal questions or advice. The new California Consumer Privacy Act will have new guidance before the activation date of January 1, 2020 and is likely to be modified by additional legislation. Please refer to the official California state website for more information. 

Podcast: CCPA - What You Need to Know

Topics: Compliance, CCPA

Saving Money with VMware vSAN Encryption

Posted by Patrick Townsend on Oct 16, 2019 7:30:02 AM

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?

Encryption and Key Management for VMware - Definitive GuideAlmost 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?

VMware-vSAN-Encryption

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.

New call-to-action

Topics: Encryption, VMware, vSAN

Are Encryption and Key Management Critical to Blockchain and DLT?

Posted by Patrick Townsend on Sep 16, 2019 6:51:24 AM

As blockchain technologies make their way towards general acceptance in private and public sector IT systems, the critical issues of governance, risk management and compliance come into play - and blockchain teams are maturing to address these areas. One important gap to fill involves the proper protection of sensitive data in a blockchain deployment. It seems odd to discuss data protection in the context of blockchain. Isn’t blockchain based on cryptography? Yes, it is, but there remains a gap in the area of data protection. Let’s delve into this in more detail.

What Data Needs to be Encrypted in the Blockchain Ledger?Blockchain’s innovative way of linking transactions and guaranteeing their immutability in a distributed ledger is based on well known and respected cryptographic algorithms and processes. The ability to extend this level of assurance across a large number of widely distributed nodes is clearly an amazing extension of modern computing. While there have been security lapses in public blockchain implementations, these have generally been related to improperly securing credentials and mistakes in implementing chaincode. Blockchain methodologies are standing up well to external attacks.

One important aspect of blockchain is its transparency. That is, everyone has perfect visibility into the transactions on a ledger and their current validity. This transparency is a core feature of blockchain - and that leads to a problem:

Some data that we want to put on the blockchain is sensitive, and we may not want to expose it to others.

There are lots of reasons why we might not want some information on the blockchain ledger to be transparent:

  • An organization’s reputation suffers when they lose or expose sensitive information. This is true for both public and private organizations and a significant loss of reputation is difficult to mitigate.
  • Even little bits of data in blockchain transactions needs to be protected. When sensitive data in a blockchain ledger are aggregated, it can indicate the direction of a business’s activity and leak important information about strategic developments to it competitors.
  • Compliance regulations prevent storing sensitive personal information in the clear. The PCI Data Security Standard mandates that credit card (Primary Account Numbers) be encrypted. The New York Department of Financial Services (23 NYCRR 500) requires the encryption of certain sensitive information. The EU General Data Protection Regulation (GDPR) mandates the protection of sensitive information of “Data Subjects”. here are other regulations that require or recommend protection of sensitive data.
  • Digital assets that represent intellectual property need to be protected from cybercriminals and state actors. The loss of key intellectual property can be devastating to a startup or mature enterprise.

Therefore, it is critical for organizations to design proper data privacy into blockchain projects from the very beginning. It is painful and potentially impossible to fix data privacy gaffs after the fact.

Blockchain SecuritySome blockchain advocates suggest that the solution to this conundrum is to not place sensitive information on the blockchain at all. But this is an impossible goal. Data on a blockchain may not specifically identify an individual, but may contain enough information that it can be combined with previously leaked information to form a full picture of an individual. Remember that hackers are really good at data aggregation. Losing a little sensitive information can lead to an embarrassing loss of a lot of information.

Other blockchain advocates suggest that the answer to this problem is to store sensitive data off of the blockchain altogether. But does this really solve any problem? This approach loses the many advantages of blockchain technology, and doesn’t do anything to solve the data protection puzzle. “Out of sight, out of mind” is not a solution to any problem.

Some blockchain implementations attempt to achieve privacy through “add on” features. Hyperledger channels and collections are two examples of this. These facilities use access controls to attempt to achieve this. As good as these facilities are, access controls will not address the data protection requirements of compliance regulations, nor provide other protections that encryption provides.

For all of the reasons we encrypt sensitive data in traditional databases, we need to encrypt sensitive data on a blockchain. This doesn’t mean that we have to encrypt everything that we put on the blockchain ledger, but it means we have to have the same intelligence in regard to sensitive data on blockchains that we have in the most secure systems today.

Fortunately, we can accomplish data protection on blockchains and maintain their usefulness. In fact, not only CAN we accomplish this, we MUST accomplish this in order to preserve the usefulness of blockchain technology.

If we are going to encrypt data that we put on a blockchain, we have to address a few requirements that are specific to blockchains:

  • We have to use industry standard encryption algorithms, such as AES, to meet compliance regulations.
  • We have to manage encryption keys using industry standards and best practices. This means storing encryption keys away from the blockchain ledger and doing so in a provably standard and secure way.
  • We have to make encryption keys available to the users and smart contracts that need them. This is a challenge in a distributed blockchain environment.
  • We must authenticate user’s authority to use encryption keys.
  • We must have a mechanism for restricting access to encryption keys, and for granting and revoking access to those keys.
  • We know how to accomplish these tasks in a traditional, centralized IT system. Years of work have produced standardized approaches to encryption. But blockchain presents real challenges to meeting these challenges.

Fortunately, innovation in the area of protecting data on a blockchain ledger is advancing.

At BlockNKey we built a key orchestration system architected from the ground up for distributed ledger technology. NIST compliant encryption and key management, a key vault, and key access control are built into each registered blockchain node. Cryptographic keys grant permission to whomever is permitted access to the data, how it’s accessed and when it’s accessible. This enables multi-party access to the appropriate data in real time through verified and validated access points. BlockNKey is compatible with public and private blockchains while enabling proper data security with easy to use REST APIs. It will even help you if you are storing sensitive data “off chain”.

Townsend Security has partnered with BlockNKey to bring an encryption and key management solution to blockchain users. More information here.

What Data Needs to be Encrypted in the Blockchain Ledger?

Topics: Blockchain

VMware vSAN Encryption for Compliance

Posted by Patrick Townsend on Aug 30, 2019 9:06:56 AM

Many VMware customers know that they can encrypt their virtual machines that are managed with vSphere and other VMware tools. VMware vSAN encryption can also provide important protections for data-at-rest in vSAN virtual disks. I wanted to share some thoughts I’ve received from our VMware customers and partners on some of the benefits of using vSAN storage with encryption enabled.

VMware-vSAN-Encryption-Flowchart

A Simple Way to Encrypt

Podcast: Protecting Data with vSphere & vSAN EncryptionWhen you have a large database, it can be inefficient to store the data in a directory or folder directly in your virtual machine. vSAN can be much easier to manage from an administrative and recovery point of view and your VMware applications can easily connect to the vSAN volume. vSAN is configured using the VMware tools you already know how to use and managing vSAN storage is easy.

Did you know that you can enable vSAN encryption to protect that database with sensitive data? You can enable vSAN encryption on existing virtual disks or on new virtual disks that you create. The process is simple and does not require any downtime for your application - and vSAN encryption enables the use of a KMIP compatible key manager like our Alliance Key Manager so that you stay lined up with industry standards and security best practices. It is an easy way to improve your overall security posture.

A Simple Way to Meet Compliance

Many of our VMware customers are struggling to implement encryption on their databases to meet compliance regulations and to protect the organization’s digital assets. Although encryption and key management have become much easier over the years, it can still seem like a daunting task. VMware vSAN encryption to the rescue! It is easy to implement with the tools you already have, and you can deploy an affordable key management solution such as our Alliance Key Manager to fully meet compliance requirements and security best practices. You configure key management directly through the KMS Cluster facility in vSphere, and then activate vSAN encryption. Alliance Key Manager does not impose any limits on the number of virtual disks you protect, nor on the number of nodes that connect to the key manager.

A Simple Way to Save Money

Some databases, such as Oracle and Microsoft SQL Server, require expensive license upgrades to enable encryption capabilities. This cost can be out of reach for many small to medium size organizations. Using vSAN encryption is an affordable way to achieve a better security posture using the tools and the IT professionals you already have.

You might be wondering if VMware supports the deployment of these databases on vSAN volumes. The answer is absolutely YES! You will find substantial documentation from VMware on doing exactly this. The documentation includes reference architectures and analysis of performance impacts. You can confidently move forward with vSAN encryption knowing that VMware has invested time and effort to make sure you are successful.

Lastly, we know that some VMware users have deployed the free version of vSphere. There are some costs associated with upgrading to the paid tier of vSphere in order to get the ability to encrypt VMs and vSAN. If this is where you are today, talk to us about how we can help with the uplift to the next level of vSphere capability.

Resources:
vSAN Documentation
Oracle Database on VMware vSAN Solution Overview
Architecting Microsoft SQL Server on VMware vSphere
Pointers to our AKM for vSphere/vSAN Solution Brief 

New call-to-action

Topics: Compliance, VMware, Enryption, vSAN

VMWare and Encryption Key Management Failover

Posted by Patrick Townsend on Jun 26, 2019 12:38:09 PM

Encryption and Key Management for VMware - Definitive GuideOne of the easiest ways to implement encryption controls in your VMware infrastructure is to activate vSphere and vSAN encryption. With vSphere VM encryption you can insure that all VM images are encrypted at rest, and with vSAN encryption you can set up virtual disks that are fully encrypted protecting any files that you place there. vSphere encryption was implemented in version 6.5, and vSAN encryption was implemented in version 6.6. All subsequent versions of vSphere and vSAN include these capabilities. (Note that you must be on the Enterprise or Platinum edition).

vSphere-VM-Encryption and vSAN-Encryption

In both vSphere and vSAN the key manager is integrated using the open standard Key Management Interoperability Protocol, or KMIP. This means that any key management solution that supports the necessary KMIP interface can work as a vSphere or vSAN key manager. Our Alliance Key Manager solution implements this support, and is already in use by our VMware customers. 

The most common question we get about these new encryption features is: How do I manage failover for the key managers?

This is a great question as VMware is a part of your critical infrastructure, and key management has to work with your high availability strategy. There are two parts to this question and lets dig into both of them:

Defining Key Managers to vSphere KMS Cluster

Key managers are defined to vSphere using the option to configure the KMS Cluster. A KMS Cluster configuration allows you to define more than one key manager. So you have a readily available path for failover. The first key manager configuration is the primary key manager, and all subsequent key managers in the KMS Cluster are failover key managers. vSphere will always use the first key manager you define and treat it as the primary. 

In the event vSphere cannot connect to the primary key manager, it will try to connect to the second key manager in the KMS Cluster configuration. If that one fails it will try the third one, and so forth. The failover order is the order in which you define key managers in the KMS Cluster, so you should keep that in mind as you define the key managers.

While vSphere allows you to create multiple KMS Cluster definitions, very few VMware customers need multiple definitions. Just put your key manager definitions in a single KMS Cluster and you are set to go. 

If you have failover clusters for VMware, be sure to define the KMS Cluster for the failover environment, too!

Implementing Key Mirroring in Alliance Key Manager

Now that you have failover key managers defined to the KMS Cluster, you need to activate key mirroring between the primary key manager and each failover key manager. This is really easy to do, and you don’t need any third party products to implement key mirroring with Alliance Key Manager. Real time, active-active key mirroring is built right into the solution. You can SSH into the key manager, provide credentials, and then take the menu option to set up the primary or secondary key server. Answer a few questions and you will have key mirroring enabled between two or more Alliance Key Manager servers.

Our Alliance Key Manager solution implements full support for vSphere and vSAN encryption key management and has everything you need to get started. Adding encryption to your VMware environment is easy. VMware did a great job with this implementation of key management support and you can easily realize the benefits of protecting VMware infrastructure.

Alliance Key Manager documentation for vSphere can be found here.

You can download Alliance Key Manager and get started right away. Here is where to go to start the process.

Townsend Security will help you get started with vSphere and vSAN encryption. There is no charge for the evaluation or evaluation licenses and you will get access to the Townsend Security support team to ensure you have a successful project.

Patrick

New call-to-action

Topics: Alliance Key Manager, VMware

Encryption and Key Management - The SIX Mistakes that Startups and ISVs Make and How To Avoid Them

Posted by Patrick Townsend on Apr 18, 2019 1:27:59 PM

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!

Designing Applications with Encryption and Key ManagementI 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!

Developing Applications with Encryption & Key Management

Topics: Encryption, Encryption Key Management, ISV, Partner

Blog-CTA-VMware-CSP
 
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