• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 736
  • Last Modified:

File Server Encryption

Hi

This is a bit of an open ended question and points to the best answer.

We have a windows file server that is virtualised and sits on a storage array.  My question is, is it best practice to encrypt these files to protect the data that they contain.  The files are of a client confidential nature but they are by no means strictly sensitive data.

Access to all files on this server is audited daily via a 3rd party monitoring tool but should I encrypt too?

Thanks
0
Nick_D
Asked:
Nick_D
2 Solutions
 
ubatCommented:
Strictly speaking you probably don't need to encrypt these files. It mainly depends on what type of agreement you have with your customer.

However, my view is that client data as a rule SHOULD be encrypted.

The exact method depends on what you want to protect against. E.g. bitlocker encrypts the entire hard disk i.e. you can not steal the hard disk.

If you want to protect against someone breaking into the file server either externally or from inside (an employee?) then encrypt the files indivudually with different passwords/encryption keys for different customers and/or sensitivity levels. That you can do using e.g. pgp or zip-encryption.


Exact method depends on the circumstances but e.g. if it is word or excel-files you can use pgp or zip-encryption.
0
 
Dave HoweCommented:
if you can encrypt, then its good practice to encrypt. however, you will need the encryption to be easy to use (for end users) or better yet transparent to them, and most importantly, also apply to backups.

might be worth you looking at MS EFS, as it comes "built in" with all windows from XP onwards. Just don't forget to set a recovery agent :)
0
 
McKnifeCommented:
Hi.

Encrypting the files is usually done if you fear someone breaks in and steals the whole server. If that is possible to happen, why not encrypt?
First of all you need to understand what this implies: If we encrypt the server, we usually don't want to lose the ability to restart the server from remote. We also of course don't want to let go the ability to restart automatically after a power outage or a bluescreen. But with encryption? Together with the need of a password being entered? That's the key point.

So what can you do to get "the best of two worlds: comfort and encryption"?
Since the server is virtualized, you have an excellent option to fully encrypt all its drives and NOT lose the ability of unattended restarting: Let me assume that you don't run good old 2003 but 2008 at least... if so, then there's bitlocker. Bitlocker does not only offer unattended restarts using a tpm chip like you most probably have heard of, no, it gets even better if virtualized. We can put the key on a virtual floppy. Place this virtual floppy image on a network share of another server in a different, secured room.
Why should you do that? Because then you will have the key and the server separated while retaining the ability to boot it hands-free!
If you only relied on the TPM, anyone that gets his hands on the server can simply power it on and boot it. Then sooner or later he will find ways (future network vulnerabilities or the infamous firewire hack...) to logon and poof, all your data lies on a silver plate.

This cannot happen if he steals the server not knowing that it's encrypted and the keyfile is somewhere else.

Other encryptors cannot be used to achieve the same. They simply don't yet offer the ability to boot automatically using a networked key.
Finally, Microsoft has discovered the advantages of this principle, too. They pimped biltlocker in server 2012 to do just that out of the box (with no virtualization needed): they call it network unlock. But therefore, you need server 2012 and suitable hardware.
0
2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

 
Dave HoweCommented:
@Nick_D:
  Usually, you have two threat scenarios.
1) an attacker physically breaks in and absconds with the server (very very rare)
2) an attacker electronically breaks in and accesses files from the server (distressingly common)

whole disk encryption protects only against the former, and is useless (and a waste of cpu) against the latter.

per-user decryption protects against the former, and unless the attacker can run in the context of the user with access to given data, the latter too.

@McKnife:
It is actually pretty easy to get truecrypt to boot from its recovery disk, via PXE, for "server farm" unattended reboots that won't work if the server is physically removed from the datacenter.

That isn't THAT secure though, as the request isn't encrypted.  I have yet to see a decent, encrypted, unattended remote boot solution (although I guess I could code one myself by using a bootstrap loader that requests the key using PFS and a unique ID taken from the machine's partition table), nor one that isn't subject to replay attacks.
0
 
McKnifeCommented:
@DaveHowe
Hi. We are not talking about the same. I am talking about booting the encrypted OS without entering a password. You are talking about the recovery disk which does not even supply a password nor unattended booting. The recovery disk only supplies the preboot authentication in case it's broken - we still need to enter a password.
Or what are you talking about? What did you manage to boot unattended and how? Surely we can mount iso images, yes, but this won't be unattended for truecrypt.
0
 
Dave HoweCommented:
@McKnife: the recovery disk can be modified trivially to boot without prompting for password (well, asserting a fixed password, which amounts to the same thing) or menu options; this is clearly dangerous if it gets into the wrong hands, as the entire floppy disk image is delivered unencrypted by tftp and could be written to physical media and used to boot the server in the absence of the network.

PXE boot is a simple method of "booting" from a floppy or drive image unattended, and can be selective based upon the mac address of the supplicant - so provided the truecrypt floppy has been prepared to not require human intervention, the machine can boot happily either from that floppy, or from a pxe delivered image of that floppy.  However, the insecure nature of this bothers me, so I am looking for a better solution (such as having the supplicant use the onboard session keys, but fetch its master key via a secure connection) but that one has thorns in it - you would need the supplicant boot code to have a viable driver for the networking hardware, and that would require much more coding. I may work on it though, at some point :)
0
 
McKnifeCommented:
So Truecrypt offers no documentation on how to modify the rescue disk, but you say it's trivial? Well, if I analyse the iso file, at first look, "trivial" does not come to my mind. But anyway, you seem to know how to.

If you are looking for a way to request the key via network in an encrypted fashion, I wonder if the new bitlocker of server 2012 (feature: netunlock) does that. I suppose so, but I have not read technical background whitepapers on it.
0
 
Nick_DAuthor Commented:
Hi Guys, I really appreciate your comments and it seemed to generate a really good disucssion.  Thanks for all your input!

Nick
0
 
Dave HoweCommented:
@McKnife: It *is* pretty trivial, but in the sense that Truecrypt is an open source package and therefore easy to recompile with the minor change that the rescue disk has a hardcoded password and automatic "hit return" action (just put a conditional around the code that waits for you to hit "return" and set the entered string to <password>, and the last key to <cr>, if its the rescue disk)

It isn't documented, for many good reasons (not least that this stuff is against the design goal of the recovery iso, but that you need a compiler probably features too) - however, anyone with any knowledge of c at all would consider it trivial, I had it up and running within about 15 minutes of downloading the source :)

Welcome to the world of open source. sometimes, the source *is* the documentation :)

Another interesting element is that the iso isn't really an iso in the classic sense, its a floppy disk image which can be extracted easily using any iso tool (which is a good thing, as PXE can't boot from an iso :)

It is possible that the newer bitlocker can do this; I will look into it (but I can't imagine many sites wanting to upgrade every box they have, even the non-windows ones, to the latest version of windows just to use it; I can use truecrypt happily on linux and on windows 2000 or better.)
0
 
McKnifeCommented:
@Nick_D
Good to hear you found the discussion useful, but me for sure and others might be interested in what you made of it. What suggestions will you actually use and how?
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now