Understanding BitLocker

[AMD T-type]

Recently a project has come up that has made me question some things about BitLocker from a technical application aspect.

These are mostly rhetorical questions, but I felt the need to ask them out loud and wasn't sure where to post this, so I was hoping there could be some discussion about it.


Recently one of my clients opted for a third party to run a security audit on their network for compliance. One of the recommendations this company made is that we enable BitLocker on our server. I mean, why not? It's a beefy server, it wouldn't affect performance almost at all, so why not just turn it on?

Well, the server is in a locked network closet, that is already in a locked office, of which is in a locked building (after hours). Since the server is mostly just a file server, the drive is unlocked 100% of the time so the shares function properly. So why use BitLocker at all?

Another amusing tidbit I noticed while reading articles online. Since our server is just a file server, and the data partition is a completely separate RAID array, and there is no PHI data on the boot drive, I opted not to enable BitLocker on the boot drive. However, while coming across articles online, many of them recommended that if enabling BitLocker on the boot drive that you use a USB drive to unlock it, while at the same time leaving it in the server so that if you have to reboot it remotely, then you don't have any issue. Well then what's the fucking point of even having it on in the first place if the KEY is plugged into it 24/7?

Another thing is that my client ordered this server without a TPM chip in it. What was surprising to me was that I have always read in order to use BitLocker without a TPM chip you need to edit the registry to allow for it. Surprisingly however, on Server 2012 R2, it allowed me to simply install the feature, open the BitLocker control panel, and turn it on for the data partition no questions asked. Did this change in R2? Why didn't it fuss about not having a TPM?

All of our laptops run SSD's utilizing SED capabilities and pre-boot authentication to unlock them, that is managed by a dashboard so that in the case of loss we can prove an asset was indeed encrypted. I just don't see the point of all the server hoopla if the machine is in a physically secure location.

I feel like the answer is simply "you don't need it" but was looking for any other reasons or opinions from others that would be helpful.

 

[Quix]

If a client asks for something, you just do it. It doesn't matter if it doesn't make sense (which of course it doesn't).

Basically, they're assuming that it's more likely that someone will steal the hard drive, without the rest of the server (which if there is no TPM then you can just easily grab the keys off the system anyway), instead of just hacking the network while the drive is unlocked, which is by your admission basically all the time.

But, if you're a contractor, and you've explained why it doesn't make sense and they still want it. Then you do it anyway, they're the client. On the flip side it means they're going to need new hardware quicker to handle the increased overhead and that generally benefits IT contractors.

 

[Darakian]

Do they have a reason to want the crypto or is it more along the lines of "Ooooohhhh shiny!"?

 

[J-Will]

Sounds like an audit or vendor assessment. Most of those have a pretty blanket policy about data encryption in transit and rest.

Physical security and technical controls rarely go hand in hand. In fact, I have never seen them compliment each other on an audit. Therefore the fact that the server is locked up does not negate the 'requirement' for data encryption. The exception is generally in mitigation or acceptance talks.

The USB thing is pretty funny though. But this would depend on your particular server and environment. If its up most of the time, then dont keep the stick near it. If it isnt... then you probably need a new server.