March 2, 2024

Secure by Default – Why did it take something like GDPR to do this?

I look at Twitter, and see everyone talking about the massive amounts of emails surrounding the changes companies are having to make as a result of GDPR. What is GDPR? Well if you like to read legislation, you can start here:

That’s a lot of info and legalese.

One of the things that I took from reading the GDPR legislation, was that data needs to be secure by default. Data doesn’t need to be secured after the fact, but by default.

An experience with data security
Here is an experience I had about a year ago, and why I think “secure by default” is tremendously important.

I went to an auction looking for whatever deals I could find. Tech, furniture, whatever. Anything that looked like it was a deal, I’d bid for.

One of the lots I bid for, included “Computer Gear” – And I won for $55. Yes, $55.
12 pallets of “Computer Gear” in fact. After several trips of loading/unloading, I had quite a bit of old tech that was new to me.

“What value does any of this stuff have, if you only paid $55 for it?”

Well, most of the PC’s ended up being sold for scrap metal for $100 (There’s a $45 profit).
I still have most of the RAM (which may end of up eBay). The HP tower in the middle is an i7 box with 16GB of RAM, and is being used as a standalone ESXi host…

More “value” from data that wasn’t secure
But there was way more (potential) value in one of the specific pieces of gear.

A 1U/4 drive NAS device (originally retailing for about $1500) was one of the pieces of gear included. I didn’t know the password, and it didn’t have an IP address on my network… After a quick lookup of the reset process online, I had it on my network, and had reset the administrative password.

WHOA! I had access to the files on this NAS box now. Over 10 years of data on thousands of people. Why was this system not sanitized before being sent to auction? How could this make it out of the datacenter without being wiped?

I’d like to think that I’m a good person, and I try to always adhere to my USAF Core Values

  1. Integrity First
  2. Service Before Self
  3. Excellence in all we do.

I didn’t look at any of the data’s specifics, other than seeing the folder’s descriptive names which allowed me to determine it was data I had no business looking at. I pulled each of the drives out, and performed a DoD data wipe on each to prevent any of this data falling into nefarious hands if I ever discarded the device/drives.

How to easily do it better with vSAN Encryption
It is no secret that I work at VMware, in the Storage and Availability Business Unit, specifically on vSAN, and one of my focus areas includes Encryption and Security.

I think about the new feature we added a year ago – vSAN Encryption.

If this NAS device had been an Encrypted vSAN Cluster, or really even just a host, the result might have been different.

Why? Well for starters, when vSAN Encryption is used, disk groups cannot be mounted without a host being able to retrieve a Key Encryption Key (KEK) from a Key Management Server (KMS).

A KEK is associated with a vSAN Cluster. When a host boots, it directly contacts the KMS (from a profile pushed by vCenter to the host), sends the Cluster ID, and the current KEK is sent to the vSAN Host.

If a host is taken from ClusterA and added to ClusterB, the Cluster ID is different. If vSAN Encryption happens to be enabled on ClusterB, the KEK for ClusterB is sent. The host from ClusterA (now in ClusterB) won’t be able to mount the disks because the KEK it had used doesn’t match up.

And in the case of a single host being off the network? Say after purchased from an auction? Well no access to the KMS, and therefore no KEK, results in the data being unrecoverable. Unrecoverable, because it is encrypted and unable to be decrypted.

I could be certain that data is safe because of the Cryptographic Module in vSAN 6.6 (FIPS 140-2 Evaluated) or vSAN 6.7 (FIPS 140-2 Validated) is secure.

I’m thankful to the engineers at VMware who worked to bring this capability vSAN, and love the fact that it is easily consumable by vSAN customers.

For more info around VMware vSAN’s and GDPR, look here:
Hyper-Converged Infrastructure Takes on GDPR Concerns

For more info around VMware vSAN’s Data at Rest Encryption, look here:
Introducing Native Data-at-Rest Encryption in vSAN

One thought on “Secure by Default – Why did it take something like GDPR to do this?

  1. Great write up on why encryption should be by default on everything from the storage, to the wire. Love the USAF Core Values, values you hope everyone would live by. With storage going more and more to SSD or NVMe, encryption should just be standard part of the hardware. Great to know that VMware is embracing encryption everywhere.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.