SaaS Encryption Isn’t Truly Secure
Encryption is not the solution to SaaS data security. There are three different types of encryption that are potentially identified as solutions to SaaS data security, client side encryption, fully homomorphic encryption, confidential computing and enterprise key management. All three have downsides, so we’ll define each and highlight why these are useful technologies they’re each limited in their application of securing data handed over to a SaaS company. There is no zero-trust solution for providing a SaaS application sensitive data and still maintaining the full functionality of the application.
Client-side encryption (no key sharing)
The only secure way to run SaaS applications is to encrypt all of the data on the client side and only send encrypted data to the SaaS app (and ensuring you NEVER share the key with them). However, this approach hobbles the application functionality as this encrypted data can not be transformed or searched. Basically, you end up with remote storage of encrypted data blobs. This methodology is secure (therefore it has applications in the world of enterprise data storage), but it hobbles the ability of a server-side application to actually perform much work. Companies like Keybase are making this much more possible and we’re excited about the potential that it brings (messaging apps such as Whatsapp and iMessage already use this technique to ensure that their servers do not have access to the encrypted messages).
Fully homomorphic encryption (FHE)
FHE is often heralded as the coming savior for SaaS data security. The promise of FHE is that the enterprise is able to encrypt all data in a special way that preserves the ability for the vendor to perform special operations over the data in encrypted form and produce encrypted solutions that can be read by the enterprise with the original encryption key. The problems with technique are related to the a) it is very slow compared to unencrypted computations b) not all operations are currently possible in FHE c) frequency information could reveal patterns that expose the content of the underlying data.
Confidential Computing & Secure Enclaves
There has recently been a big push by Cloud providers to highlight the availability of “confidential computing” which leverages new security features within the chipset to only decrypt data within a secure enclave. This has some really interesting use cases, but when the secure enclave is under the control of an external vendor, additional validation is needed to prove that decrypted data is not sent to an external service (likely through verifiable SBOMs & attestations)
Enterprise key management (EKM)
EKM is touted by vendors such as Salesforce and Box as the solution to all enterprise data concerns. However, for EKM you still have to trust the vendor not to purposefully or accidentally store the encryption key or any of the data while it is unencrypted in system memory. Combining this technology with secure enclaves (specialized hardware to load encrypted data in from main memory into a hardware encrypted cache) can prevent the vendor from accessing the encryption key, but it does not guarantee that data isn’t accidentally mishandled while it is unencrypted on the hardware. The bottom line, is that bugs happen. For example Twitter never intended to store unencrypted versions of customer passwords… but they did the same is true for Mixpanel.
So you either need to trust the vendors you’re working with or not send them the data. Trust was possible when enterprises were working with 5-6 different vendors. However, the current proliferation of SaaS apps within large enterprises (Netskope says the average enterprise runs 900+ SaaS apps) is problematic.
Most SaaS applications don’t even attempt any of these things (it’s a lot of work and not something they’d do anyway w/o these enterprise requests). As a result, for most applications you can be very confident that some $50k/year CSM is accessing all of your company’s private data through some sort of admin dashboard.