64-bit Windows 7 fares better than its 32-bit counterpart in part due to the inclusion of kernel patch protection, a technology only available in 64-bit Windows 7 that protects the kernel from unauthorized changes. Windows 7 is less likely to be infected overall because of User Account Control (UAC), an umbrella term for a set of technologies that make the OS easier to work with as a standard user or specially protected administrator account (Protected Administrator).

The results reported in SIR v10 for Windows 7 would have been even better if more home users didn’t disable UAC, which is likely what many tech-savvy home and business users do considering the number of articles on the Internet about the evils of UAC and how to turn it off; and hence goes the old adage that people don’t always know what’s good for them. If your users currently run as protected administrators on Windows 7, configure UAC in Group Policy to make it a little harder for them to disable UAC – though it’s worth bearing in mind that if a user has admin rights, Group Policy settings can be circumvented with enough will.

While UAC has some benefits in enterprise computing, it is a user-driven technology. UAC elevation prompts require users to give consent, or provide an admin username and password, to perform administrative tasks, resulting in decisions being made by unqualified staff that affect the integrity and security of the OS.

UAC Protected Administrator accounts provide a lot of flexibility, with a limited degree of security, that wasn’t possible in Windows XP. Once you move to standard user accounts in Windows 7, users can no longer elevate privileges; and all tasks, anticipated or otherwise, must be made to work as a standard user, or IT will have to intervene and provide administrator credentials.

Predicting users’ every move and requirement isn’t possible, so if it’s not acceptable to restrict the computing experience with a standard user account, you’ll either need to leave the default user-driven UAC experience in place or deploy Avecto’s enterprise rights management solution – Privilege Guard.

As well as the ability to assign privileges to individual applications and tasks, Avecto’s software can be configured to allow users to run any process with administrative privileges. UAC prompts can be replaced with custom corporate messages and users can be prompted to provide a valid reason before elevation. An audit trail of privilege elevation events allows administrators to keep track of how privileges are used. Privilege Guard helps companies strike the right balance between the flexibility of user-driven UAC and policy-based IT controls, making Windows 7 more secure and mitigating unnecessary risks.

Security is often viewed like an insurance policy – an expense that’s hard to quantify in terms of return on investment. But skimping on well secured endpoints or assuming that antivirus is enough to keep end users out of trouble is a false economy. Even if your company isn’t subject to regulatory compliance, properly secured systems still bring important advantages that shouldn’t be overlooked.

Anyone who’s run Windows Vista or 7 as a standard user will know that these PCs perform consistently, more reliably, are less prone to malware infection and rarely require support from an IT professional if compared to an equivalent system running with administrative privileges. Application whitelisting can further improve this record, significantly reducing problems caused by malware or application conflicts.

In an ideal world, users would be able to install any application in an isolated container without having to worry about the impact on system performance, malware infection or compatibility problems. And while the technology does exist to virtualize applications, it’s not yet mature enough that users can be left to choose what to install without some assistance from IT.

Striking a balance between a curated least privilege desktop, productivity and the ability to install approved applications on demand is the best way to provision fast, responsive and secure systems that enable users to be as productive as possible. Privilege Guard can help IT departments manage the balance between security and flexibility that is crucial in any least privilege deployment, and improvements in Privilege Guard 2.8 make it even easier for IT to manage privileges across multiple desktops.

But user productivity can be difficult to measure and proving that it provides a competitive advantage or positively impacts a company’s end of year results is not always easy. To get management buy-in, analyse the organization’s helpdesk logs, and give users who generate the most support tickets a fresh build of Windows with least privilege enabled from the outset. Once they’ve run with it for a couple of months and any initial problems have been ironed out, make a before and after snapshot of helpdesk calls to show the reduction in IT support costs. Extra uptime for end users can be translated into additional sales or improved customer service. The results will be significant enough to convince management that a secure desktop is less expensive to support and has added productivity benefits for users in exchange for minimal IT administrative effort and cost.

While these programmes may benefit tech-orientated employees in large companies like Google, for most organizations, passing responsibility for IT purchasing decisions to users, which in turn determines business policy, isn’t likely to be the best way forward.

When friends or colleagues ask for advice about purchasing a new notebook, what criteria do they usually give as a priority? Looks, style and other desirable ‘must-haves’ often outweigh technical considerations, such as whether the device has the necessary capabilities to run line-of-business software, if it can be supported by IT or whether the build quality is likely to make it durable enough for business travel.

Similar factors often come into play when users make decisions about what software to install on their work devices, with little understanding of the complex problems that may arise if software is downloaded from untrusted sources, left unpatched or causes a conflict with a line-of-business application.

Consider the current malware situation on Windows. Most infections result from poor decisions taken by users on what constitutes a genuine security update, an application that’s trusted and required for business purposes or being duped into clicking links that redirect to sites with drive-by downloads.

Now, with changes to the security model in Vista and Windows 7 that make the OS easier to use without administrative privileges, and with some help from third-party utilities such as Avecto Privilege Guard, IT departments can ensure that only qualified technical personnel are able to make changes to core system configuration. Standard user accounts reduce the number of security incidents, malware infections, calls to the helpdesk and the frequency at which operating systems have to be reinstalled.

While also limiting flexibility from users’ perspectives, the advantages of least privilege security can often be justified by lower total cost of ownership and the necessity to comply with regulatory codes. If required, flexibility can be handed back to users by deploying applications stores (app stores) and virtual machines (VMs), taking much of the risk out of installing software by protecting key system configuration.

Most users don’t know what’s best for the business, and neither should they be expected to. Complex security decisions or determining the best solutions for business problems must be taken in consultation with all the stakeholders. In the past, IT often dictated what devices and software would be supported, but this should always be a two-way process, involving users and conducted with a thorough understanding of business needs.

Citrix has engineered GoToMeeting so that it doesn’t require any special privileges to install. That may come as a surprise to some system administrators, as it’s often assumed that admin rights are required to install and update the software. One exception is that administrative privileges are needed to install GoToMeeting’s recording codec, but if you don’t need to record a meeting, you’re good to go without it.

If you’ve configured application whitelisting to provide an extra layer of defence, you’ll need to make the necessary exceptions so users can install and update GoToMeeting. Creating rules for Windows 7 AppLocker to allow GoToMeeting to run needs a little preparation because of the slightly convoluted nature in which GoToMeeting installs and runs.

Table 1 - GoToMeeting Executables and AppLocker Rules

Rules will be required for 5 executables as shown in Table 1. Assuming you’ve already enabled AppLocker in Windows 7, I won’t explain here how to create rules, as no doubt that’s something you already know how to do. A good primer can be found at http://technet.microsoft.com/en-us/windows/dd320283. Suffice to say that following best practice, you should configure publisher rules for the GoToMeeting runtimes wherever possible. Figure 1 shows how the file name on disk and the file name displayed in the AppLocker wizard differ, adding some confusion to the process.

For the purposes of adding the GoToMeeting runtimes to AppLocker, you’ll find most of the executables located in the logged in user’s TEMP directory (%username%\appdata\local\temp). You can either enable AppLocker and add a rule for each executable as it’s blocked or install GoToMeeting with AppLocker disabled and then run the Automatically Generate Rules wizard and allow AppLocker to discover the necessary runtimes. The appcore executable isn’t signed, so you’ll need to create a file hash or path file rule to prevent AppLocker from blocking it.

Figure 1 - An AppLocker publisher rule for g2m_download.exe

Once rules to allow the 5 executables listed in Table 1 are added to AppLocker, you should find that users can join and host meetings. If you’re using a mix of Windows versions, Privilege Guard can manage application privileges and implement whitelisting in XP and later so that one set of rules are applied to all your Windows systems.

Use Virtualization to Solve Problems of Privilege

If a user is required to host meetings on a regular basis, with GoToMeeting or a different service, make sure the software is set up in advance and works on their local desktop. For users that might need to join meetings at short notice using unknown services, consider deploying Windows 7 XP Mode – or other virtualized desktop – so that if necessary, client software can be quickly installed without any intervention from IT.

According to Microsoft’s latest Security Intelligent Report, which gathers data from the second half of 2010, Windows 7 had an infection rate of 3.8 per 1000 computers compared to 15.9 and 7.6 for Windows XP and Vista respectively. However, the figures for Windows 7 show approximately a 30% increase in infection compared to the first half of 2010.

So does this mean that Windows 7 defences, such as UAC, are less effective than 6 months before? It was only going to be a matter of time before malware authors changed tactics. It was the norm pre Vista for users to log in with administrative privileges, so most malware assumes that it will run with admin rights inherited from the user to compromise a device.

When UAC is enabled, users (or Protected Administrators in UAC terminology) run with a restricted security token and explicit permission must be given to elevate a process to run with admin privileges. Windows 7 attempts to reduce UAC prompts by permitting some system components to run with elevated privileges without requiring users to give permission. This leaves malware writers with several choices:

• Design malware to run without elevated privileges
• Fool the user in to permitting malware to run with elevated privileges
• Use UAC auto-elevation to gain administrative privileges
• Exploit an unpatched or zero-day vulnerability to elevate privilege

Malware that runs as a standard user can’t ‘own’ a system completely, but it can do enough damage to disrupt the normal functioning of a logon session and steal information, which is the primary goal of much of today’s malware. The last three methods are much harder to pull off.

While enterprise users are likely to have different default settings than a home user, although this is not always the case, preventing malware from running in a standard user session should be high up your list of priorities as hackers adapt their wares for least privilege environments.

All supported versions of Windows have built-in application whitelisting technology that can be used to prevent untrusted software running in a user session. As malware infection methods evolve, signature-based antivirus solutions can’t be relied on to provide protection against the thousands of new malware variants that appear every day.

The rules in Privilege Guard are extremely flexible and can be used to elevate specific applications that trigger UAC or elevate all applications that trigger UAC. For instance, the screenshot below shows an application definition that will only fire when task manager attempts to launch with UAC.   

Task Manager Elevated

To capture all applications you would simply change the file name to *.exe and remove the publisher rule. Leaving the publisher rule in place would allow all operating system applications that trigger UAC to be elevated. Privilege Guard’s integration with Windows security catalogs enables the publisher rule to be used for operating system files, which are not signed directly by Microsoft. This topic was covered in a previous post. 

Privilege Guard can optionally prompt the user before elevating or running an application. In many situations you may want an application to elevate silently, without notifying the user. However, when the user is making a conscious decision to elevate an application it is often a good idea to prompt the user first. The screenshot below shows a policy that has been defined to elevate task manager when it triggers UAC. 

UAC Policy

In this example the task manager application has been added to an application group named All Signed UAC Apps. This would allow you to show a different prompt for signed and unsigned applications, as you may want the warning to be more severe for unsigned applications. You may even decide that a user is not allowed to elevate unsigned applications and indstead show the user a blocking message, which will prevent the application from launching.

The policy we have defined in this example will not elevate task manager until the user triggers a feature in task manager that requires administrator privileges, such as clicking the Show processes from all users button. When the user attempts to access an administrator feature in task manager then they will first be prompted with a message, as shown below. You may fully customize this message and even replace the banner with a corporate image. All of the text in the message is configurable, including full multi-lingual support. You may optionally ask the user for a reason or force them to re-authenticate, which have both been included in the example message below. 

UAC Replacement Message

The UAC rule is an extremely effective way of configuring specific or generic rules that only trigger elevation when an application requires administrator privileges. This effectively replaces UAC with a more flexible solution that is configured and mananged centrally through policy, without giving the user access to a local administrator account. Combined with the end user messaging capabilities in Privilege Guard the UAC rule can be used in a wide range of scenarios to elevate, block or monitor access to privileged applications and tasks on Windows 7 (or any other Windows operating system that supports UAC).

Situations will always arise where the driver for a device is not available as part of Windows 7 or Windows Update, so if your organization has non-standard devices which users should be able to install without intervention from IT, there are several options for realizing this. Drivers should be included as part of your company’s standard OS deployment image, but where that’s not possible, the DevicePath registry value can be set so that the driver store can be updated with drivers located in custom directories.

When a new device is connected to Windows 7, the OS searches Windows Update for a suitable driver and failing that, the local driver store. If neither location turns up an appropriate driver, the last step is to search the path(s) specified in the DevicePath registry value.

In Windows 7, paths listed in the registry are considered trusted and standard users can pre-stage and install drivers from those locations. Any drivers you place in directories listed in the DevicePath value must be signed with a certificate trusted by the devices on which the drivers will be installed.

To add additional search paths to the DevicePath registry value:

1. Type regedit in the Search programs and files box on the Start menu and press CTRL+SHIFT+ENTER to start Registry Editor with administrative privileges.
2. Locate the DevicePath value under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion.
3. The default search path is %SystemRoot%\inf and you can add additional paths by double-clicking the DevicePath value in the right pane of Registry Editor to modify the string and add new paths separated with semi-colons. For example to search the default local path and a network location, in this example \\server1\drivers, the string might look as follows: %SystemRoot%\inf;\\server1\drivers

Registry Editor showing the DevicePath registry value

You could also consider making network locations available offline so that notebook users can install drivers when not connected to the network.

Windows 7 includes a number of security enhancements to help secure the desktop, including User Account Control (UAC) and AppLocker. I have posted about both of these technologies in the past, and although both are welcome additions to Windows 7, they can fall short when striving to deploy the least risk Windows 7 desktop.

If you are seriously considering UAC then you should change the default configuration to always prompt. The downside is that users will always be prompted when an application requires elevation, but the security risks associated with leaving UAC at its default setting in Windows 7 have been well documented. Regardless of the configuration setting of UAC, you will still be surrendering control of the desktop to the end user, because UAC requires the user to either log on with local admin rights or to have access to an account with local admin rights.

In order to create the least risk Windows 7 desktop users should log on with a standard user account and not have access to an account with local admin rights. If a user requires access to applications that require local admin rights then a solution like Privilege Guard will provide you with the granularity to assign these rights directly to the applications that require them, avoiding the need to give up complete control of the desktop to the user.

In addition to ensuring users log on to their desktop with a standard user account there are still more steps that should be taken to create the least risk Windows 7 desktop. Many of these steps may be obvious, but are still worth a mention, such as anti-virus protection at the endpoint and the use of Group Policy to harden many elements of the desktop configuration. For more information on Implementing Windows Security with Group Policy you will find a white paper by Derek Melber, Group Policy MVP, in the resources section of the Avecto website.

For those that are truly serious about locking down the desktop there is one last step that can be taken, which is application whitelisting. Many organizations are hesitant to adopt this approach, as there is a fear that the amount of time to configure and maintain such a solution outweighs its benefits. This is not necessarily the case and depends on the approach you take to application whitelisting. If you take a purist approach and build up a database of hashes for every application then there is no doubting that the solution can become time consuming and costly to maintain, but there are more pragmatic approaches to application whitelisting that can provide the same security benefits with far less ongoing maintenance.

AppLocker is available with Windows 7 (assuming you are using the Ultimate or Enterprise editions), which provides a Group Policy based application whitelisting solution. I have written about the pros and cons of this solution in a previous post, but I strongly recommend that you assess its capabilities, as it may be adequate for your environment, and it’s a big improvement over its predecessor, Software Restriction Policies.

If, however, you feel that AppLocker lacks the flexibility and control that you require then Privilege Guard’s application control capabilities provide a number of benefits over and above AppLocker, including the option of being either user or computer centric, whereas AppLocker is computer centric. The ability to block an application or simply warn and audit, enables Privilege Guard to handle more demanding scenarios. With broader application support, corporate end user messaging, a more flexible rules base, and the ability to deal with privileged applications, including software installers, Privilege Guard is the ideal solution if you are looking to implement the least risk Windows 7 desktop.

For more information, refer to The Least Risk Windows 7 Desktop.

AppLocker can ensure that users are only allowed to run authorized executables, installer packages and scripts. It provides a good selection of rules, including filename, publisher and file hash. In addition, it is possible to identify applications based on their file properties, such as product name and version, although this capability is restricted to signed applications.

The lack of support for management consoles and control panel applets, introduces a slight security concern, as unauthorized snap-ins and applets may be launched by the user. Other areas of Group Policy can be configured to hide control panel applets, but this does not stop a rogue control panel applet from actually running. Management console snap-ins can also be controlled through Group Policy settings, and although this does go further than superficial hiding of snap-ins, the whitelisting of third party snap-ins could prove challenging, so it’s a shame that AppLocker can’t control snap-ins through the restriction of msc files.

Although AppLocker can handle software installation packages, a high proportion of software installers will require local admin rights to install. Granting local admin rights to a user will make any attempt to control application execution a futile undertaking, as the user will effectively have complete control over their desktop, and so the white listing of software packages with AppLocker is severely limited.

Where AppLocker really disappoints is in its end user experience. The end user message that is displayed when an application is blocked can’t be configured, and so the IT department are not able to convey a meaningful message to their user base when an application is blocked. This is further compounded by the lack of any method for a user to request access to an unauthorized application. It’s highly unlikely that the IT department will get application control policies configured correctly first time, and so the lack of informative messaging and a user feedback mechanism will make the ongoing fine tuning and maintenance of policies more challenging.

The application of AppLocker to more advanced users, such as technical users or laptop users, could prove problematic, as applications can only be blocked, which may prove too restrictive and lead to productivity issues. The ability to warn and audit, as opposed to blocking, would have made it possible to apply AppLocker policies to a much broader range of users, but this capability is sadly lacking.

As with most of Microsoft’s built-in system management tools, AppLocker provides no reporting capabilities, which could make it difficult to fully assess the impact of the applied policies.

There is no doubting that AppLocker is a big improvement over Software Restriction Policies, but it still falls short in a number of areas, which may restrict its adoption to smaller implementations of task based workers, where users require little flexibility in their job role. As a user’s requirements become more complex, AppLocker could prove difficult to apply without severely compromising an end user’s productivity and creating a burden on the IT department to constantly update policies.

As many organizations look to migrate to Windows 7, it is an opportune time to review user privileges.  User Account Control (UAC) was introduced by Microsoft in Windows Vista, and it has remained much the same in Windows 7, albeit with a few minor tweaks to its default behavior. Although UAC is a welcome addition to Windows, it really doesn’t provide a corporate solution to least privilege.

Here are 10 reasons why Privilege Guard provides a more suitable solution for the corporate environment.

1. Policy Driven Approach

UAC is a user driven approach to least privilege, in that users make the decision on whether an application should run with administrative rights. Privilege Guard, on the other hand, takes a policy driven approach, where the IT department has complete control over which applications run with administrative rights. It is tightly integrated with Active Directory Group Policy, so no additional backend infrastructure is required to deploy Privilege Guard policies.

2. Standard User Account

UAC requires the user to either logon with a local administrator account or to have access to a local administrator account, which gives the user too much control, leading to deliberate or accidental misuse of these privileges. Privilege Guard enables all users to logon with standard user accounts, as elevated rights are assigned directly to the applications that require them, without the user requiring access to a local administrator account.

3. Granular Privilege Control

UAC can only assign full administrative rights to an application, whereas Privilege Guard can assign granular privileges to individual applications, including, but not limited to, full administrative rights. With Privilege Guard, custom access tokens may be defined, enabling granular control over the groups, privileges and integrity level within an access token.

4. Privilege Inheritance

Once an application is assigned administrative rights with UAC, all child processes of that application will automatically inherit those rights, and there is no way to override this behavior. In Privilege Guard, privilege inheritance may be defined on a per application basis, ensuring privileges are only inherited where it is absolutely necessary. In addition, Privilege Guard will force standard user rights on the common file dialog that many applications utilize to allow a user to open or save files. This dialog has full explorer capabilities, so it is important to revoke administrative rights from this dialog, to ensure that deliberate or inadvertent modification of files in restricted operating system and application directories is not possible.

5. On Demand Elevation

Although UAC does provide an on demand elevation facility through the “Run as administrator” shell context menu, the requirement for a user to have an administrator password makes this facility inappropriate for most corporate users, with the exception of real system administrators. Privilege Guard enables a custom shell menu item to be defined, which may be applied to all or selected applications. This on demand facility functions under a standard user account, without the need for an administrator password. In addition, the user may be prompted with a custom message and optionally be asked to provide a reason for their actions, which is audited. Users can also be forced to re-authenticate before elevating an application, providing an extra level of security and discouraging a nonchalant attitude.

6. Application Support

UAC may be invoked for executables and installer packages, either because an application is deemed to require administrative rights, or the user has launched the application via “Run as administrator”. In addition to executables and installers, Privilege Guard can also manage the privileges assigned to individual scripts, including batch files, WSH scripts and PowerShell scripts. For more advanced users, Privilege Guard can elevate management console snap-ins, without giving the user elevated rights over the entire MMC. Privilege Guard can also handle the installation of authorized ActiveX controls.

7. Auditing

An important aspect of Privilege Guard is the ability to provide a comprehensive audit trail of each user’s actions. This audit trail may be vital to satisfy regulatory or internal compliance initiatives. Privilege Guard logs detailed application and policy information, including the end user’s reason for elevating an application, where applicable.

8. Privilege Monitoring

Privilege Guard includes a privilege monitoring capability, which may be used to discover any applications that require elevated rights to function. This capability is often used in the pilot phase of a least privilege project to identify the applications that need administrative rights to run. Once identified, applications may then be added to Privilege Guard policies, enabling these applications to function under a standard user account, without the need for user intervention. Privilege Monitoring may also be used in a live environment to provide application forensics of all privileged operations, including details of access to the file system, registry, kernel objects and interaction with system services.

9. Custom End User Messaging

The end user experience is often over-looked, and yet this can be crucial if a least privilege environment is to be accepted by the user community. Unlike UAC, which shows a fixed message, Privilege Guard provides a fully customizable messaging facility, enabling any number of custom messages to be defined. The IT department has full control over when a message should be displayed, whether a user should be forced to re-authenticate and whether they should be asked to provide a reason for their actions. All of the text in these messages may be customized, including full multi-lingual support. It is also possible to block a user from running a privileged or unauthorized application, and in this scenario the user can be provided with the ability to email a request to the help desk to run the blocked application.

10. Supported Platforms

Although many organizations are looking to make the move to Windows 7, other versions of Windows, such as XP and Vista, will continue to be prevalent for many years. Privilege Guard provides the same capabilities across all Windows platforms, making it possible to implement the same solution in mixed environments, and take the solution forward to during a Windows 7 migration.