BitLockered Ourselves

[PliotronX]

So you know how computers have a way of misbehaving at the worst times? This is one of those times; a midsize company has a policy of enabling BitLocker upon deployment of the image for all portable devices. The COO of said company had a possible malware infection (not likely a Crypto variant but we can't say yet) and refuses to boot back up. Perhaps the boot sector had been affected because the Windows 8.1 install cannot get past "automatic startup repair." Now the fun part: the key does not appear to have been planted in AD. And the COO is a curmudgeon that didn't back up nor store anything on the file server that is not only backed up but replicated at three sites. Years of data.

Since the "automatic repair" is having a rough time (yeah right, when has that worked?), there is really nothing readily apparent that we can do at this point. I know if it were that easy to break, it would be pointless but are there any workarounds if we have the original laptop that generated the key and perhaps the exact deployment image at the time of key generation?

 

[Mushkins]

Encryption is used for a reason, if there was an easy two-click way around it then it wouldn't be effective.

This is an instance where COO or no, the only thing you can do is use the hardware switch to disable wireless before booting up the laptop to ensure there is no network connection, boot the laptop back up in safe mode, and investigate the threat. If he refuses to let IT do their job, then he loses his data. That's his choice.

 

[PliotronX]

I know this, it makes it all the more frustrating because a while back my boss heard about this "BitLocker thing" and thought it would be awesome to deploy without a DRA or key on file (relying on AD only). Myself and one guy are struggling with this while our higher ups are out jetskiing until Monday. S rolls downhill indeed. My coworker may have found something to get us over the automatic repair loop though.

 

[JoeBleed]

wait, can you even get into safe mode or are you being dumped back into the auto repair loop? tried the F8 key to get into safe mode with out networking and see if that works?

if you can get into safe mode, can't you export the key? I wish i would get around to playing with bitlocker, but i haven't so i'm not sure if that's possible. Seeing as it has been a few days, have you had any luck?

 

[PliotronX]

wait, can you even get into safe mode or are you being dumped back into the auto repair loop? tried the F8 key to get into safe mode with out networking and see if that works?

if you can get into safe mode, can't you export the key? I wish i would get around to playing with bitlocker, but i haven't so i'm not sure if that's possible. Seeing as it has been a few days, have you had any luck?

Nopers, not even safe mode. Refresh, repair, command prompt, safe mode, everything that we would need to do to repair the OS is locked. We were attempting a CBA but the laptop had a supremely outdated firmware that was preventing the memdump programs from loading via USB (secure boot was disabled). Before I had a chance to try the PXE boot version, my coworker reset the CMOS so we don't even get to the automatic repair step; after re-enabling TPM it goes straight to asking for the key. Hopeless. If anybody takes something from these mistakes, learn two things from this teachable moment, gang:

• Back up. Always. And again.
  
  
• Audit your DRAs and keys because nobody ever follows the above
  

I have never liked FDE. EFS including the page file and strategic folders should be "good 'nuff" and allows the IT team to fix the goddamn OS.

 

[imagoon]

EFS with a lost key is just much of a loss as FDE. FDE simply prevents "mistakes" and is generally required now to meet any of the PHI / HIPPA / etc regulations. File based encryption is not generally accepted.



Back up. Always. And again. <--- this is the correct answer.

 

[PliotronX]

EFS with a lost key is just much of a loss as FDE. FDE simply prevents "mistakes" and is generally required now to meet any of the PHI / HIPPA / etc regulations. File based encryption is not generally accepted.



Back up. Always. And again. <--- this is the correct answer.

Right, but this situation was different in that if we were able to boot into safe mode or refresh the OS it would have been possible to at least access the data. We were shut out cold without so much as a password attempt.

By the by for my own curiosity do you have any literature about FDE being a requisite? My understanding was that any PHI is to be encrypted, nothing said of the OS around it.

edit- I have been unable to find anything in HIPAA that dictates FDE. The closest it gets about encryption for data at rest is "reasonable measures." EFS has not been specifically excluded AFAICS. I've not looked into other regulations though.

 

[imagoon]

Right, but this situation was different in that if we were able to boot into safe mode or refresh the OS it would have been possible to at least access the data. We were shut out cold without so much as a password attempt.

By the by for my own curiosity do you have any literature about FDE being a requisite? My understanding was that any PHI is to be encrypted, nothing said of the OS around it.

edit- I have been unable to find anything in HIPAA that dictates FDE. The closest it gets about encryption for data at rest is "reasonable measures." EFS has not been specifically excluded AFAICS. I've not looked into other regulations though.

Without the password or recovery key "fixing the OS" was not the problem in this case.

As for the other question, technically yes a single file being encrypted meets the requirements however good luck proving that with in the guide lines, the data was encrypted when the data was lost.

Also you can repair the boot sector on bitlocker volume using the same tools as you would a non bitlockered volume. The boot partition is unencrypted and contains the decryption engine to boot the encrypted volume.

 

[PliotronX]

Without the password or recovery key "fixing the OS" was not the problem in this case.

As for the other question, technically yes a single file being encrypted meets the requirements however good luck proving that with in the guide lines, the data was encrypted when the data was lost.

Also you can repair the boot sector on bitlocker volume using the same tools as you would a non bitlockered volume. The boot partition is unencrypted and contains the decryption engine to boot the encrypted volume.

I don't think you understand, the options provided for repairing the OS required the key, even boot sector repair. That volume does not appear when using the command prompt.

Then my point was made, you were incorrect to assert that EFS does not meet compliance. It is big money to scare business owners into enabling features that are not needed to keep data safe. FDE just creates headaches and incurs added overhead. I suppose to "prevent mistakes" it would be fine on a case-by-case basis, we all know those people who do not understand folder structures. Overall, I still do not care for it.

 

[imagoon]

I don't think you understand, the options provided for repairing the OS required the key, even boot sector repair. That volume does not appear when using the command prompt.

Then my point was made, you were incorrect to assert that EFS does not meet compliance. It is big money to scare business owners into enabling features that are not needed to keep data safe. FDE just creates headaches and incurs added overhead. I suppose to "prevent mistakes" it would be fine on a case-by-case basis, we all know those people who do not understand folder structures. Overall, I still do not care for it.

I understand fine, I am telling you that you it does. We do it on a regular basis as needed across a fleet of bitlockered devices. I am also telling you that your issue is a non issue. You didn't have the key. You lost access to your data. This is a failure of your IT department and staff, not bitlocker.

You also have failed to read: EFS does meet the requirements but when something is lost, you need to give good evidence that the file mentioned was encrypted at the time of the loss. FDE prevents "accidents" like the encrypted file from being decrypted else where on the volume. Hence: Good luck proving that when a loss occurs. FDE will cover those "issues" and pass through an audit faster than EFS.