3 ms·

DEP, UAC, Security related updates not installed, using built in administrator (technically enabling rather than disabling), or even having your anti-virus disa

DEP, UAC, Security related updates not installed, using built in administrator (technically enabling rather than disabling), or even having your anti-virus disabled. All those help prevent a situation where the boot up sequence is somehow compromised. Whereas secure boot is only reactive - it won't do anything to prevent the malicious software from installing itself in the first place. Also, no, I have not gone out and done a survey to find out how many people understand secure boot. However, if you just use common sense and apply your experiences with interacting with an average user (might be your parents, co-workers, relatives, friends, etc.) then how likely do you think the majority of average users will have even heard of secure boot? I'd be willing to bet money on the answer to that.

ksk 13y ago
>DEP, UAC, Security related updates not installed, using built in administrator (technically enabling rather than disabling), or even having your anti-virus disabled. DEP is already on by default, so is UAC. Updates not being installed shows up as a warning on the Win 8 login screen. Next, Win 8 AFAIK creates a non-admin account by default, so if you are logged in as admin, you have jumped through some hoops to create one. And there is some kind of "action center" warning on not having an anti-virus installed. Remember, secure boot needs to be enabled outside the OS. If the OS could enable it by default, it already would have been enabled. It could be that the user has knowingly disabled it. The OS has no way of knowing the intent of the user, hence the warning. Assuming the worst-case scenario in security matters is nothing new. >All those help prevent a situation where the boot up sequence is somehow compromised DEP primarily prevents "fishing" expeditions for remote-attack scenarios where the attacker blows through the stack, writes to some random region in memory and attempt to execute code from there. DEP defaults to pages being either executable or writable but not both. UAC has nothing to do with the bootup sequence, nor has anything else you mentioned. > Whereas secure boot is only reactive - it won't do anything to prevent the malicious software from installing itself in the first place. Nothing can prevent an user from running executable code he wants to run. Secureboot implements a method to counter an Admin account compromise. It is not needed if the user is running as a non-admin.
- Tomdarkness 13y ago
  You've missed the point. If they are enabled by default or display a message elsewhere is irrelevant, the fact is they don't display a watermark when the user is using the less secure option. Also I specifically referred to the built-in administrator which is not like a normal administrator account as everything it executes has elevated privileges. Yes, all of those have nothing to do directly with the boot sequence. But again, that is not the point. They all help prevent the malware from executing or gaining hold in the first place, before it has the chance to compromise the boot sequence. Secure boot does nothing to stop the malware in the first instance, just prevents it from messing with anything at boot. In my view, I'd say that actively defending from the malware is far better than reacting after the event to limit the impact. I'm not saying secure boot is not helpful but rather the current level of notification you get when it is disabled is disproportionate.
  - ksk 13y ago
    OK, too many loose ends here. Let me tie it up.. All those settings are controlled from inside the OS. The OS can track whether the user has intentionally changed them. Secure boot has to be enabled outside the OS. In which case the OS has no way of knowing whether the user has intentionally disabled it. Assuming the worst-case scenario can be a good thing when it comes to security. Personally, unless I can get it to work with CentOS, I wont be using Secure Boot since I ship products on Linux. However, I don't think the warning is disproportionate.

ksk 13y ago

>DEP, UAC, Security related updates not installed, using built in administrator (technically enabling rather than disabling), or even having your anti-virus disabled. DEP is already on by default, so is UAC. Updates not being installed shows up as a warning on the Win 8 login screen. Next, Win 8 AFAIK creates a non-admin account by default, so if you are logged in as admin, you have jumped through some hoops to create one. And there is some kind of "action center" warning on not having an anti-virus installed. Remember, secure boot needs to be enabled outside the OS. If the OS could enable it by default, it already would have been enabled. It could be that the user has knowingly disabled it. The OS has no way of knowing the intent of the user, hence the warning. Assuming the worst-case scenario in security matters is nothing new. >All those help prevent a situation where the boot up sequence is somehow compromised DEP primarily prevents "fishing" expeditions for remote-attack scenarios where the attacker blows through the stack, writes to some random region in memory and attempt to execute code from there. DEP defaults to pages being either executable or writable but not both. UAC has nothing to do with the bootup sequence, nor has anything else you mentioned. > Whereas secure boot is only reactive - it won't do anything to prevent the malicious software from installing itself in the first place. Nothing can prevent an user from running executable code he wants to run. Secureboot implements a method to counter an Admin account compromise. It is not needed if the user is running as a non-admin.

Tomdarkness 13y ago
You've missed the point. If they are enabled by default or display a message elsewhere is irrelevant, the fact is they don't display a watermark when the user is using the less secure option. Also I specifically referred to the built-in administrator which is not like a normal administrator account as everything it executes has elevated privileges. Yes, all of those have nothing to do directly with the boot sequence. But again, that is not the point. They all help prevent the malware from executing or gaining hold in the first place, before it has the chance to compromise the boot sequence. Secure boot does nothing to stop the malware in the first instance, just prevents it from messing with anything at boot. In my view, I'd say that actively defending from the malware is far better than reacting after the event to limit the impact. I'm not saying secure boot is not helpful but rather the current level of notification you get when it is disabled is disproportionate.
- ksk 13y ago
  OK, too many loose ends here. Let me tie it up.. All those settings are controlled from inside the OS. The OS can track whether the user has intentionally changed them. Secure boot has to be enabled outside the OS. In which case the OS has no way of knowing whether the user has intentionally disabled it. Assuming the worst-case scenario can be a good thing when it comes to security. Personally, unless I can get it to work with CentOS, I wont be using Secure Boot since I ship products on Linux. However, I don't think the warning is disproportionate.