One of the most basic conundrums in computer security is the constant trade-off between security and usability.  At the end of the day, if security is too complicated to use, then it simply won't be used.  Even if a feature offers a good level of security protections, if it is complicated or has poor usability it will likely be disabled by the end-user or network administrator, which doesn't benefit anyone.  The same issue with safety and security exists in the physical world.  I remember when car alarms were first available (as an aftermarket product) -- you had to remember to set the alarm after you locked your car and half the time people forgot.  Today, many cars come with alarms from the factory and the task of setting the alarm is usually just part of locking the car -- and as a result, alarms get set.

When we set off to make sure that Windows Vista was the most secure version of Windows ever, we had to create security capabilities that we could enable by default and be usable enough to be left on when the system was deployed.  There is clearly a balance here because if we lock the system down too tightly, then we risk the majority of customers turning key features off, or even worse, staying on older versions of Windows and thus not realizing the great security benefits of the new system.  It's a great irony when you realize that one of the risks of adding more security in the name of making people safer is that users might stay on older  versions that, in some ways, appear easier to use but are much less secure than the new system.

While we greatly improved the security of Windows Vista and we believe it is the best system available, I have always been clear that the system is neither fool-proof nor unbreakable -- no software I have seen from anyone is.  Moreover, there are defense-in-depth security capabilities that some may mistakenly believe are impenetrable security boundaries, when they are not.  This was the hard balance that we dealt with:  How many applications would be impacted with a harder security boundary and how many users might turn off a security feature if the usability was perceived to be worse?

One great illustration of this challenge in Windows Vista is User Account Control (UAC).  In the simplest terms, you can think of UAC as "standard user that works" or "non-administrative user that can actually do things."  Prior to Windows Vista, there were key scenarios that were important to a standard (non-administrator) user that couldn't be completed as a standard user.  So to do things like change the local time zone on the system or many other things, you had to have local administrator privileges.  As a result, almost everyone used a logon account that was a member of the local administrators group -- the secondary effect being that most software developers (including at Microsoft) developed their software assuming that the user would be an administrator.  There were indeed some corporate customers that deployed their environments with their users as standard user, but this was typically an expensive task, and often with some loss of functionality.

So for Windows Vista, the primary goal of User Account Control was to help protect users from inadvertently doing things that require administrative privileges whether that privileged function was initiated by either malware or the user.  Remember that prior to Windows Vista, when the user was logged on as an administrator, they (and typically all software) basically had full run of the system with the ability to override any local security checks.  To achieve our goals for Windows Vista, we not only had to make standard user work well for an end-user who just wanted to get their work done, but also to protect someone who really needed to be an administrator from accidently doing something bad.  The primary goal was to protect the system from both people with malicious intent and users who might inadvertently perform administrative tasks without knowing the full consequences of the task.

To do this, we had to go through the various system tasks that users perform and for each one ask the question:  "should the user have to be an administrator to complete this task?"  What we found was that in Windows XP there were many cases where we required the administrative privilege if the user was making a change that impacted the entire system (rather than just their user account).  We subsequently learned that this was too broad a distinction and in fact, with some common sense rules, we could protect the system while still making it usable.  We also found that there were many cases in previous versions of Windows where we had lumped things together when instead only part of the task really should have required the user to be an administrator.  For example, in Windows XP you had to be an administrator in order to change the time or the time zone of the system. The reason that time functions are usually restricted is that you can do some pretty sneaky things if you can change the system time -- like trick system logs or backdate emails.  But as it turns out, changing the time zone of the machine so that a business traveler based on the West Coast goes to their meetings at the right time when they are visiting New York really doesn’t need to be protected -- so in Windows Vista, we split that out and now allow a standard user to change the time zone.

As a result of this work, in Windows Vista you will find that once you get beyond the setup phase on most systems, you can work just fine as a standard user.  The problem was what to do when the user needs to complete a task that does require the administrator privilege.  To address this need, we created a new capability in Windows Vista so that when a standard user tries to do something that requires the administrator privilege, the system prompts the user to have an administrator authorize the task by entering their credentials (or confirm the task if you are an administrator).

When we first designed this functionality in Windows Vista, we required that the user enter the CONTROL-ALT-DELETE (C-A-D) sequence (known as a secure attention sequence due to its capability to resist interception) prior to prompting the administrator for their username and password.  The reason for this functionality was that entering this sequence is the only way for the user to know for sure that it is really the system (and not some phishing exploit) asking for your credentials -- in much the same way that you never want to give personal information to someone who calls your house claiming to be your bank:  You only want to give your password to the system when you know for sure that it's the system asking for it.  So just like you only give your bank information if you called them yourself (so you know it's them), C-A-D is the high-assurance way to interact with the system directly and know with confidence it is the system on the other end.  When the user hit the C-A-D sequence, we brought up the Secure Desktop, a restricted mode where only the system can run, and then asked the user for their credentials from that desktop.  The benefit of the secure desktop is that it is more difficult for malware to run in that context, and the user knows that they are on the Secure Desktop because the running applications are grayed out in the background, highlighting the dialog box running on the secure desktop.

When we conducted usability testing, we quickly learned two things:  The first was that that the system asked for permission way too frequently; and the second was that C-A-D was confusing to most users, especially home users, most of whom associate C-A-D with bringing up the Task Manager.  To address the first issue, we examined the system and carefully analyzed each situation to make sure that we were only asking for permission when it was really necessary.  We also worked with application vendors to make sure that they do not require elevation to administrators except when it is really necessary.  We looked at cases where an application tried to elevate to administrator mode when it wasn't really necessary and created compatibility updates that made the application think they were elevating without actually evaluating them, thus eliminating an elevation prompt.

The second issue was more difficult to address, since C-A-D is really the only way to make sure that you aren't being spoofed by malware.   With that said, at the end of the day, we came to the conclusion that if we did not eliminate the need to hit C-A-D, then most users would likely just run as an administrator all the time, which was more of a security risk than the potential risk of a credential spoof.  While C-A-D was disabled by default, we still ask for consent on the secure desktop so that the user knows that this is a special request from the system.  In the end, while we left the C-A-D integration with UAC in the system, we disabled it by default.  If a user wants to require the C-A-D sequence for UAC elevations, they can easily turn it on via group or local policy.  Network administrators can also mandate C-A-D for UAC elevations via group policy.  So, if you want to be more secure than the Windows Vista default, just turn on C-A-D for UAC elevations.

Note that UAC may not help you if you already have malware on your machine -- one more reason why we view it as a defense-in-depth security feature and not a hard boundary.

As I discussed above, we also wanted to allow users who wanted to be a local administrator to have that flexibility, but at the same time be safer than Windows XP.  To do this, we created a mode of UAC called admin approval mode.  In this mode (which is on by default for all members of the local administrators group), every user with administrator privileges runs normally as a standard user; but when an application or the system needs to do something that requires administrator permissions, the user is prompted to approve the task explicitly.  Unlike the "super user on" function from UNIX that leaves the process elevated until the user explicitly turns it off, admin approval mode enables administrator privileges for just the task that was approved, automatically returning the user to standard user when the task is completed.

However, it should be noted that this functionality is primarily a convenience feature for administrators and not an explicit security boundary between processes that can be absolutely isolated.  If an administrator performs multiple tasks on the same desktop, then malware may potentially be able to inject or interfere with an elevated process from a non-elevated process.  Thus, the most secure configuration for Windows Vista is to run processes in two separate accounts, with only administrator tasks performed using an administrator account and all other tasks performed under the standard user account.

When we first designed admin approval mode as part of UAC, the default was to require the user to type in their password.  (This was in addition to the CONTROL-ALT-DELETE (C-A-D) sequence I discussed above.)  The feedback from usability testing here was the same -- essentially, users felt that having to type in their password for each elevation was too complex, as was having to hit C-A-D prior to provide consent.  Again, the risk of having this complex (although more stringent) UI was that some customers might simply turn off admin approval mode and then use administrative rights without any protection or warning.  Clearly the security risk with admin approval mode off was greater than the risk of the system being spoofed.  So, although this is not foolproof, if someone is going to run in admin approval mode, it is clearly much better than Windows XP.  In the end, while it's possible to require a password in admin approval mode, it is not required by default.  It can be enabled by an end-user or set by a network administrator using group policy.  See below.

Another great example of convenience vs. security is our strategy on enabling Data Execution Prevention (DEP) in Windows Vista.  In simple terms, DEP treats data as data and code as code, and then blocks execution of any data content.  The benefit of this is that if there is a vulnerability in the system (or in an application) that allows a data buffer to be overrun, with DEP enabled, it is harder for the attack to execute the malicious code that was placed in the data buffer -- thus blocking the attack.  DEP is turned on by default for the kernel and it is a great way of protecting other parts of the system (like Internet Explorer) and applications from buffer overruns.  Here is the problem:  it turns out that there are some third-party add-ons that generate code dynamically and store the code in the data region (sometimes referred to as "jitting"), and there is no method for DEP to distinguish between these add-ons and malware.  So you either have more security or potential application compatibility issues.

Here is the default for Windows Vista.

Note that you can turn on DEP for all programs and services if you want.  This is clearly a more secure state, but it could create some application compatibility issues.  I certainly recommend that businesses test to see if they can use DEP for all programs and services.  In some cases it might be possible; in others it won't be (yet).  There’s that tradeoff again!

Internet Explorer was a particularly difficult case because we certainly wanted IE to benefit from the protection afforded by DEP.  But prior to the Windows Vista release there were compatibility issues with several well known third-party IE add-ons, so by default we could not enable IE to run with DE.  It turns out that there are two pieces of good news here.  The first is that it is possible for dynamically generated ("jitted") code to be DEP-compatible -- it just takes a few lines of new code (and an upgrade to the new code).  We expect most third parties to update their add-ons to support this.  The second piece of good news is that Adobe, whose Acrobat and Flash Player add-ins were previously incompatible with DEP, has updated their software to be compatible with DEP.  (Be sure to get these updates.)

So although it is not the default today, you can turn on DEP for IE for the additional protection.  Michael Howard wrote a great blog post on how to enable DEP in Internet Explorer 7 on Windows Vista.

I personally have enabled IE to use DEP on all my Windows Vista PCs and I would recommend that you do also if you want the added security.  (Again, be sure to get the Windows Vista updates from Adobe.)  I won't promise that all sites will work, but in my typical usage pattern everything works fine.  Over time, as we work with more third parties to make their software DEP-compliant, I expect we will be able to turn on DEP by default for everything.

While we have configured the system to balance usability and security, as I noted above, we've also made it possible for home users and network administrators to make the system even more secure by enabling the features that we ended up turning off by default -- something that wasn't possible on previous versions of Windows.  So what's my advice?  I tend to think of this in terms of a good, better and best approach for both home users and enterprise customers.

For home users:

• Good strategy:  Make the first user account a parental account (even on a kid's machine) and protect it with a good password -- by default, this first account is in the local administrators group with administrator approval mode enabled.  Subsequent user accounts -- especially for kids -- should be standard users.  If a standard user (for example, a child) encounters the need to complete an admin task, the administrator (for example, mom or dad) can enter the proper credentials to complete the task.  With the advent of fingerprint readers on most laptops, this may be as simple as swiping a finger.  You should also use the Parental Controls feature in Windows Vista to help protect and restrict any accounts that kids use.
• Better strategy:  In addition to the steps for "good strategy," also require the password to be entered when an administrator elevates themselves to complete a task using admin approval mode.  This makes it harder to spoof the system and also makes it extremely difficult for an unauthorized person to complete an admin task on a PC that is left unattended.  By default, Windows Vista will lock the desktop after inactivity (if you leave the machine), and if you have a password, then it will be required to unlock the system -- one more reason why we recommend that you have a password on accounts in the administrator group.  You may want to adjust the period of inactivity to be shorter if necessary.  I also recommend that you enable DEP for Internet Explorer.  In most cases, if you get the latest add-ins from Adobe, you will likely not have too many problems.  If you do, it's easy to turn it back off if necessary.
• Best strategy:  If you are extremely concerned about security, then in addition to "better strategy," also require the C-A-D sequence for consent to complete admin tasks.  This will provide additional protection to the system when an administrator is elevating him or herself using admin approval mode and also when a standard user needs consent from an administrator.

For business deployments:

• Good strategy:  The most basic step is to require all users who need administrator privileges for their roles or application compatibility requirements to run with admin approval mode enabled (which is the default).  This provides a good transition to standard user, but provides a little leeway through the transition.  (Note that I personally strongly encourage businesses to move to a "better" or "best" strategy instead of staying at a "good" strategy.
• Better strategy:  Require all (or most) users to be standard user.  Many customers should move their end-users to standard user over time.  When elevation must occur, require C-A-D before the administrator enters their credentials to complete a task.  Also require administrators to enter their credentials in admin approval mode.  As in the home user case, I also recommend that you enable DEP for IE, provided the appropriate testing is done before doing this.  If you have internally-developed add-ons that don't work with DEP, consider updating them to make them compatible.
• Best strategy:  In addition to having most users run as standard users with C-A-D and passwords required for administrators using admin approval mode, do not allow over-the-shoulder elevations for end-users on the theory that any tasks that require local elevations (such as software installs or configuration changes) could be completed more securely using centralized management including group policy.  For changes that must happen locally, the administrator can log on to a separate session (either at the system or remotely using Remote Desktop).

The true test of how secure any system will be in practice has as much to do with how it is deployed as it does with its architecture and code quality.  And how the system is deployed has a lot to do with usability and convenience.  (If you don’t lock your doors at night because it is too much of a hassle, the locks don't offer much security.)  Our goal is that the most generally applicable security configuration (remember, this is a combination of architecture, code quality and usability) is deployed by default.  We sometimes use defense-in-depth approaches when designing security measures instead of hard boundaries for this reason.  We also know that there are certain customers who, even with a deep understanding of the usability issues, may choose to enable a more locked down system than we could ever ship by default.  For these people, we provide great flexibility to turn on even more protections.  What makes this even more complex is that given how broadly a product like Windows Vista will be used, some people may try to create sensationalist headlines by calling out some apparent "weakness."  Before they do, it is important to remember that the design was more likely a deliberate design choice that was balancing some other factor such as usability or application compatibility, rather than an oversight.

jim