46

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.

George
  • 257
  • 1
  • 2
  • 13
user4755220
  • 619
  • 1
  • 6
  • 5
  • 3
    Thoughts that come to mind: If a server is off, the drivers can be stolen. There's nothing wrong with indepth security. If the server is switched off, what does one prevent from disconnecting the network from the server and boot it? Just thinking out loud here. – Jeroen May 22 '15 at 06:40
  • 1
    It isn't entirely pointless but adds a layer of complexity and slightly reduces performance. –  May 22 '15 at 12:17
  • 7
    If your company is doing anything interesting at all, then there is always the risk of people with smiles and warrants who will want hardware access to your server for a few hours. Of course, only them and the DC employees know that has happened. FDE might help protect your clients in this situation, even if neither you nor them know it. – dotancohen May 22 '15 at 13:14
  • @dotancohen and you would be unlikely to even be able to detect it assuming they yank the correct drives out of a properly-configured RAID, image them, and plug them back in – user2813274 May 22 '15 at 14:28
  • As @dotancohen states, you're probably overestimating the physical security of your drives in this scenario. I'd assume that any company that needs to go to the expense of housing their systems in a "maximum security" data center will also consider it standard practice to encrypt their drives. – Lilienthal May 22 '15 at 14:53
  • 1
    "little risk" is not "no risk" and it all comes down to risk management. Encrypted drives, done right, help enforce separation of concerns by preventing data access even if physical access to servers/SANs is required. Especially important when outsourcing your DC's. – Julian Knight May 22 '15 at 15:02
  • What if someone find a flaw in your OS (or plug an USB stick) and run its own software, can he read the FDE key from the memory? – A.L May 22 '15 at 17:03
  • 1
    I can't be sure from the question, are you asking for arguments that FDE is better than file-level encryption in this scenario (since you say, "using some of the other field or file level encryption tools available"), or are you looking for arguments that FDE is better than no encryption at all (since you say, "from a logical stand point, they are in the exact same situation than if no encryption had been implemented")? – Steve Jessop May 22 '15 at 17:33
  • 5
    The maintenance contract on our storage array requires that failed disks be sent back to the company after swapping out (or we pay a hefty "non-return" fee on the drives). Without disk encryption, returning disks may not be possible since you can't wipe a failed disk. We had a power supply take out an entire disk tray once -- that would have cost us around $40,000 in non-returned disk fees. – Johnny May 23 '15 at 03:57
  • 1
    @Johnny Sounds like it would've been cheaper to pretend the disks didn't fail rather than pay the non-return fee. – Atsby May 23 '15 at 07:07
  • What if the data centre's security degrades? Management or policies could change. To – Rimian May 23 '15 at 09:13
  • @André the performance point is moot with self-encrypting drives. And using the well-proven transparent compression/decompression stack in this case is hardly any complexity addon on the software / OS side. You would have to do the key management, though. – syneticon-dj May 23 '15 at 09:24
  • Look at it this way: are airbags pointless in a car equipped with ABS and ESP and driven only by licensed and professional drivers? No they are not. Because there is a residual failure risk of preventive measures, there needs to be a safety net for damage containment. – syneticon-dj May 23 '15 at 11:03
  • 2
    @syneticon-dj currently the security is moot for self-encrypting drives. We can't even trust their "secure" erase function, why should we trust their encryption ? And complexity shouldn't be overlooked especially if you plan on entering the key remotely. I've looked at the solutions for this on Linux and it still looks not reliable for production usage. –  May 23 '15 at 14:52
  • 1
    @atsby - If we pretended the disks didn't fail, we'd have lost the use of an entire tray of disks in our array since the disks did in fact fail. Since we used full disk encryption, we just sent them back after we swapped in the replacement disks, knowing that the encryption would prevent anyone from recovering data. Without encryption, we'd have had to physically destroy the disks and would have incurred the expensive non-returned disk fees. – Johnny May 23 '15 at 15:37
  • 1
    A "secure data center"? How do you know? What, does it have cameras and a couple unarmed rent-a-cops? [Yeah,](http://www.theregister.co.uk/2007/11/02/chicaco_datacenter_breaches/) [good](http://www.computerworld.com/article/2538534/it-management/data-center-robbery-leads-to-new-thinking-on-security.html) [luck.](http://royal.pingdom.com/2008/07/18/forget-about-hacking-your-servers-might-get-stolen/) The military? [Better.](https://en.wikipedia.org/wiki/PNS_Mehran_attack) – Matt Nordhoff May 24 '15 at 06:30
  • @André You might trust or not trust a particular implementation or even a particular manufacturer. But dismissing the entire featureset as untrustworthy just because there are issues with an **entirely different** feature on **some** disk's models seems like throwing out the baby with the bathwater. – syneticon-dj May 24 '15 at 20:59
  • I believe in the Defense in Depth approach. Had to use it on Fed gov servers to pass NSA grade security audits. See: http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29 – FreddyNoNose May 24 '15 at 08:13
  • Is it an acceptable risk if your server under attack crashes and would reboot immediatly to permit the attack to proceed further and improve?↵A disk encryption key to enter would fully cover this risk. – dan May 25 '15 at 22:16

10 Answers10

77

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).
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 5
    The VM comment is a good point and something I have not thought of. The servers I am debating though are not virtualized, they host only one application. – user4755220 May 22 '15 at 13:26
  • I have often had this debate and I appreciate these points as they make a lot of sense. However, they don't address the original question, which is whether encrypting the drives offers any inherent security in of itself while the server is operational? Every security expert I speak to says no. The only value comes when the drives are offline/disconnected. – John Virgolino May 23 '15 at 07:02
  • 1
    @JohnVirgolino FDE is explicitly labeled as "Data at rest protection". Why should it add protection to an online, unlocked (i.e. decrypted) disk? – syneticon-dj May 23 '15 at 09:21
  • 2
    → Stephane: point 1. & 3. are risks correctly covered by a full disk encryption. For point 2. I'm not so sure. For me on many OSes, if an attacker has access to the uncrypted running disk, then the IO buffers, and the part of the disk used for virtual memory are also accessible through a basic `read`. If I'm wrong could you improve this point 2.? – dan May 25 '15 at 22:06
  • @danielAzuelos That's one of the reasons why I wrote "make it harder" instead of "protects against". – Stephane May 26 '15 at 06:50
22

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.

kasperd
  • 5,402
  • 1
  • 19
  • 38
  • Note that fetching the decryption key from a key server wouldn't really help you from preventing leaks. All it does is allow you to create an audit trail of when the key is accessed. – Lie Ryan May 22 '15 at 13:43
  • 4
    Hopefully if you are going to the trouble of FDE using dm-crypt you recognize the need for a TPM to house the decryption key. The things you mentioned are obviated by properly using a TPM, since the key never leaves it and it integrates tightly with the OS and FDE software to decrypt as-needed without exposing itself to simple reverse engineering. – Jeff Meden May 22 '15 at 15:35
  • @LieRyan If the attacker steals the server with the encrypted data but doesn't steal the key server, then the attacker won't be able to decrypt the data. This is of course assuming that the key server only responds to requests from within the data center. The key server itself could use another key server for decrypting its own disk. Fallback to passwords would bee needed to boot the key servers in case both are ever powered off simultaneously. – kasperd May 22 '15 at 15:54
  • 3
    @JeffMeden: Special care must be taken to ensure that the TPM chip does not become a single point of failure. This will indeed tie the content of the disks to the TPM chip and the motherboard, if the motherboard dies, then the disk content may not be retrievable... – WhiteWinterWolf May 22 '15 at 15:56
  • 1
    @JeffMeden You'd be trusting the tamper resistance against an attacker who can use as much time as they like to break it. The attacker would have stolen the server including all the key material needed in order to decrypt. The attacker could even boot the machine and try to attack it through the network in a setup where no IDS can alert anybody, and nobody can cut off the attackers network connection to the target. That doesn't sound very robust to me. I'd much rather rely on the attacker not stealing every server in the data center in order to have the decryption key. – kasperd May 22 '15 at 15:58
  • @WhiteWinterWolf Whatever you do, I'd always want it to be arranged such that the disk can be decrypted using a password. The password is for emergency situations, and the other approach is for normal boot. – kasperd May 22 '15 at 16:00
  • @kasperd, Agreed that a TPM is likely not flawless, but it is the current state of the art when it comes to properly handling encryption key material in a potentially hostile environment. It would (at present) take an attacker significant dedication and resources to compromise it (i.e. nation-state or billionaire evil genius). For an "ordinary" attacker you would follow the evidence from the theft (no doubt many security photos were taken, including face and vehicle), go to their hideout and take the server back with law enforcement assistance. – Jeff Meden May 22 '15 at 17:29
  • @JeffMeden It is only state of the art, if you restrict yourself to solutions that require everything to be inside the machine which you need to protect. If you take advantage of the possibility to communicate between different machines within the data center, much more secure methods are possible. – kasperd May 22 '15 at 18:30
  • @kasperd your premise includes the caveat that there is some higher level of security surrounding the "different machines" but in most colocation settings (where a lot of the internet lives) there is no choice but to put all the eggs in one basket. – Jeff Meden May 26 '15 at 13:44
  • @kasperd: if the machine can reboot without human intervention, then the machine also necessarily contains the access key to authenticate itself to the key server. I can't think of any attack scenario where the attacker cannot just steal this authentication key and the disk encryption key at the same time. – Lie Ryan May 27 '15 at 11:33
  • 1
    @LieRyan For the third time: The key server must only respond to requests from the local network. Once the server has been stolen, it is no longer on the local network. – kasperd May 27 '15 at 12:48
  • @kasperd: how would you be able to have sufficient permission to copy the server's harddisk but not have permission to make a network connection on the local network itself? The only scenario this is possible is if you are disconnecting the server for physical transport, then I agree FDE is necessary. On most other circumstances, the attacker would have already had access to the local network to be able to take a disk image. – Lie Ryan May 27 '15 at 12:57
  • @LieRyan Thieves usually don't ask for permission to steal something. And they usually want to get away quickly, so compromising the key by communicating with the key server while on site is unrealistic. And yes, disconnecting the server for physical transport is implied when I am talking about stealing a server. If the thieves didn't disconnect the server and physically transport it away, you wouldn't say it had been stolen. – kasperd May 27 '15 at 13:18
  • @kasperd: "permission" has a specific context in computer security. As the OP mentioned, physical theft is the least of your concerns in a high security data center, which would have full time armed guards, cameras covering all angles, physical access logs, steel doors, and identity and background checks and frisks before you can even get anywhere near the machines. Individual machines would also be in individual steel cages. You can't simply disconnect a machine and run away from a high security data center. – Lie Ryan May 27 '15 at 14:17
  • 1
    @LieRyan Sure permission has a specific meaning in that context. But once the server has been stolen and is in a location controlled by the adversary, we are no longer in that context. And all of the physical security measures may reduce the risk of theft, but it does not eliminate it. With proper social engineering a person could walk in, pick up a server, and walk away with it. – kasperd May 27 '15 at 22:48
9

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.

Guntram Blohm
  • 1,529
  • 11
  • 13
8

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

David Lin
  • 101
  • 1
1

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.

peterh
  • 2,938
  • 6
  • 25
  • 31
1

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.

Mark G B
  • 151
  • 1
  • 6
1

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.

Tim X
  • 3,242
  • 13
  • 13
0

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.

Ole Tange
  • 301
  • 1
  • 9
0

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.

user4755220
  • 619
  • 1
  • 6
  • 5
0

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

Joachim Wagner
  • 171
  • 1
  • 5