The rise of Software as a Service (SaaS) has unlocked an immense amount of value for enterprises and consumers alike. The cost of that value has been control over your data.
With security incidents and sophisticated vendor traversal attacks (like the Aug. 2022 hack of Twilio & Signal) becoming more commonplace, the lack of control is starting to show its true cost.
We’re founding EdgeBit because we believe that we can solve this problem – to empower SaaS services to consume and process data securely – in a way that maintains customer control over data, without getting in the way.
Staying out of the way is crucial. Usability is key to any security feature, and EdgeBit is no different.
It should be easy to:
- ingest any type of sensitive data without re-architecture of your app
- read, use or manipulate that data
- show your customers what code is manipulating their sensitive data and provide an audit trail
- for customers to crypto-shred their data and walk away if they lose trust
It should be hard to:
- extract the plaintext of an encryption private key (this one should be impossible!)
- read user content on a machine, in a queue or in a database
- roll your own crypto or implement it incorrectly
Securing data “in-use” is now essential
Encryption at-rest is required by many security regulations. Securing or encrypting data in-use is lightly covered in regulations but is just as essential to preserving privacy and preventing unauthorized access to your customer’s data.
Data should be encrypted when it is stored and encrypted at every place an attacker or insider could read it while it flows through your app.
The Magic Formula
Four properties are required to unlock capabilities that haven’t been possible before:
- Trusted runtime environment - attestation of the bootloader, OS, and system software.
- Trusted network policy - attestation of the inbound and output rules
- Trusted app code - attestation of the exact code running
- Trusted identity - attestations of 1-3 verify trustworthiness for other operations
Once you can guarantee that the environment is configured exactly as you expect, that data can’t leave that environment (unless specifically allowed) and the application code is audited and reproducible, you reach a magical tipping point. It’s orders of magnitude safer to decrypt and manipulate data. It’s safe enough to intermingle private key material of separate parties, allowing for a customer to “bring their own key” while connecting applications and vendors together.
Every app has workflows that should be specially secured
Frankly, almost every application has functionality that should be encrypted while in-use or secured with extra special attention – from obvious things like crypto key generation and decryption, but also manipulation of sensitive data that the rest of the application has no need to see.
From a security perspective, software engineers have generally treated their own RAM as a secure area for plaintext, but we’ve seen compromises that negate this belief. So far, engineers building applications have not changed their behavior.
On the privacy front, SaaS providers need to embrace the mentality that sensitive data goes beyond the obvious stuff like social security numbers and credit cards to chat messages, user location, file contents and friend lists. Easy-to-use tools need to exist to secure current and future classes of sensitive data.
More from EdgeBit in the future
We’re looking for design partners to influence how we tackle the wider journey of building security-centric and privacy-preserving features of their SaaS applications. We would love to chat about your ideas and test out our software.
If you’re a customer of a SaaS platform and want to influence the platforms you are already using, we would also love to hear from you.