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.

UAC and Privilege Guard Comparison

In addition to the security benefits of least privilege there are also many operational benefits, as the cost of supporting the corporate desktop is dramatically reduced when the desktop is in a locked and well managed state. However, least privilege does bring its own set of operational challenges, which is why many organizations have struggled to embrace it.

Here are 5 of the most common operational challenges preventing organizations from moving to least privilege.

1. Legacy Applications

Many applications will not run under a standard user account. Although I refer to them as legacy applications, it will be no surprise that there are many newer applications that are simply badly written and require admin rights to run or function correctly. Most organizations have hundreds or thousands of applications, so it is common place to have a large number of problem applications that will fail to function correctly under a standard user account.

2. Basic Administration Tasks

Many users perform basic system administration tasks for themselves, such as connecting printers, adding plug and play hardware and defragmenting disks. This is especially true of laptop users, although it affects many desktops users too. Every organization will also have a group of advanced users, who need to perform more advanced system administration, such as managing disks and network adapters.

3. Software Installation and Upgrade

Although most organizations will have a centralized system for deploying software packages and updates, it is not unusual for this to be supplemented with some ad hoc software installation. As most software requires admin rights to install, this can be difficult to accomplish on a locked down desktop, where admin rights have been removed.

4. ActiveX Installation and Upgrade

One of the most challenging issues of moving to least privilege is the inability of a user to install ActiveX controls. Although there are obvious security benefits in preventing users from installing ActiveX controls, the inability of a user to install or upgrade authorized ActiveX controls for themselves is a major headache, as alternative deployment strategies are costly and time consuming.

5. Advanced Tools

We are left with one area, which I will categorize as advanced tools. These are applications that don’t fall under the legacy applications category, as they are applications that genuinely require admin rights to function correctly. We are usually referring to more technical users, such as software developers, who need to run debugging tools and other privileged applications.

The challenges I have outlined above are difficult to overcome using standard Windows policies and tools, as there is no mechanism to assign privileges directly to applications. In Windows a user is given either a standard user account or an admin account, which is the reason Avecto introduced the Privilege Guard solution. Privilege Guard makes it possible to overcome these operational challenges, as admin rights (or more granular privileges and rights) may be assigned directly to the applications that require them, with the user logging on with a standard user account.

In addition to supporting executables, Privilege Guard can assign rights to control panel applets, management console snap-ins, software installation packages and patches, batch files, windows scripts, PowerShell scripts and registry settings. It also integrates with Internet Explorer and allows authorized ActiveX controls to be installed under a standard user account. No other solution provides such broad application support, making the implementation of least privilege a realistic goal for every organization.

However, sometimes it is necessary to check the integrity of a file, and therefore most good application control solutions should provide additional capabilities for this purpose. In particular, you should expect a solution to provide support for both trusted publishers and file hashing.

A trusted publisher rule can be used to ensure that a set of application files have been signed by a specific vendor. If the vendor has not signed the application then the only other realistic option is to take a hash of the file, such as a SHA1. The only problem with file hashes is that they are difficult to maintain, as an update to an application will require a new set of file hashes. For this reason, checking the publisher is a much better approach, if the application has been signed, and hashes should only be used as a last resort.

This brings me on to Windows security catalogs, which is the subject of this post. If you check the properties of an application in the operating system, such as calc.exe, you will notice that the application is not signed by Microsoft. At first glance this would suggest that a publisher rule can’t be applied to operating system binaries, as they are not signed by Microsoft. Well that depends on whether your application control solution has built-in support for Windows security catalogs. All of the operating system binaries are indirectly signed by Microsoft. This is achieved by placing hashes of the operating system binaries into various security catalogs, which are then signed by Microsoft. If you’re interested in delving deeper then the catalog files can be found in C:\Windows\System32\catroot.

We built support for Windows catalog files into Privilege Guard 2.5 and the screenshot below highlights the publisher for timedate.cpl being identified as “Microsoft Windows” on Windows 7, even though the applet is not signed directly by Microsoft. On Windows XP the publisher will be set to “Microsoft Windows Publisher” for operating system binaries.

To understand the power of this capability, you could just as easily create a single rule to match any application binary that is signed by “Microsoft Windows”. This would be an extremely effective and secure way to whitelist all of the binaries that are part of the operating system, which would also include all future Windows updates.

So if you’ve ever wondered why the operating system files are not signed by Microsoft, now you know why, but more importantly I hope I have shown how application control solutions can provide a secure approach to identifying operating system binaries, which will require little to no maintenance of policies.

Although Event Forwarding didn’t start shipping until Windows Vista and Windows Server 2008, it is also available for Windows XP (SP2 and above) and Windows Server 2003 (SP1 and above).

Avecto have written a solution guide for setting up and configuring Event Forwarding, which is available for free download here www.avecto.com/resources.

1. Implement Least Privilege

If you are serious about desktop lockdown then you really need to adopt least privilege. If users are logging on with admin rights (or power user rights) then locking down the desktop becomes an almost impossible and thankless task.

If the only thing stopping you from implementing least privilege is that users need to run problem applications, perform basic admin tasks, such as connecting printers, or install approved software, then consider a privilege management solution. Privilege management solutions enable individual applications to be elevated under a standard user account, making it possible to remove admin rights from users.

2. Review and Secure Access Control Lists (ACLs)

The access control lists (ACLs) on files and registry settings should be addressed before you get too concerned with applying the various group policy settings that can be used to lockdown the desktop. Many of the group policy settings simply hide features in the explorer shell and other applications, and are not necessarily securing the underlying desktop build.

Assuming you have implemented least privilege, you should ensure that users only have read and execute access to the operating system files and installed applications. If any applications run from the network then make sure that write access is also restricted on the relevant network shares.

The modification of ACLs on files and registry settings can be centralized through group policy security settings. 

3. Restrict Software Installation

Probably one of the biggest security and stability threats to the desktop build is the installation of unapproved software. Implementing least privilege will remove a large percentage of unapproved software installations, as most will require admin rights to install.

However, this still leaves you with a couple of potential problems. Firstly, how do you eliminate unapproved software that doesn’t require admin rights to install? Secondly, how do you allow a user to install approved software under a standard user account? The first of these problems can be solved with an application control solution, which I will cover in the next tip. The second problem requires a privilege management solution, which I covered in the first tip, implement least privilege.

If you decide to invest in a privilege management solution then ensure that this solution can handle elevated software installations and the installation of ActiveX controls in Internet Explorer.

4. Implement Application Control

Many unapproved applications can run as standalone executables or install with standard user rights. In order to eliminate these applications from the desktop build you will need to consider an application control tool.

If you are looking for an application control tool for Windows 7 then you should seriously consider AppLocker, as this is a standard part of Windows 7 and may be managed centrally through group policy. If your desktops are running Windows XP or Windows Vista, or you have a mixed environment, then consider Software Restriction Policies (SRP), although it lacks the flexibility of AppLocker and is more difficult to manage.

If you find that SRP or AppLocker are not adequate then there a number of third party solutions available that provide flexible application control. Some privilege management solutions also include application control, which will enable you to utilize a single solution to control the applications that run and the privileges assigned to them.

5. Audit and Refine Lockdown Policies

In addition to compliance, auditing is crucial to refining lockdown policies. You are unlikely to implement a perfect set of lockdown policies on your first attempt, but don’t let this discourage you.

Ensure that the solutions you use for privilege management and application control have comprehensive auditing capabilities. Understanding which applications have run with elevated rights and those that have been blocked from running will enable you to fine tune your lockdown policies.

Look for solutions that provide good end user messaging, as this will eliminate end user confusion, when a user has been prevented from running a privileged or unapproved application. In addition, mechanisms that allow a user to provide a reason for requiring access to a blocked application can help to remove the end user frustration that may result from inadvertently over-locking a user.

Even if you could build your own deployment mechanism that matched or even surpassed the features in Active Directory Group Policy, there would still be one over-riding reason not to do so … most organizations already have an Active Directory in place, and they have carefully designed and built an infrastructure that is suitable for their environment. So why provide them with a proprietary system for your product that requires additional servers and all of the dedicated training, management and support time that is required to set up and maintain this new infrastructure.

First of all, it’s worth dispelling a common misunderstanding at this point. Active Directory Group Policy does not mean that your product is limited to the registry based policy settings provided by ADM and ADMX files. Group Policy is completely extensible, and you can develop a management console that plugs directly into the Group Policy Editor, which can save data in any format to the Group Policy Template (GPT) portion of a Group Policy Object (GPO). The GPT is stored on SYSVOL and therefore requires no change to the Active Directory schema. Put simply, your product can save a structured set of policies in an XML file, or any other format that takes your fancy, as opposed to being restricted to simple registry based policy settings.

Another common concern is the efficiency of using Group Policy. Understanding a little more about the inner workings of Group Policy, helps to dispel this concern too. Group Policy is a “pull” technology, and each product must implement a Client Side Extension (CSE), which resides … yes, you guessed it, on the client computer. Each CSE is notified when there has been a change to one or more GPOs that are of interest to the client or logged on users. It is the CSE that is then responsible for downloading its policy settings from Active Directory, as GPOs are not just transferred in their entirety to the client computer. In other words, if a product’s CSE has not been installed on a client computer then the policy settings for that product will never be downloaded from Active Directory. It is an efficient mechanism, and the versioning of GPOs ensures that GPOs only need to be processed by a CSE when there has been a change to the policy settings or a change in the GPO precedence rules.

I should also point out that organizations who use Novell eDirectory need not feel left out either, as ZENworks supports Group Policy too, and for smaller companies with no directory services in place, there is always local Group Policy.

I’ve never made the time to blog, but I’m going to make a special effort now, so I suppose we’ll see how it goes. I took the plunge with twitter a few months ago, and although I started well, my tweets fell off as the self-imposed pressures of a new software release mounted. Anyway, enough of the excuses and on with my first blog, and of course there will be a twitter link to this blog, so my tweets will be reborn too!

So I suppose an introduction to least privilege would be a good place to start my first blog, an idea that is not new, but is getting more serious attention in recent years, as companies look to improve security, reduce operational costs and adhere to various compliance initiatives. If you are looking to deploy a locked down environment then least privilege has to be the first step, otherwise your efforts will be worthless.

Least privilege is a simple concept, in that users and applications should be granted the most restrictive set of privileges in order to perform their role or function. In practice, privileges are assigned to users and not applications, which results in the user being granted the privileges required to run all of their applications. This leads to an obvious problem, in that it only takes a single application to require special privileges, such as admin rights, and the user must be assigned these rights.

Most corporate environments have hundreds or even thousands of applications, so it’s no wonder that admin rights are still prevalent in many organizations. The problem is further compounded by the need for many users to perform basic admin tasks, such as connecting printers, and performing basic software maintenance, such as upgrading an ActiveX control or launching a software updater.

So although the concept of least privilege is a simple one, turning the principle into practice is not quite as straight forward. It’s very easy to give a user a restrictive account, but to do so without compromising a user’s ability to perform their role effectively is another matter.

In future posts I will cover the drivers for moving to least privilege, best practices, and discuss the various tools and techniques that can be used to implement a least privilege environment. I will also cover the limitations of the built-in capabilities of the Windows operating system, which is why the Privilege Guard product was introduced.