5 Things SaaS Companies Get Wrong with BYOK

Bring Your Own Key (BYOK) is an acronym without a clear and widely agreed-upon definition. It can mean anything from uploading some key source material to a provider for them to hold and use to something much more sophisticated. We explain the basics of BYOK and how it is approached across the industry elsewhere.

There are big choices in front of software companies whose customers are asking for BYOK and lots of ways those choices can go wrong. And for customers of BYOK, this will help you to understand what you might be getting and whether it passes muster.

Customers who ask for BYOK (or HYOK or CMK or any of the many variants) want better data protection for the data they’re entrusting to their service provider. They want some guarantees about who can access it and of their ability to revoke access if needed.

1. Transparent encryption

Common low-level infrastructure-layer encryption like transparent disk encryption or the thing you get by checking an encryption box on an AWS service simply doesn’t protect the data. This is because the key is only needed when the service starts up, not while it’s running. And while the service is running, the encryption provides no barrier to access and no meaningful security. This sort of encryption only helps when hard drives are removed from computers.

The better option is application-layer encryption (ALE), which encrypts data before it gets saved and which requires access to the keys on an ongoing basis. Unlike with ALE, when using transparent encryption, any admin of the software vendor can peek at customer data in plaintext (and this goes double for hackers that compromise admin computers or credentials).

2. Provider-held master keys instead of customer-held / “HYOK”

Some BYOK offerings ask a customer to upload a key into the vendor’s system, or simply let the customer press a button to generate a key. The key itself is fully under the control of the vendor.

On the good side, the customer knows their data is encrypted independent of other customers’, and there’s little or no effort for the customer to get started since everything is automatic.

On the bad side, the vendor is completely in control, leaving the customer without any control of their data. This pattern also can’t support data sovereignty use cases.

Putting #1 and #2 together: if the vendor holds the key, the customer has less control. If the encryption is low-level and infrastructure-layer, then the customer has much less protection. The best approach uses application-layer encryption and also lets the customer hold their own key (HYOK). The worst approach to BYOK is when a vendor holds the keys and only uses low-level transparent encryption. The other combinations have their own trade-offs.

3. Single-provider KMS option

Another approach, which tends to go hand-in-hand with the transparent encryption from #1, is to stand up dedicated infrastructure for a single customer and then point to the customer’s Key Management Service from it. For example, if the software vendor uses AWS and has checked the “encryption” box for their data store, they can configure AWS to point to any AWS KMS, including one managed by the customer.

This has a number of disadvantages. First: it’s expensive to run, and those costs get passed back to the customer. Correspondingly, it puts better security out of reach of all but the biggest Enterprise customers.

Second: it does nothing to alleviate issues where a subpoena to the infrastructure provider (Amazon, in this example) results in plaintext data going to the requesting entity. This makes things like data sovereignty very difficult.

Third: customers don’t always use the same providers as their vendors. If the customer is an Azure user, then they may not be wild about setting up with Amazon. Or if they’ve invested in their own KMS already, they may want to leverage that investment instead of spending on a duplication of their already paid-for infrastructure.

Fourth: this doesn’t stop curious or compromised admins at the vendor or the vendor’s providers from peeking at data.

4. Adoption for only a few data fields

We strongly recommend that companies don’t start by boiling the ocean. Pick the one or two most important or most sensitive pieces of information or fields to protect first.

But beware, because companies that stop after just doing one or two fields have a poor offering for their customers if those customers perceive other pieces of data as sensitive.

For a security team reviewing a vendor, seeing some fields protected is very encouraging. But if they think all the sensitive data isn’t going to be covered, they probably won’t give the bonus credit that’s deserved.

SaaS customers are often willing to pay extra for advanced security features, but they want to see that all the sensitive data will be covered and that progress is being made in that direction if it isn’t already so.

5. Protection of only one data store

Data propagates within infrastructures and across providers. It’s a byproduct of the cloud-based, distributed and global nature of today’s applications and their microservices.

When a BYOK offering protects data in the primary data store (for example, in a SQL database), but neglects other copies of the data in the infrastructure, such as in a search service, then there’s a pretty big chink in the armor they’re selling to customers. The protection is completely undermined.

Even worse, such discrepancies aren’t necessary. For example, Salesforce has an application-layer encryption customer-managed key offering, but excludes the data in their search indices from ALE protection. This is surprising given the number of encrypted search products in the market today that allow the data to stay ALE protected while still being searchable. Note: Salesforce has a complete offering here, but they don’t really let customers hold their own key. Instead, customers provide the key to Salesforce about once every twenty-four hours and then Salesforce holds it ephemerally.

Bonus: Not getting started

But all of the above five ways that vendors get BYOK wrong pales in comparison to the vendor who doesn’t even attempt to bring data protection and control to their customers. Not getting started, in fact, is the number one mistake of vendors, particularly when products like SaaS Shield handle so many of the complexities and concerns with little effort required.