1 of 1 people found this helpful
My opinion is neither offer any protection, and are not appropriate for use if you are trying to adher to any regulatory compliance laws, like HIPPA, HITECH, or any of the state or international data protection laws.
But, security is all about risk assesment, so if you are happy with the risk, you are happy with defending yourself against a claim that you did not follow "Industry Best Practice" (ie NIST 800-111 in the USA), and you are happy that in both cases the effort to break into the system is minimal, then by all means go ahead...
I think you can do better though - tens of millions of users are running full disk encryption with pre boot authentication, and those companies are still operating quite effectivly.
1 of 1 people found this helpful
SafeBoot and I have discussed the philosophy of disk encryption with "weak" (eg, non-existent) authentication. Our legal office has determined that they are willing to take on the risk presented by autoboot, in exchange for the user acceptance, and lack of issues related to passwords, change intervals, etc.
That said, permanent use of Autoboot has become a common practice (at least with several large companies), and that shift is reflected in some of the more recent versions.
If you put the HD into similar hardware...it will try to boot to windows. If the HD contoller is close enough, then the PBA will run. Then it's just a question of getting Windows to boot with different hardware present.
One issue with BitLocker: Once a laptop has disappeared, how do you KNOW that the HD was encrypted? What can you present to the State (in the USA) so that you are not forced to disclose the loss of the device?
One follow-up question (before closing this off)
If an Autoboot policy is in-place, and a disk is removed from a machine and placed in another machine with identical hardware (i.e. so that all drivers are present etc).
Would the machine bootup into the OS?
i.e. is the expected experiance that by enabling Autoboot you should be able to do this (I'm hoping not, but would like to check)
Obviously the benefit of using Bitlocker in this scenario (as a result of the TPM tie-in) is that you could run in transparent operations mode, but it wouldnt let the disk be moved to another device.
MANY thanks in advance.
it will boot for sure, but whether it goes into Windows is dependent on the OS.
The trouble with Bitlocker in TPM mode, is a) TPM has been hacked, b) the key is on the drive, so it does not give you protection from data disclosure laws. You have to use TPM plus PIN to get protection - even Microsoft recomend that you DO NOT use TPM only.
Many thanks for your (incredibly swift) reply !
I'll mark this as answered now, BUT (and I know I'm "pushing my luck" by asking) 2 other quick questions I have:
Are you aware of any published data showing performance comparions with the following:
- No Encryption
- McAfee Endpoint encryption
Would also be great if this showed the impact of use of AES-NI as well!
(I saw some "independant" results from Checkpoint but these look quite dated
MS claim in their FAQ on Bitlocker that it "Generally it imposes a single-digit percentage performance overhead")
I'm sure you get asked this sort of question all the time, but ..
Do you think SEDs will at some point take over and replace the need for Software based solutions?
Do McAfee plan to do the same (when?)
1. No, since eveyone uses much the same algorithms, everyone performs much the same. There are some differences though, Bitlocker uses a smaller key than everyone else, and McAfee have an RC5 implementation which is around 40x faster than AES.
The performance impact is so low that it does not matter much, but you are right, AES-NI is an order of magnitude faster than software crypto.
2. I hope SED's replace software crypto, as it's a pain, but it relies on everyone buying SEDs and the manufacturers getting their act together and releasing OPAL spec drives. Anything else is pretty much useless in the enterprise space.
We already have OPAL support in the lab, but with so few drives available, there's no point releasing it. Sure, you could use WAVE, but are your users capable of using BIOS-style passwords, one per machine, disconnected from their Windows credentials? That's the problem OPAL will solve.
Many thanks for the replies - very much appreciated!