Select a language to translate this page!
Powered by Microsoft® Translator
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:
For business deployments:
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.
The experience of many of us who have NTFS data partitions (say on a D: drive) is that when Vista is installed, you can no longer save to (some or all) folders on those drives because of the way that Vista plays with the ACLs.
There is no easy way to clean up the user rights for the drive except by stripping the entire drive of current rights and starting over. This is not even easy for experienced Windows users (as the beta indicated), and will be a real trial for home users since so many OEM machines come with data partitions out of the box.
DRM Genuine advantage product activation restricted licensing.
These are issues of mine hindering my attempts to secure windows.
It just makes it harder and pointless to support windows at home, work and on a grand scale its just gonna fail. It has already.
Very interesting stuff indeed however no one has yet to talk about the accessibility of UAC. Narrator for example still doesn't give blind users access to this screen. It just shuts down.
Just wanted to say that I really appreciate your posts .. they are very well written and extremely informative.
This is Jonathan from the UAC development team, responding to the earlier question about UAC and Accessibility.
UAC was designed with Accessibility in mind – the infrastructure actually provides programs with the ability to mark themselves as accessibility applications, which may need special access to various user interface elements.
In the case of Narrator, it’s possible that it's in a state where it won't run after a transition to the secure desktop. I’d recommend the following – I had success with it on my Vista machines:
1. Lock the computer – this brings you to the secure desktop, so if Narrator is turned off (for the secure desktop), it should be silent here as well.
2. If that’s the case, unlock the machine, press “Windows + U” to bring up the Ease of Access Center, and select “Start Narrator” to refresh it.
If that doesn’t help, please let us know at http://support.microsoft.com/contactussupport/?ws=support, and we’ll make sure that the appropriate people are notified of the problem.
My questions are from a corporate environment context.
Does UAC distinguish between a Domain Admin and a member of the Local Administrators Group?
If I want "admin approval mode" to only function for members of the Domain Administrator's group, how can that be done?
If I want the SAS to expect Domain Admin credentials only (and not local Administrators), how can that be done?
Hopefully the answer isn't to add the Domain Administrators group to the Local Administrator's group.
'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.'
It seems to me as if this is where the primary mistake was made with UAC. There should be an option to make an app run as administrator until further notice. Less secure? Slightly, although if you click OK once you'll probably click it again. More usable? You bet.
This is Darren from the UAC Program Management team, responding to an earlier post by “hitmouse” regarding NTFS permissions on data drives.
Thanks “hitmouse” and yes the old XP ACL was causing access issues in the Vista Beta 2 timeframe.
What was the problem with the previous XP system ACL?
When creating a new folder in XP, “Users” were only given Read permission while Administrators were given Full Control. Since most users logged onto Windows XP as Administrator, everybody was able to “collaborate” or edit the pictures and therefore did not see the access problems.
To mitigate this access issues we did the following:
In Windows Vista (RTM) the default System drive ACL was modified to enable data sharing and collaboration in data directories and outside of users' protected directories. These ACL changes ensure that users can share and edit files without having to provide approval to a User Account Control dialog box. The Vista ACL is applied during installation and migrated to all detected non removable drives that do not contain a Windows OS and are formatted with the default XP root ACL.
Note: Under the following conditions we will not automatically migrate the data drive ACL:
1) Running non RTM version of Vista
2) Data drive was not present or detected at time of install and therefore the ACLs did not migrate.
3) Data drive had old OS installed
4) Data drive or Folder in question has a custom ACL and therefore the migration was blocked
Workaround: If your data drive was not converted for either reasons (1 or 2) then perform the following:
Start a command windows with administrative rights:
A) Click: Start --> All Programs --> Accessories
B) Rclick: on cmd.exe “Command Prompt” and Select: “Run as Administrator”
C) From within the administrator command window run: “Cacls D:\ /s:D:(A;OICI;GA;;;BA)(A;OICI;GA;;;SY)(A;OICI;SDGXGWGR;;;AU)(A;OICI;GXGR;;;BU)”
Note: “D:\” is the data drive being converted
If for any reason we have not covered your specific scenario please feel free to contact firstname.lastname@example.org
Perhaps hitmouse might find Jesper's (http://msinfluentials.com/blogs/jesper) Jan. 16th post useful. It's about granting standard user's write access to what was previously a Windows XP NTFS drive. All objects that inherit permissions from their parent containers ought to get the new User ACE once you add it to the drive's root. So, as Jesper states "As long as you have not broken inheritance somewhere along the directory hierarchy of the drive you will not need to modify any more ACLs on this whole drive." Hopefully home users will get some help with this issue through Vista's new online help system.
Excellent article. Highly recommended.
In fact, I strongly recommend it to InformationWeek and an unnamed Symantec spokesperson. See http://securitygarden.blogspot.com/2007/01/sensationalism-irresponsible-journalism.html
Good reading, and clear enough. Anna is going to have troubel figuring it out, though. Given the friction of getting into and out of some of these security features, it occurs to me that Vista adoption may stimulate both TPM and fingerprint reader attach in PCs. Better a quick swipe than continuously re-entering a password.
It might be helpful to mention that the user must first run IE 7 in "Administrator mode" prior to being able to enable/disable DEP protection.
The article mentions that the admin approval mode only enables administrator privileges just for the task that was approved.
How does this go together with the experience from a previous poster that the user has to run IE 7 in "Adminstrator mode" to enable DEP.
Shouldn't it work this way that IE 7 runs with normal user privileges and UAC only kicks in when Administrator privileges are needed?
I also see this in installers, they require admin privileges right at the beginning when they are started, wether they admin privileges or not.
Hey NTBugtraq: I've conferred with my colleagues on the Security team regarding your questions and they've provided me with the following answers:
- No, we do not distinguish between the two, both account types will have the same UAC experience, except with the exception of the first Domain Administrator on the Domain Controller who has the same RID as the local administrator (RID500).
- It cannot be configured on a per-group basis. We support UAC prompt configuration on a user-type basis (Standard User, Administrator, Built-in Administrator). Note: the Administrator group includes 15 different "privileged" user types, included in the list below.
- We cannot enforce what the user enters into the credential dialog. The only option we have is to not enumerate the Local SAM Administrator accounts in the UAC credential dialog. FYI: By default, the Domain Administrator is a member of the local administrators group on all domain-joined clients.
GROUP / ACTUAL RID
Built-in Administrators DOMAIN_ALIAS_RID_ADMINS
Power Users DOMAIN_ALIAS_RID_POWER_USERS
Account Operators DOMAIN_ALIAS_RID_ACCOUNT_OPS
Server Operators DOMAIN_ALIAS_RID_SYSTEM_OPS
Print Operators DOMAIN_ALIAS_RID_PRINT_OPS
Backup Operators DOMAIN_ALIAS_RID_BACKUP_OPS
RAS Servers Group DOMAIN_ALIAS_RID_RAS_SERVERS
NT 4.0 Application Compatibility Group DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
Network configuration Operators DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
Cryptographic Operators DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
Domain Administrators DOMAIN_GROUP_RID_ADMINS
Domain Controllers DOMAIN_GROUP_RID_CONTROLLERS
Certificate Publishers DOMAIN_GROUP_RID_CERT_ADMINS
Schema Administrators DOMAIN_GROUP_RID_SCHEMA_ADMINS
Enterprise Administrators DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
Group Policy Administrators DOMAIN_GROUP_RID_POLICY_ADMINS
Hope this helps.
Good article, but...
It is about choices.
Not directly about security as such, but why does the backup facility not support tape drives? How idiotic is that? Where is the old backup UI that let you select exactly which files and folders you wanted to backup? The backup app in Windows was never a strong point, but now it is a complete joke. I don't want to back up ALL my image files, or ALL my document files, and I certainly don't want to back up an entire drive... I do want to backup my some of my files, spread around my hard drives and I want to back them up to a DAT tape drive! That is what I bought the tape drive for! We had the backup and restore wizards before, I suppose for home users, but now that is all we have and it is functionally impoverished to the point where it is useless.
The upshot is that Windows Vista does not provide a usable backup at all for anyone with a tape drive who wants to selectively back any thing up!
More functionality is lost in the disk defrag application. It doesn't share any information with you. All you can do is run it (on a schedule). You cannot obtain an analysis, you cannot discover the state of your drives, you can turn it on on a schedule or you can run it now, or you can turn it off. The schedule also seems to assume the system is left on all the time... An invalid assumption. When you do run defrag you have no indication whatsoever of its progress. You are warned that it may take minutes to hours, but you have no way of knowing which it will be. The feedback is so non-existent that you don’t even know which of your hard drives is being defragmented. I suspect it is all of them, which might very well not be what you want!
Removing functionality, reducing user information, concealing folders under ever more layers of obscurity, making users jump through hoops, not once or twice, but every time they use an app, to have established virus protection applications not work; all to serve a paranoia which most of us don't share - all this rather negates the good work the Vista team have done in other areas.
So, congratulations on the good work you have done, but as for the rest of it… I am not American, but I would say in these areas the whole thing sucks!
Thanks Jim - a great article, clarifying many aspects.
In particular, I liked the two Good/Better/Best summaries.......
As for the system being turned on all the time, say in sleep mode (which is sort of the new 'close the computer' thing), I must say that MS hasn't done anthing, imo, which helps the environment much.
Having the computer in sort of a stand by mode all the time uses energy...and leaves also the computer vulnerable to attack from outside soruces, imo. Of course, you could also go into the menu to shut the computer down...
As for the back up functions I reallt don't need to back up files etc. on DAT tapes, but I would like to back up my files on say a USB flash memory drive (USB stick) or on DVD's.
I don't want to back up an entire harddrive...
On a more positive note, I might note that I find the information in this blog useful.
I am caught in a catch 22 situation. To get Vista's strong security, I must run in user mode. Current Anti-virus products can update when the user is in "user mode". I checked all the Microsoft recommended Anti-virus product just now. All and in beta! The ones I checked were Microsoft OneCare, Trend, CA, Symantec, Mcaffe, and AVG. I assume the these new beta soon to become real products, will solve the problem of administrator mode vs user mode. It just isn't clear why and how Vista is ready to give me the security I have under XP (manually switching my modes) now?
Please correct my previous "Current Anti-virus products can" to "Current Anti-virus products for XP cannot"
Hey "Jim Allchin",thx for share
I have to say I'm more than a little disappointed that Microsoft's own virus protection does not work on its new 64-bit OS. Especially since security is suppose to be a major feature of Vista. You guys really pooched this one. When will OneCare be available for 64 bit users?
If vista is so secure y do i still need an anti-virus? the other popular OS does not require an anti-virus?
Hi, I am having a problem with Windows Vista security it seems. I am on a network with server 2000. We only have 1 vista comp which is a new laptop and this is the only computer giving the problem. Whenever the vista workstation gets logged out of, the server account locks whenever the account logs back in when it tries to connect to the server. I have to then go and unlock the account in active directory twice, then it is able to connect again. This happens every time we restart. The network info is static and similar to all other computers and the windows firewall was shut off to test the issue. We are on a workgroup, not a domain. So far no luck, could you please help?
Thanks a lot!
I've have a friend who bought a new computer with the vista program installed. Not knowing that you have to upgrade to another system.Why? Why should a person buy a computer with his hard earned money - get it home - plug it in and finially realize after talking with friends that you have to spend nearly $200.00 to upgrade to premium, just becuase Microsoft failed to inform the public of this .
I would think that when you bought a computer ( like in the old days) it would be functional. There should be a way to upgrade to a more functional program without having to spend hundreds of hundreds of dollars.
Are we ( the general public) that gullible to think that a company can survive with these tactics? I think not!!! Hello congressman.
This is a major security issue that would potentially allow a password changed due to it being breached back into the system again. That happened to me when, I suspected that my daughter discovered my administrator privileged password, I changed it to a new password. Later, I created a new account for my son, which never existed before. He somehow crashed the Vista OS and his account got deleted, albeit my daughters account created using the old administrator privileged password stayed intact. When I tried to log on to create a new account for my son, I was unable to log on with my new administrator privileged password. I was baffled when my repeated attempts using that new administrator privileged password that I used dozens of times refused to log me on. Then, I scratched my head in disbelief, slowly but surely it dawned on me that I should try my old administrator privileged password. Eureka!! It worked. If I had forgotten that old password I would have lost my account on that Vista.. This Vista has many bugs crawling all in it. Us poor MS guinea pigs, we are paying MS for Vista only to find bugs in their big time commercial product, we should receive some type of stipend just like the big shot developers and engineers being paid to find bugs in MS’ Vista. Una Vista Muy Malo?? Mi Cabrone, Que Pasa?
I love Vista! The tradeoff made with UAC is very acceptable to me, and allowing customizations through policy is just the icing on the cake!
Great job guys! Thanks for helping us be a little safer.
I bought a Vista system 9 months ago. I found the security too extreme as I'm not even able to set up a network using Vista Home system. Plus, I'm a Adobe user and I'm disappointed that Vista is not compatible. I also discovered that Vista doesn not support 5.1 or 7.1 surround. I'm not sure if the security issues are at play, but Vista (and by extention Windows Home Meda) make for a poor media system. Unfortuatly, I'm buying a Mac so I can have a real multi media system.
informative post, keep it up.,
Check out this site for more resources on the security features of Windows Vista.