A Plan to Stop Breaches With Dead Simple Database Encryption
Credit to Author: Lily Hay Newman| Date: Tue, 18 Jun 2019 13:00:00 +0000
Data breaches and exposures have been so rampant over the last few years that it's difficult to even keep track at this point, much less step back to mull a solution. But, perhaps out of necessity, researchers from the database giant MongoDB have spent the last two years developing a new database encryption scheme aimed squarely at reducing these damaging incidents. Their secret weapon? Radical simplicity.
The idea of encrypting databases in various ways isn't new. But in practice there have been limitations on where and when data was actually protected. Databases are often encrypted "server-side," meaning that random strangers can't just query it for information, but credentialed users can access some or all of the information in it. But that also means that anyone with full access to the data—like the database operator and administrators—can decrypt and access everything. This puts the data at risk to both outside hackers wielding stolen credentials, and rogue insiders who have been granted more access than they need.
Other types of encryption schemes, though, typically add both complexity and cost, which is why it's taken so long for companies like MongoDB to offer something that's both usable and secure. And given that companies as large as Adobe and Google rely on MongoDB database architecture, it's a solution that could have outsized impact.
"One reason that no one did this before was because they didn’t perceive customer demand the way that it’s easy to perceive today," says Davi Ottenheimer, MongoDB's vice president of trust and digital ethics. All those high-profile database breaches have finally started to make companies aware of what solid encryption is worth.
MongoDB calls the new feature Field Level Encryption. It works kind of like end-to-end encrypted messaging, which scrambles data as it moves across the internet, revealing it only to the sender and the recipient. In such a "client-side" encryption scheme, databases utilizing Field Level Encryption will not only require a system login, but will additionally require specific keys to process and decrypt specific chunks of data locally on a user's device as needed. That means MongoDB itself and cloud providers won't be able to access customer data, and a database's administrators or remote managers don't need to have access to everything either.
For regular users, not much will be visibly different. If their credentials are stolen and they aren't using multi-factor authentication, an attacker will still be able to access everything the victim could. But the new feature is meant to eliminate single points of failure. With Field Level encryption in place, a hacker who steals an administrative username and password, or finds a software vulnerability that gives them system access, still won't be able to use these holes to access readable data.
The focus, Ottenheimer says, was on trying to offer that security in a form customers would actually adopt—a classic cybersecurity problem. "We really focused on making this easy for developers to put into their path to release," he says. "We want them to be able to release new products and code as quickly as possible."
Field Level Encryption is built on well-tested, public encryption standards, and is open source, so it can be extensively vetted by the cryptoanalysis community. That auditing process has already begun, but will expand significantly during the tool's beta testing phase, set to start next week. Brown University cryptographer Seny Kamara has been assessing Field Level Encryption, and says that MongoDB has already made changes based on his team's feedback.
"This cryptographic technology is new and like much of cryptography there are tradeoffs between efficiency and security," he says. "MongoDB’s effort to involve the cryptography community is unusual and welcomed. Being proactive about getting new cryptography analyzed is definitely the right way to do things."
As with any defense mechanism, Field Level Encryption does come with some limitations and caveats. Most importantly, MongoDB databases are what's called "NoSQL" databases, meaning they can accommodate all sorts of unstructured data and fan out across many servers as they grow. And while MongoDB offers the most popular type of NoSQL database, so-called "SQL" databases, or relational databases, are more common overall. This means that Field Level Encryption, or something like it, won't be coming to every database anytime soon. Additionally, the new feature creates challenges to managing all of the different system encryption keys across cloud providers, and also makes it more complicated for the database system to perform certain types of information sorting and querying, since data is scrambled and unreadable.
Still, given MongoDB's reach, Field Level Encryption is an important step—one the company hopes other database makers will now be motivated to take, too. And Kenn White, MongoDB's product security lead, says that he thinks the company will be able to overcome more and more of these limitations as it works with beta testers and beyond. Above all, the goal of the new defense, he says, is to limit access to the data as much as possible. He likens the feature to putting valuables in a safe, and then placing the safe in a locked storage unit. Even if someone pressures the storage provider to cut the lock, they'll still have to contend with your safe.
Nothing can ever be a total security panacea, though. "If you put a pair of bolt cutters and a sticky note with the safe combo on the ground outside your unit then, yeah, I got nothing," White says. "But if you have confidential workloads, now you don’t need to trust MongoDB. If you have a backup that's sitting in a cloud bucket—no one can read the encrypted fields. You can run highly sensitive workloads and have protection against an insider attack or an internal breach. That's a much better position to be in."