What do you mean by storage encryption?
In my year-long research project, the F5 Labs’ 2018 Application Protection Report, I asked if security professionals used storage encryption for data and applications. About 19% of survey respondents said they didn’t do any while 39% said they used encryption most of the time and 42% said they used it some of the time.
What I didn’t ask and should have asked (and I will ask next year) is how they defined storage encryption. It’s a vague control, and depending on the threat context and how you define “storage encryption,” it can be a highly effective control or a complete waste of resources.
Before we go too far, let’s back up and look at who is often asking this question: auditors. Under many compliance requirement regimes, you need to do storage encryption. Well, a lot of compliance looks like PCI DSS requirements. The PCI DSS doesn’t explicitly require encryption but just states you need to render the primary account number “unreadable anywhere it is stored.” It’s purposely vague to allow the defender to choose between many different techniques and technologies. It also doesn’t address the specific reasons why you need to do this, which leaves matters even more open to interpretation.
What am I getting at? Well, let’s look at a few major ways that defenders implement “storage encryption” to protect data with applications.
Whole disk encryption is the cheapest, easiest, and therefore most common method of doing storage encryption. It’s usually built into modern operating systems, such as Microsoft’s BitLocker, Apple’s FileVault, or the many open-source choices on Linux. It’s an immensely powerful way to protect your data if an attacker steals your computer or hard disk, making it a must-have for confidential data on portable devices.
It’s also superfluous for protecting data on servers, which are usually inside locked cages in data centers surrounded by guards and alarms. Worse, it’s completely useless if an attacker pops the application via SQL injection or some web vulnerability—one of the most likely and devastating scenarios for leaking private data. Unfortunately, I’ve seen more than a few organizations tick the box on a compliance requirement for storage encryption with whole disk encryption.
On the other end of the spectrum is application encryption. This is where the encryption is interwoven into the application itself with decryption keys tied to user authentication and authorization. It offers much more robust protection against application attacks and bonus: physically stealing the computer, as well. It isn’t so useful against credential theft attacks, but it definitely improves confidentiality protection over whole disk encryption.
However, there are downsides. The obvious one is cost since this kind of encryption has to be either coded into the application from the beginning or integrated into an existing app. In both cases, we’re talking serious developer resources and project time. The more complex and interconnected the application, the harder (and therefore more expensive) this is to do. I’ve seen such projects climb into the mid-six figures for a medium-sized financial application. A non-obvious drawback to application encryption is reduced usability. If only specific users have access to private data and not the whole application itself, then you can’t do account recovery (don’t lose your password), data aggregation across the app, and many operations like backup and data processing need to be individually permitted by the user. There are workarounds to make some of these functions work, but they either reduce the security of the system or make the project even more complex (a.k.a. more expensive).
Instead of full application-integrated encryption, some organizations look to database encryption. Implemented correctly, it can offer the same level of protection as application encryption at a (hopefully) lower implementation cost. There is a lot of variation in implementation, though. I’ve seen some database encryption solutions that really don’t offer too much more than whole disk encryption, leaving the primary encryption key laying around inside the app itself, ripe for exploitation via a well-placed injection attack. Application attacks such as this often give the attacker direct access to the encryption keys and therefore, open access to the stored data, regardless of how strong it was encrypted.
One threat we haven’t looked at is problematic here, as well: the unauthorized access of protected data by the system administrators. Realistically, none of these solutions provides a perfect defense against administrator snooping. It gets even more interesting when you want storage encryption in the cloud in case the cloud hosting company is untrustworthy. With a few checks and balances using some additional detective controls, you can usually discover unauthorized administrator action after the fact. But yes, this is more work.
So, why spell out all these scenarios? Because I’ve seen many people, usually non-technical, think that “storage encryption” somehow provides protection against physical theft, application hacking, insider abuse, and everything else. It’d be better if the person asking about storage encryption was more specific about what kinds of risks need to be addressed rather than lumping everything into a single, vague control reference.
And yes, I know I haven’t even mentioned all the other issues that come with encryption, like selection of the appropriate cryptographic scheme and key management processes. It can get real complicated (and expensive) very quickly. All of this is important because sometimes data encryption is thrown around as the perfect security solution. In reality, a significant percentage of security breaches happen because of application attacks, especially web application attacks. Without a robust and well-thought strategy, looking at just the question, “Storage encryption, yes or no?” is a waste of everyone’s time.