I was wondering:
What protection will I have when I enable disk encryption, but when I disable the Preboot (by allowing the autoboot) option?
Will my data be safe for Windows security hacking tools? Or will this be actually no protection at all?
We are currently using version 5 and are busy with testing version 6.
However, it seems like the password sync problem we have with version 5 is still here with version 6. (See KB 66015)
Somewhat reduced security. Degree varies, depending on Windows security standards applied to that PC.
Please note that you could not access encrypted media with alternative boot method, without knowing EE credentials or keys (SDB/xml).
Once Windows is logged to, encryption is virtually gone, so disk access via network or other means is transparent.
Also PBE needs user intervention, so hacked computer cannot be restarted automatically to Windows. That offers additional protection.
I think it would be hard to claim "safe harbor" if you lost a machine and it was in this mode - especially in states like NY which specifically consider loosing the key with the data to be unacceptable.
So, if you're deploying EEPC to mitigate data disclosure laws, be careful and make sure your auditors and legal council consider what you are doing sufficient.
as for Peter's note of "somewhat reduced" security, seeing as the key is stored on the drive, I'd go a little further.. ;-)
Various members of my management structure have asked why we just can't use autoboot all the time. I've had the best luck illustrating the various scenarios like this:
Imagine you have a house, and all your valuables are inside. You are getting ready to leave for a week on a vacation. You can do one of the following things when you leave:
1) Shut the windows and doors without locking them. (This is your machine without encryption or PBA. A Windows login looks secure, but it's really not that secure)
2) Shut and lock all windows and doors. (This is the intended method of use for SafeBoot, and the most secure. Encryption on, PBA enabled. This is why you bought the product)
3) Shut all windows and doors but only lock the doors. (This is a machine with Encryption turned on, but with PBA bypassed via AutoBoot. This will work to deter an average person from accessing your stuff. But the dangerous people (the people that are good at what they do) aren't going to come in through the front door. They come in through the window.)
I find management starts to think differently when you make them start thinking of data as the stuff they have in their house.
Those two analogies (to car/keys and house/doors&windows) are quite naive. Give me technical details how would you retrieve data from encrypted hard drive with PBA bypassed; to convince me. (there might be a way to do that in version 4.x but it was fixed in 5 and 6)
The key must be on the drive for a start, so there's no doubt that theoretically it's possible. All I have to do is find the key and then I can decrypt the drive. A simple analysis of a machine with a known key will tell me all I need to know to do that, and as we're using a FIPS certified algorithm, we know everything needed to undo the encryption. We just need to work out how to get the disk media key from whatever's being used to autoboot the machine (which is much easier than you would expect).
OR, I could plug in a firewire device and simply zap through the Windows Login prompt
OR, I could use any one of the recent network based attacks
OR, I could wait for a new network attack to be published...
I'm not sure how things changed between 4 and 5 - the two use the same core key design. The fact remains though, the key is for sure on the drive, so you are not protected from regulatory disclosure. Is this topic really about security? or is it really about the need to publicly confess lost data?
need I go on? :-)
Simon has good point: are you asking a legal question or a security question? If the concern is compliance then it's best to ask your corporate/organizational counsel. Our organization falls under US HIPAA and SOX rules and our corporate counsel says Preboot Auth isn't optional. But every circumstance is different.
To Peter's point: he's right too. If you have strong Windows and app patching and update procedures, and good strong control over endpoint configs then the cost of enabling Preboot is probably not justifiable. Unless maybe your machines store state or corporate secrets or something. Never forget that criminals are mostly lazy--all you need to do is make your stuff a little less attractive to them than the next guy's stuff, or throw just enough hassle in their way to tick them off.
Also, always remember that Simon is paid an awful lot to be paranoid and evangelize falling skys. He, and everyone else who wants to sell you security "stuff", will always answer the could-they-do-it question. I have a very real budget that cannot address all the possibilities Simon can imagine so I always answer the would-they-do-it question to decide. Yes, PB is good stuff, but if US law wasn't beating our execs with sticks we'd spend the money to address other risks first.
I think I'm not making myself clear.
from a security point of view, then the argument for preboot is in the eyes of the beholder - there are a lot of considerations.
BUT if regulatory compliance is driving you, there is no argument - without preboot you'd never be able to claim the data was protected from unauthorised access, and you'd be forced to disclose.
so, if you are protecting secret sauce, then you have a choice for preboot or not, but if you're protecting PII/PHI, I don't think in the eyes of the law you have any choice in the matter at all.
Thanx all for the replies.
As the discussion is going on, I have at least found a reason why we shouldn't enable the auto-boot.
Our company should comply with the SOX regulations...
I'll start a new threat for the authentication password issue I referred to in my opening post.