Traditional security approaches often involve securing a myriad pieces of infrastructure and people who go into a building, deploying and managing your server or cloud application. This made sense 10 years ago when the border with the outside world was very clear and ownership of data, databases, servers and administrators all meant the same thing. In the cloud however, this is a tremendous security nightmare because you’re forced to trust (from a security perspective) people and infrastructure that you really cannot or should not.
But before we continue, let’s talk about one thing …
TDE is not very useful in the cloud
Yes, it’s true. TDE or Transparent Data Encryption encrypts the actual database file that’s resident on the database server’s filesystem. Specifically, the threat model it protects against is when someone might pull out your server’s hard drive, read the database file and the information within the database file. This made sense in the pre-cloud era where the database server would be on a server rack down the hallway but no hacker attempts to steal your hard drives from your inside data-center. Not unless it’s Tom Cruise and it’s the Mission Impossible movie. So the first issue with TDE is that this threat model is obsolete in the cloud – no one tries to steal your hard disks from the data-center anymore. The most common attacks in the cloud, the ones that will compromise your data and take down your business, are actually network and logical attacks at the SQL layer. It’s like jumping off an aircraft high up in the clouds and hoping your trusty motorcycle helmet will save you. Well, what you really need is a parachute. The second issue with Transparent Data Encryption is that, well, it’s transparent! This means the database server will happily decrypt encrypted data for requests it receives at the SQL layer. It doesn’t care if that request is coming from your legitimate app or an attacker. And guess what? Most attacks are happening at this logical, SQL level. Be it SQL injection, insufficient access controls or compromised connection string.
A cloud-first security model
Crypteron’s CipherDB and CipherStor products enable a true cloud-first security model. To fully appreciate this, let’s examine the traditional security model first.
Traditional Security Model
As all the recent security breaches clearly demonstrate this security model is broken since it’s very hard to uphold. It requires trusting all of the underlying systems that power your app. This is not only unmanageable but also very untenable in the long run. If any one system is compromised, it can compromise the security and privacy of the entire application and it’s secured data. In addition, infrastructure management is often a shared responsibility that spans multiple organizations making audits complex, compliance a nightmare and true security impossible.
Crypteron Security Model
CipherDB accelerates you to a truly cloud-first security model. No “afterthought security”, no legacy artifacts from prior computing eras. With CipherDB and CipherStor, you need to only trust the application itself. This simpler and agile model offers extraordinary security at a system level. With CipherDB and CipherStor, every supporting infrastructure or personnel that lives outside this ultra-tight trust boundary can be totally untrusted. You no longer rely on pure goodwill of 3rd party maintenance staff. You rely on concrete, modern cryptography to protect the privacy of your data no matter what. Just as a VPN can protect all data within it when traversing wide open public networks, CipherDb and CipherStor protect your data even when stored in the public cloud.
Decoupling that guarantees secrecy
With CipherDB, no 3rd party can ever get to your data. Neither Crypteron nor the cloud database provider. Crypteron only has the keys which are useless without the encrypted data. On the other hand, your cloud provider/hosting company only has your encrypted data which is useless without the encryption keys. Everything comes together in harmony only within your CipherDB enabled app and even there, keys are kept in working memory only when in use.
What does this buy me?
As a Crypteron customer this should be your top question. An investment in the security and integrity of your cloud app is critical to your reputation, business operations and in some verticals, human lives. Here are some of the top attacks that are active in today’s cloud computing environment and which CipherDB and CipherStor mitigate
- SQL Injection: CipherDB provided strong protection against SQL Injection. For details check out our previous blog post on this topic.
- 1st party data breaches: Since the only trusted entity is your own server app, the likelihood of 1st party data breaches (i.e. yourself) is very slim. You can even register the production and development versions of an app as separate CipherDB apps on our management dashboard in which case production and development keys (and therefore data) are completely isolated from each other.
- 3rd party data breaches: Since data is in the clear only inside your CipherDB enabled app, breaches anywhere, be it due to lapses on the cloud provider’s side or even Crypteron’s side, will never compromise your data itself.
- Rogue admin: While a trusted database administrator is desired, CipherDB doesn’t require it. A rogue database administrator has zero insight into your application’s private data. This is useful not only in the cloud where it’s another company that manages the infrastructure you’re renting from them but even in large enterprises where the group managing the data-center doesn’t need to have access to data destined for another group’s business. Encryption keys never touch the database server. At all.
- Backup losses: With CipherDB, backups inherit the security of the primary, so the backup is also safe. In fact a rogue admin could take a backup of the entire database and data privacy would be preserved.
- Database connection string leaks: Typically loss of your database connection string is a potential loss of all the data within the database server. Not anymore with CipherDB.
- Freedom from expensive audits: Since large parts of your application’s supporting infrastructure never touches your sensitive data in the clear they fall outside the audit scope in most compliance standards. This saves you time, money and headaches.
- Protects your data before, during and even after an attack: This is a natural outcome of the fact that the database server falls outside the trust zone and that data breaches target the database server. Any breach will simply result in the attacker being in possession of the ciphertext version of your sensitive data. It’s AES256 encrypted, so it’s unbreakable.
Here are some of the other advantages
- Productivity from day 1 with great code manageability: CipherDB leverages your existing skills with ORMs like Entity Framework and NHibernate to rapidly develop secure, quality code that your colleagues will understand. No custom APIs to learn and no custom code to write and maintain at every interaction with sensitive data.
- Ultra-flexible architecture: Since you no longer have to trust the integrity of the underlying infrastructure provider, you can architect the system as you wish. In fact if you want complete independence from connectivity (e.g. A nuclear submarine that surfaces once in 6 months or an isolated power station), our enterprise self-hosted stack will work in those situations too. Since we’ve designed the system to work with long latencies, you could even host your app and database in the Amazon Web Services cloud and keep the key management running inside Microsoft Azure cloud or even inside your corporate datacenter. In fact, all three, the app, the database and the key-management systems can each be independently moved for a topology that’s ideal for your design, be it public cloud, hybrid cloud or isolated networks.
- No limits on data sharding or partitioning: For large database systems where one would like to shard (or horizontally partition) the data across many databases, CipherDB adds no additional restrictions that would prevent you from sharing your data
If you have questions or concerns please feel free to contact us.
