I cannot disagree with anyone that is apprehensive in moving from the current Windows desktop operating system that is installed for the majority of your users’ desktops to Windows Vista. We have all seen or heard the horror stories from past operating system upgrades. Applications do not work, drivers are not available, users do not adapt well… etc. Well, Vista does exhibit some of these issues. However, there are some compelling security reasons to make the move. In reality, I am going to suggest that you make the move for the IT staff immediately! This article describes the top 5 security based reasons to move to Windows Vista for all users in the environment. The reasons are valid and very reasonable.
UAC for Standard Users
User account control (UAC) went through numerous iterations and name changes during the Beta period for Windows Vista (code named Longhorn). The goals for solving end user issues were high and the results were reasonable. If your goal for UAC is to solve the LUA (Least privilege user access) bug, then you should continue on to bullet number two. UAC does not solve the LUA bug in any way shape or form. If you are not familiar with the LUA bug, it is the problem that is caused by poorly coded applications that force users to be local administrators in order to run applications. There are fixes to the LUA bug, if you go to XYZ you will find articles written to solve this issue.
What UAC does for end users is protect them against malware, adware, and other misbehaving applications that are running in the background. We all know that end users will click on nearly every radio button, read every email, and install any “fun or humorous” application. UAC is available to help protect the computer from the end user. The key to UAC is that any action that requires “administrative privileges” will prompt the user for the required credentials. If the user is not an administrator, the task can not be performed!
The prompt that that the end user will see is one that asks for the credentials of an administrator, as shown in Figure 1.
Figure 1: UAC prompting an end user for “Administrative credentials”
If the user is not a local administrator, this dialog box should not be able to be configured. As a best practice, the two alternatives should also not be provided. The first is to provide the end user with local administrator credentials. If you do this, you are granting the user local administrative access which is no better than giving the end user account administrative power. The second, which is to have an administrator come and input the credentials for the user to perform the task, is also not ideal. Imagine a world where 10,000 users need a “physical” administrator to input credentials. This would cause mass hysteria and mayhem.
The solution to this is to have the user report that they can not install a “needed” application through some procedure. Then the IT staff can provide a solution to grant the user access to the application. Solutions that come to mind include using Group Policy, Specops Deploy, XYZ, to install the application. If the user needs administrative privilege to run the application, now you need to refer to the article that I referred to earlier at XYZ.
Not only does UAC protect the user from installing applications or widgets locally, it also protects them from attacks from the Internet. Web sites on the Internet can be very sneaky in their delivery and execution of malware and adware. With Windows Vista and UAC, the computer will always flag any activity that is occurring to the system files and registry on the computer. Your end users will be notified when a modification has been triggered by an attacking Web site and application.
UAC for Administrators
UAC is a good solution for end users, but an ideal solution for administrators. This would include anyone that has membership in the local Administrators group for the desktop in question. For these users, protection from attackers is essential. If you are an administrator, local or domain, you need to take every protection to protect your computer and the network.
In a similar fashion to the end user that we just discussed, local administrators can be protected from malware, adware, and inappropriate acting Web applications. However, the difference is that the local administrator does have local administrative access… unless they are using UAC!
The definition of LUA is as follows (which is defined by the US Department of Defense):
“[The Principle of Least Privilege] requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use [including malware].”
Note: This quote is taken from the Department of Defense Trusted computer system Evaluation Criteria, (DOD-5200.28-STD), or the orange book.”
The fantastic reality of UAC is that no matter who logs on, including a user with Enterprise Admins privileges, when they log onto a Windows Vista computer they are a standard user. This will be the case until a task that requires administrative privileges is triggered. In this instance, a dialog box will appear asking for approval to complete the task, as shown in Figure 2.
Figure 2: UAC prompting an administrator for approval to run a task
The difference between this dialog box and the one for the end user is that no credentials are required. The user logged onto the Windows Vista computer “is an administrator”! Thus, they are granting the system to perform a task that requires elevated privileges. This means that up to this point and for all other tasks they are still a standard user. It is only for the task at hand will they be granted elevated privileges, if they agree to the elevation presented by UAC.
This means that nothing can occur to the system files or registry without the user being informed of the action. This will protect the administrator from all applications that are trying to run behind the scene. From personal experience, this includes even the most trusted Web sites that we all use and trust on the Internet.
The other benefit that this provides is that dual-admin accounts are no longer required. For years I have suggested as a best practice that two user accounts are required for domain administrators. One account has limited, standard user privileges. This account is to be used for routine tasks that need to be accomplished throughout the day, such as checking email, writing memos, and other routine employee tasks. The other user account should have administrative privileges. This account should be used for network tasks that require administrative privileges. This might include modifications to Active Directory, DNS, routers, etc. The separation of duties protects the network and the users desktop from attack from those that want to do damage or sabotage the environment.
All of these security measures contribute to the overall benefit of having the computer protected against applications, malware, ad-ware, etc that attempt to access the registry, system files, and other protected areas of the computer behind the scenes. The attempts will still be made, but since the administrator is just a standard user, the attempts will fail and the dialog box will be shown, asking for the permission.
Reset Local Administrator Password
In conjunction with the benefits that UAC provide, once you have Windows Vista and at least one Windows Server 2008 domain controller, you will have new Group Policy settings available to you. These new settings fall under a new type of policy setting which are called Group Policy Preferences.
Group Policy Preferences add over 3000 settings and some help security where no other tool has gone before. The two main security settings that Preferences control affect the local SAM of your Windows Vista desktops.
The first is the ability to reset the local Administrator password, through a GPO. The setting is quite simple, as shown in Figure 3. The true benefit of this setting is that it applies during a Group Policy background refresh. With this benefit, you can apply
Figure 3: Group Policy Preference to control the local Administrator password
Control Local Administrators Group Membership
The second setting that Group Policy Preferences provide control over is the membership of the local Administrators group. Here, the key control is to remove the user account from the local Administrators group, to aid in moving towards Least Privilege User Access (LUA).
Here, the policy setting is just a check box for the Local Group Policy, as shown in Figure 4.
Figure 4: Local Group Policy used to remove the user from the Administrators group
Like the setting for the Administrator password, this setting also applies in the background refresh of Group Policy. With both of these settings applied, the security of your Windows Vista computers can be increased dramatically within one 90 minute refresh cycle of Group Policy.
Advanced Firewall Security
Windows 2000 and Windows XP came with forms of a Firewall that met some needs, but not all. In conjunction with the Firewall, Windows XP also provided the ability to use IPSec policies. The problem with these solutions was that it was hard to combine the two, as the technologies were quite difficult to configure, especially IPSec.
Now, there is a much simpler feature of Windows Firewall, which combines the two technologies together. The new Advanced Security of Windows Firewall, provides control over inbound and outbound traffic. Ports, services, and applications can now be controlled granularly and easily. Figure 5 illustrates a common dialog box for control over one of the inbound rules.
Figure 5: Advanced Security for Windows Firewall inbound rule
Summary
Windows Vista provides some additional features and security measures that make the move well worth the time and money. If you are an administrator moving to Windows Vista, it is highly recommended. UAC for Windows Vista provides a solution to LUA for administrators. For standard users, UAC and the other security controls provide a much higher level of security, as well as a foundation for achieving LUA for standard user desktops.
