Is full disk encryption on a server in a secure data center pointless?

Question

I am having a debate with several people regarding how much protection full disk encryption provides. dm-crypt is being used to encrypt data which is required by my company to be encrypted at rest. The Linux servers hosting the data reside in a secure data center with very little risk of unauthorized physical access, let alone someone actually stealing the server.

My argument is that in this situation, that while complying with the letter of the law, they have done little to nothing to actually reduce risk associated with unencrypted data. In effect, from a logical standpoint, they are in the exact same situation than if no encryption had been implemented at all. I am curious though if this train of though is correct, thoughts?

To tailor the question more to my specific situation, regarding physical protection, the controls around that are typically very sound. I am not saying risk is eliminated but it is considered to be low. Same with disposal of the drives, the destruction controls operate pretty effectively and risk is considered low. From a logical access standpoint the servers are not Internet facing, are behind a firewall, logical access is well controlled (but many have access), and they are not virtualized. Further, the servers operate 24x7, the only time they are rebooted is if it's needed after a change or during installation of a new one.

My concern is that in the event an insider goes rogue, or an unauthorized user exploits a logical security flaw, then the full data encryption does nothing to protect the data versus using some of the other field or file level encryption tools available. Whereas the people I am debating argue that this is not the case.

Answer 1

Two generic things you apparently have missed:

• In case of disk failure, having the data encrypted at rest solves the issue of having potentially sensitive data on a media you can't access any more. It makes disposing of faulty drives easier and cheaper (and it's one less problem)

• Full disk encryption also makes it harder for an attacker to retrieve data from the "empty" space on the drives (which often contains trace of previously valid data)

And if you're using VMs:

• Encrypting the partition makes you less dependent on the security of your hypervisor: if somehow the raw content of one of your drive "leaks" to another VM (which could happen if the drive space is reallocated to another VM and not zeroed out), that VM will be less likely to have access to the actual data (it would need to obtain the decryption key as well).

Answer 2

If the decryption key is stored in plain on the very same media as the encrypted data, then the encryption is pointless. If you have a set of rules, which require data to be encrypted, but permit storing the key in plain on the very same media, then the rules are flawed. If you ever face such a flawed set of rules, you should point out the flaw.

If the key is not stored on the same media as the data. Then the encryption does serve a purpose. That does however raise the question about where the server gets the key from at boot. There are a few options:

• Require a password to be entered during boot. This is not very practical for a server.
• Fetch the decryption key from a key server. This can prevent the data from being decrypted if the server was stolen, it just requires the key server to only respond to requests from within the data center.
• Secret share the key across multiple disks. Does nothing for the case where the server is stolen. But if you have a RAID where single disks are occasionally replaced, it guarantees that any data left on disks returned under warranty is properly encrypted. When a new disk is added to the RAID, an implementation of this technique would have to do the following:
  • Generate an encryption key for this individual disk.
  • Generate a new master key.
  • Secret share the new master key across all disks.
  • On each disk write the disk encryption key encrypted under the new master key.

The three approaches described above can be combined. If they are combined, the key server could be implemented using blinded RSA.

Answer 3

There are attacks on the firmware of hard disks. Googling for hard drive firmware attack will return some results about what the NSA does or can do, which probably isn't very relevant to you; but even hobbyists are able to modify the firmware of drives. This guy even installed a linux kernel on his hard disk - no, it wasn't the PC that ran linux, the hard disk controller itself did that.

If someone gains access to the firmware of your disks (for example, that somebody rents a server from your data center for a month, then returns it; the data center company wipes the drives, then assigns that server to you), they might have the drive firmware do something like "Whenever a block that's written to disk contains a special pattern, for the next 5 minutes, in every read block that starts with root:$1$, replace the first bytes with (some password hash)", you have an attack that's nearly undetectable. Your /etc/shadow file will look normal to you except during the 5 minute time window after your attacker requested a file with a name containing the trigger pattern from your web server, which wrote it to its error log.

Unlikely? Sure. Impossible? Definitely not. Is it paranoid to assume this could happen? Probably yes, depending on how interesting your data is. But, encrypting your drives will protect you from this kind of attack, and it won't cost you anything but a few cpu cycles. And, if there are any laws or regulations to follow, in case of a security breach, i certainly don't want to be in the position to have explain why i thought it wouldn't matter.

Answer 4

Consider what you mean by 'secure' data center.

Generally, I don't consider anything secure against a determined and well-resourced attacker. True, having 18" of reinforced concrete, double man-traps, and armed security provides a fair amount of protection, but it's rare that this protection is all just for you. In most co-location facilities, the only thing guarding you from a person with $500 and enough knowledge to rent rack space in the same facility as you is a dubiously secure wire cage with a three pin tumbler.

Occasionally, natural and man-made disasters will flood things, cut power, poison water supplies and do all sorts of unusual things that cause security guards and technicians to not show up for work or just go home to their families - what I'm saying is that data centers only provide a level of security that is probably not as much as many of their customers think.

Reconsider your stance on the low risk of your disposal contractor losing drives.

A certificate of destruction entitles you too..... the $20 back that you paid them to destroy a drive that didn't actually get destroyed?

Have you visited your drive disposal facility? Checked their hiring procedures? Seen their safeguards? Make sure you're rock-solid on this because it's one of the most obvious vulnerabilities - a change in custody.

So, that's not at all what you asked, how about the insider-threat you actually asked about.

Ok, an insider would have access through your FDE and would see the files unencrypted. In your FDE scenario, it will do nothing to stop or slow the insider from getting at the data.

What it will do is funnel your insider-threat to go through your FDE, which would allow you to log, monitor, and identify a culprit, or at least a suspect. Being able to identify your attacker is a layer of security.

But, I'm pretty sure funneling is not primarily what FDE is for. Even if you do have FDE you can still implement another file-level or other data encryption on top of FDE. You can also still use the operating system's access controls.

FDE protects against insiders that don't have access through the FDE. It guards against server technicians replacing drives taking one and making off with data. It guards against an employee of the server facility picking one up out of a shipping container at your facility waiting for transport to your destruction contractor.

FDE allows you another level to stop insider-threats as well, if you segregate your farm or use granular access - say your insiders only have access to certain servers, etc. FDE would prevent them from simply copying drives wholesale that they don't have access through the FDE for.

Simply put, FDE protects the data on the drive from physical access to the drive. You can try to control physical access as much as you'd like, but the drives will always find themselves with some vulnerability (being stolen by insiders, being copied by insiders, transiting custody where insiders touch it, unguarded due to a disaster, etc). If people touch the drive, FDE is a layer of defense against it.

David

Answer 5

Not surely. It depends on, against what you want to defend yourself. Some examples:

• If you live in a country, where the government can confiscate your server to analyze its content and then use it against you, or your employer.
• If you are the owner of the server, but won't give the possibility of your employee/collegues having physical access to it, that they stole/mirror its content. Then you enable them to service/boot it, but don't give them the encryption keys.
• Same could be serve as an efficient protection if you can't/won't trust your server hosting solution.

It depends on the circumstances. These circumstances I shown as example, are at least uncommon in my environment, but they could be possible.

If you are in a regular business environment, don't do it. It taked a lot of work hours away, and has an extended service time. On my opinion, in most cases it doesn't worth its price.

Answer 6

From your description, I suspect your correct. That is, full disk encryption does not add any real protection for your data on a running server should someone compromise that server to extract the data. This is not what full disk encryption is designed to achieve. However, this doesn't mean there is no case for having full disk encryption on a server. As pointed out in other posts, there are good reasons to have full disk encryption on a server, such as protecting against theft, effective control for disk disposal or having to return failed disks to vendor etc. However, if you need to protect the data on the server when it is running, you will usually need file, table, etc encryption on top of disk encryption - it isn't necessarily an either/or situation.

The other thing to consider is that security is about layers of protection. Suggesting that you have good controls in place for disposal of disks and therefore you don't need full disk encryption assumes that the controls used in disposing of disks will never fail. However, these types of controls usually have a high procedural and human content - it relies heavily on the admin following the procedure correctly. In my experience, these are the types of controls which are more likely to fail. It could be that new employee who just forgets or is not aware of the procedure, it could be that experienced sys admin dealing with a high pressure failure where the boss is pressuring him to get the service back up ASAP etc. Having full disk encryption is simply another protective control which takes some of the pressure off staff and reduces the possible impact from a simple human error.

Where things go wrong with full disk encryption is when people assume it solves more problems than it actually does - this would seem to be the thrust of your argument/concern. I have seen many vendors and even admins convince management that the data is safe simply because it uses full disk encryption. As a result, little if any real risk analysis is done regarding the risks when the server is running. I recently did a large data storage project for a client which involved potentially sensitive and/or valuable data. It was quite surprising the number of vendors who didn't address the encryption questions correctly. Their stock answer was that "its ok, the system uses full disk encryption". Once I drilled down and gave examples and asked how their full disk encryption would protect against various scenarios for a running server, their general answer was "Oh, well thats a problem which the application needs to solve".

For me, the biggest issue I've run into with both full disk encryption and file/table level encryption is the frequent lack of any real consideration regarding key management. For me, most of the solutions seem weak in their support for enabling consistent and reliable key management. There have been many times I've seen a system where I've been told about all the wonderful use of encryption to protect the data only to find that the keys used are poorly protected - almost an after thought. Worse still, due to the lack of a good or understood approach, you come across data centres where the same key is used in multiple places or at multiple levels just so that the admins can manage them effectively and be able to recover when necessary.

Answer 7

Quote: " . . .they have done little to nothing to actually reduce risk associated with unencrypted data. . ."

Ok, yeah, I think you are right. The simple answer is "it is pointless", but "it is also NOT pointless." Which is why, and forgive me for saying this, I think you may be barking up the wrong tree. Let me explain. The full disk encryption (FDE) does serve some purpose - even if it is only for a subset of exploits that are of low probability. There are a number of possible exploits - and LOW probability does not equal NO probability.

So, is it pointless? Not entirely. But why are you arguing against it? Do you want more attention paid to the security when the servers are running, and the data is unencrypted? This enters the region where facts may do you less good, and a sense of politics may stand you in good stead.

It could be that your goal in this argument at work is to establish your expertise. Or maybe there is something you think needs doing, and nobody is paying attention. All the above are valid and reasonable, and part of the everyday workplace environment. I could be misreading your question, but it seems to me you might get a better result by arguing for the action you think needs to be done, rather than against an action that IS being done. Pick your fights.

Answer 8

Thank you everyone for the feedback. In summary, the title question, is FDE for a server in a secure data center pointless? The answer is not necessarily as there could be scenarios where one would want the additional protection on the physical devices. For instance protection during destruction, protection from the host country, or protection in case of disk failure among other situations.

In the text the question was somewhat changed from that stated in the title. The concern in the main question was the data being compromised not via physical access to the server but logical access to the data. Based on the responses, it appears that FDE does not provide this protection. The solution is transparent to the user where the data is decrypted at the server upon boot. At that point one is reliant on other controls such as firewalls, good access management, strong authentication, and patching.

My preference is that in addition to those controls for file or field level encryption to be used with access to the encryption keys being restricted to provide an additional layer of security.

One thing that I didn't see mentioned is that I have heard that FDE can also provide protection from certain types of malware which might programmatically copy the information. However, I have not been able to confirm this statement through research.

Answer 9

Here are 2 more advantages (assuming you use new encryption keys each time you re-install):

• If you run file recovery tools that scan the full block device, e.g. PhotoRec, you do not have to checks tons of old files that are no longer of interest.

• If you run filesystem repair tools that scan the full block device, you do not run the risk of confusing structures and meta-data of an old filesystem with the current one.

JJ

Answer 10

If you use Confidential Cloud Computing (https://security.stackexchange.com/a/241566/84564) you need to have FDE.

But you will not need a secure data center to guard the confidentiality: Unless the attacker works with AMD or is really skilled at bypassing the security in the CPU, your data is safe. Even if the full computer is stolen.