I read this in the release information for 6.0 patch 1. I amcurrious what the point of enabling autoboot is. If you goal is to make it so that the computer cannot be accessed by external parties, what good is it to bypass pre-boot authentication. If I bypass preboot authentication, am I still somehow protected by encryption? Just currious what the implacatons are. Maybe this is something I would like to do, but I don;t understand how I can disable pre-boot authentication and still remain protected. Is getting to the system's encrypted data trivial when pre-boot is bypassed?
Are there any special considerations for AutoBoot? My users currently do not see the pre-boot authentication screen and I want to keep it that way.
The AutoBoot functionality still exists in version 6.0, however, it is implemented differently. In version 5.x, there is an AutoBoot user(s) account that is used to boot the client. In version 6.0, the AutoBoot functionality is a policy setting and no AutoBoot users are required. Enabling this policy setting will enable the AutoBoot functionality.
First of all EEPC v.6 and 5.x are very different when it comes to features, management and security properties.
Autoboot enables after reboot continuation of PC operation without local operator, so it is good for remote installations, recoveries and so on.
It reduces overall security, because you are running Windows security only. Encrypted disk provides protection from using other media to boot PC and access data stored there.
There are documented volnurabilities, including memory, firewire and other type of attacks, but they are not trivial to execute. So even autobooted PC provides good level of security, but not as good as it could be.
not trivial to execute? I beg to differ. You can buy one right now from Passware.. http://www.lostpassword.com/kit-enterprise.htm or get a free tool like http://www.theage.com.au/news/security/hack-into-a-windows-pc--no-password-needed/2008/03/04/1204402...
The main problem with "autoboot" mode is that you are no longer protected from data disclosure regulations, which is mostly why people encrypt drives in the first place.
as peter says though, it's better than nothing IF you are trying to protect the data, only a little better though. But, if you're trying to protect yourself from regulatory disclosure, it's probably not worth anything - talk to your legal team to see if they are happy or not.
Not sure which feature you would use in Passware to access encrypted disk data.
As for the FireWire, you just remove driver in Windows, that should be enough.
Thanks. That's what I kind of figured.
I thought that McAfee including this in the FAQ for the Patch 1 release implied that a lot of organizations were using Autoboot to prevent users from seeing the preboot. This sounded like a bad idea to me, but when I see something I can't figure out, my first inclination is to think that I don;t understand what is going on.
But in EE 6.0 those uses are prevented or at least very difficult to use, right? If the bypass is controlled by EPO policy, then it is not as if my patching system can run a script to enable pre-boot bypass, Right?
In 5.0 I think it is possible to run a specially crafted program to bypass preboot on the next reboot. I think that that is gone in 6.0. I am not sure I want to develop processes based on a version that is going away. I think to be useful for patching and other uses you suggest, there will need to be some way to bypass preboot authentication "on next reboot only" and override what is set as the policy for the machine in EPO. Otherwise, people relying on this ability may be tempted or required to disable pre-boot authentication entirely in order to maintain processes that they have in place.
I don't have a very big deployment of EE yet. I am on 5.x (for 1.5 years) and have had a lot of problems so we have kind of been treading water waiting for EE 6.x to stabalize. I am attempting to figure out how some of our processes will work once EE is implemented more widely.
For instance, we turn computers off at night, by policy and they are automatically powered on at 6:00AM. We treat the time from 6:00AM - 8:00AM as a maintenence window when we are allower to install software and patches. If we implement EE, then those encrypted machines will no longer be able to patch in the morings because they will be sitting at the pre-boot. If we disable pre-boot when the machine shuts down, it is open to attack. I guess what would be the best case would be to be able to communicate to the pre-boot environment over network control - like a remote unlock. It could be secured fairly easily like one or two wrong attempts would disable the feature or something like that. I imagine to implement that though you would need to abandon the MBR and perhaps move to a WinPE partition idea where you would have a bit more access to the hardware on the machine. Pre-boot bypass is a fairly significant pain point for the product. I understand what you are saying though about how you wouldn't want to rely solely on Windows security though.
I am not sure what the answer is there. We are moving to a much more centrally managed method of controling machines and so far I have been trying to figure out how to lessen EEs impact on that model. The tough part is that you can't really have it both ways. I would think there could be something in vPRO or some of the newer technologies like that where a central server could communicate with those machines sitting in Pre-Boot.
It would be great too for the help desk. Rather that reading those keys back and forth to bypass encryption, they could send out a specially crafted magic packet to the machine that could send it an unlock command. (Get developing! ) I think it would be fine to accept one or two attempts to provide an unlock command over the network and if it failed, you would no longer accept attempts and you would need to go back to the key entry system only.
Also, laptops, on the road, are generally sleeping - not fully powered down. So they are effectivly in the same state as bypass pre-boot, right? It would only be hibernate that takes the computer to a spit where pre-boot authentication was in the picture. So in many circumstances, pre-boot is already effectivly disabled.
Whew, what a lot of rambling on. Sorry.Message was edited by: eobiont on 5/6/10 10:15:46 AM GMT-06:00
the feature is in EEPC6 - you turn it on and off via a policy change, which of course you can use EPO automation to do. It's not as obvious as v5, but it does work fine.
remember though, your machines are effectivly insecure while in this mode.
The problem is not so much the planned updates, they can be automated, but it's the unplanned updates - in that case machines as you say sit at login prompts. There's no good solution unless you want to invest in AMT technology, or move to file/folder crypt instead.
So in EE 6.0 it is possible to set a bypass pre-boot authentication on next reboot from a command run on the client? That is what would be required.
Haivng to modify a policy and apply it to a sigle machine in EPO is not useable. What we need is the ability to adjust a setting locally on the machine where it tells the machine to do a reboot, bypassing authentication and we need to be able to do that from a VBScript or some other programatic way from the client itself. Anything less than that is not feasable to implement, or I can't see how it would be implemneted.
no, you can't do it from the client - that's totally insecure, users would just go around turning off the security everywhere ;-) You can do it in v5 though, there's an api command to do it. We don't like it, but it is there.
You can only do it in EEPC6 via a policy change in EPO.
If you really need this though, feel free to talk to your account manager and submit it as a feature request?