A rather distraught software developer was accused of stealing data from his previous employers. The company claimed he circumvented the USB monitoring system when copying files to a flash drive because IT couldn’t find any evidence in the logs that the files had been transferred to the removable drive. As a software developer, he had admin rights on his PC and the company is now threatening legal action.

I don’t know whether the company has any legal basis on which to make such threats, but as has been said many times before, giving users administrative rights unleashes the potential to override Group Policy, Windows security and any other defensive measures you decide to put in place on your systems.

It’s in everyone’s interest to work with the minimum privileges required to carry out the job at hand, especially if users want to avoid being held responsible for a major security incident. The likelihood of inadvertently causing a devastating virus outbreak, installing unlicensed software or otherwise circumventing security policy is significantly greater if running with admin rights. As the risks are not usually taken seriously, it can help to illustrate what the consequences of a virus attack or other security incident might be, not only for the company but also the employee.

Someone who pressures the IT department to run with admin rights without good reason and then infects the network with a virus, not only causes downtime for themselves, but makes extra work for the IT department and frequently the consequences are felt by other employees, who see their own machines infected or network services become unavailable. You could compare it to calling the doctor when the symptoms are nothing more than a minor sniffle, wasting valuable resources and denying those who are really ill the vital help they need.

It’s important to communicate the effect that computer misadventures can have. Pose the question: Do you really want to be responsible for downtime that brings the organization to a standstill? Teach users to be good corporate citizens by giving real-life analogies of IT security problems and examples of the possible consequences should something go awry.

Microsoft provides a free utility which does just this – the Microsoft Baseline Security Analyzer, or MBSA for short.

Choose a type of scan or view previous scan results

The MBSA is designed to highlight potential security risks on endpoints and makes recommendations for remediation of these risks. Access to a local admin account is of course a high risk concern, and so this is one of the things it checks for.

Select your scanning options

It works by scanning each target endpoint for the number of entries in the Local Administrators group, which for any endpoint joined to a domain should only contain the Local Administrator user and the Domain Admins group. So if it detects more than two entries, it flags this in the graphical UI. From here you can drill into the report to display the actual group memberships.

Summary of all endpoint scan results

Summary of the scan results and details of the 'Administrators' test

In summary, you should have a good understanding of which users have admin rights before implementing least privilege. If you don’t already audit this, then MBSA can provide this information for you.

For more information and to download MBSA, visit the MBSA TechNet resource here.

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.

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.

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.

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.