Your Critical Data Has No Clothes…and the Wrong People Know It

I’m sure we all remember the parable of the Emperor Who Had No Clothes. Clever weavers promise a fabulous outfit that is invisible to the unworthy and then leave the emperor naked, with nobody willing to admit it because they don’t want to seem unworthy. There are unfortunate parallels between this and the state of modern database security.

Modern cybersecurity has a whole host of impressive technology and tools. Perimeter security using complex passwords, physical keys, and endpoint detection builds a wall around critical data. Some attackers still get in. Various types of on-disk encryption raise the difficulty of exploiting a stolen database file. Technologies like SSL protect the pathways as critical data is transported. These technologies work, and new and inventive improvements are made every year. With such widespread technology the industry establishes protection at the perimeter, while data is in rest on disks, and while data is in motion being transferred. These protections have become a standard compliance checklist.

Unfortunately, cyber attackers are very smart. Modern cyber attackers are often a persistent threat; they manage to get through the perimeter somewhere and will take their time exploring and attacking. They see good security while data is in motion and while data is on-disk and move their attacks to the place security is neglected – data in use.

Consider a modern customer service center. Representatives need to be able to look up each caller’s records to help them. Perhaps they search by address, or account number, payment ID, or even a partial social security number. For conventional databases to be searchable they must be unencrypted, in fact many cloud services make you pick either search or encryption but not both. Even when the call center’s database is encrypted on disk, that same database is decrypted to memory so that it can be searched. If the database stores 100 million records, they are all decrypted so that the customer service agents can search for and display the one, single record at a time that they need. Even a large and busy customer service center may need a total of a few thousand records a day, but the entire database sits in memory unencrypted during that whole time. The same concept applies when employees are working with financial, medical, or personal data. Cyber attackers know this, so they don’t bother trying to crack an on-disk encrypted database, instead they use a variety of attacks (DLL replacement, kernel corruption, and hypervisor compromise are just a few examples) to simply read the unencrypted database from memory, no decryption requires.

The standard compliance checklist is reassuringly checked off, but the critical data is still naked and visible to the attackers all day every day because there has historically not been a solution to keep the data encrypted while still searching for the needed records. Between social engineering and zero-day attacks almost any system can eventually be penetrated. The internal defenses of these systems, however, are like the emperor’s clothes in the story: nobody wants to talk about the truth that the data is completely naked all day long while in use so that the few needed records can be found. The critical data has no clothes.

How did we get here? Why doesn’t the standard compliance checklist include “encryption in use” as one of the requirements? Cyber security professionals are smart as well, and it’s unlikely any of the above is new information to most cyber security practitioners. The reason in-use database encryption, real in-use protection that protects the data in memory, isn’t on most cybersecurity checklists is simply that it hasn’t been attainable. Why put something unavailable on a to-do list?

A lot of marketers have attempted to convince people that encryption of the database on disk is “in-use” encryption. A web search quickly turns up dozens of products advertising “database encryption in-use” that are actually encrypting on the disk and therefore a more skeptical eye might consider them “at-rest” encryption. Other products advertising “in-use” encryption may bring data encryption all the way to the application and only decrypt in front of the user but searching is not possible, leaving unsolved the problem of finding the desired record.

Paperclip office and work-flow apps have been used by a veritable who’s who of the finance and insurance industries for 30 years. Nine of the top ten life insurance companies have had multiple Paperclip SaaS products for at least 15 years. The Paperclip Virtual Client Folder app alone has more than 300 15K SaaS users, half a billion stored pages, and has been running for decades with zero breaches. With 30-years of running SaaS client apps one thing Paperclip knows is that the most common database access action is searching. Searching to find the one file, customer, or record they need. This drove Paperclip to search for solutions to keeping the data as safe as possible while also allowing users to search for the file they need. There are plenty of records that might not be needed for years, and ideally those records would be decrypted as few times as possible. Previous technology requires decrypting unused records almost continuously, just in case they are searched for, and this is still common practice in almost every database deployment in the world.

Paperclip has been working on a solution for almost a decade. There are multiple published and academically reviewed techniques for secure search, mathematically proven secure. Unfortunately, these have previously proven impracticably slow for many enterprise applications. Paperclip started with a proven algorithm and has spent years improving performance using careful architectural and implementation details without altering the core mathematical concepts. We’ve also added defense against dictionary attacks and built the whole thing on top of Paperclip’s patented and proven data shredding technology to create Paperclip SAFE – our new storage technology. Storing half a billion pages of data with zero breaches after 30 years isn’t easy, but constantly pushing forward the edge of data security technology is how to get the job done. The result is searchability without decryption at speeds undetectable to most humans. One example implementation of Paperclip SAFE added typically 16ms each to overall Select+Where operations [4 million data rows, example test returning 1,200 results, including data shredding and return]. This technology was invented for internal use to protect our customers, but now we are making it available for others to use as well.

Paperclip SAFE, the new storage technology with real in-use protection, doesn’t decrypt records that aren’t needed. If a customer service center needs a specific 1,000 records to get its job done during the day, Paperclip SAFE is how to let your customer service reps find those 1,000 records while keeping the other 999,999,000 records from ever being decrypted.

Now we can add that last desired item, true in-use encryption, to the cyber security checklist and block off the preferred path of modern advanced persistent threats. With Paperclip SAFE the critical data isn’t just clothed; it wears armor all day and night.

Some data sources:

This one has some info on direct memory attacks (without the compromise types I listed): https://www.virsec.com/blog/five-reasons-memory-based-cyberattacks-continue-to-succeed

Solarwinds attack used injection of a malicious DLL: https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/

Info on DLL Hijacking: https://www.upguard.com/blog/dll-hijacking

Hypervisor hacks (less common): https://www.techadvisory.org/2019/04/dealing-with-hypervisors-vulnerabilities/

To get in touch with someone at Paperclip and talk about SAFE, please click here.