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.

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.

Running up-to-date anti-virus software, and keeping Windows and other software updated with all of the latest security patches, should prevent infection from most known malware threats. However, the risk of a zero-day attack that includes a kernel-mode rootkit continues to pose the most serious security threat. The ability of a zero-day rootkit to hide itself from security software can make subsequent detection and removal extremely difficult, often resulting in re-imaging of the operating system, assuming that it is even possible to detect the malware infection. The fact that a kernel-mode rootkit could go undetected makes it difficult to fully assess the true scale of the problem.

One important step that can be taken in the fight against zero-day rootkits is to ensure that users log on to their computers with a standard user account. Most kernel-mode rootkits will simply fail to install when the user is logged on with a non-administrator account, as the successful installation of the rootkit will require write access to a secured area of the HKLM hive of the registry. To install under a standard user account the malware would need to discover and then exploit one or more vulnerabilities in the operating system, in order to gain higher privilege levels, making it much more difficult for the malware to infect or spread.

Avecto Privilege Guard enables organizations to implement least privilege, by ensuring users log on with standard user accounts and elevating the individual applications that require privileged access. Any zero-day attacks that are not detected by the anti-virus software will run with the user’s standard rights, making it difficult for the malware to compromise the kernel. Although least privilege can’t protect against all malware threats, it is an extremely effective line of defense against stealthy and persistent threats that attack deep inside the operating system.

On a final note, I would like to mention the innovative new technology that our partner McAfee launched at their Focus11 event in Las Vegas. McAfee DeepSAFE, which was jointly developed with Intel, enables McAfee to build hardware assisted security products. The DeepSAFE technology sits below the operating system, allowing it to detect hidden threats, such as stealth rootkits and Advanced Persistent Threats (APTs). McAfee Deep Defender is the first product to utilize the DeepSAFE technology and is managed with McAfee ePO software. McAfee Labs state that the stealthy malware threat is escalating and that they detect 110,000 new unique rootkits each quarter.

Here at Avecto we are delighted to be working closely with McAfee and we will soon be launching our ePO integrated version of Privilege Guard. I believe that the combination of least privilege with Privilege Guard and hardware-level protection with DeepSAFE, provides a major step forward in the fight against kernel-mode rootkits and other stealthy malware.

Technical personnel sometimes require access to domain controllers, maybe to perform maintenance connected to backup, patching or a one-off task. This leaves security administrators with something of a quandary, as most of the work likely to be carried out requires full administrative access to the DC, and in turn the crown jewels – Active Directory.

Let’s make it simple and start off by saying that it’s not possible to separate AD and administrator permissions on a regular DC. If you need to grant a user domain administrator permissions to complete some work on a DC, you must trust that person with full access to the AD domain. Read-only domain controllers (RODCs) do exactly what they say on the tin and host a read-only copy of the Active Directory database. Wherever possible you should deploy RODCs, as any domain user can be given permission to install and manage the server without privileged access to Active Directory.

Windows IT professionals often assume that the built-in Server Operators group in AD gives the equivalent of local administrator access to DCs without elevated rights to Active Directory. This is not strictly true and any kind of administrative permission on a DC can result in the user gaining privileges to AD. All built-in AD groups that end in ‘Operators’ are legacy groups and shouldn’t be populated unless you have an application that requires it. For example, if you need to grant permission to perform backup duties, create a new group and assign rights as necessary.

One approach you could adopt to grant admin privileges to DCs is to issue a unique username and password each time access is requested. The credentials are assigned to a technician for a given period of time and for an agreed piece of work. This information is recorded and permissions revoked at the end of the allotted session. Setting up the user account and recording the necessary logon session details is often done manually, although can be automated. The person requesting access is responsible for anything that happens during their logon session. Nevertheless, you still need to trust that person with Active Directory.

Depending on the type of work being carried out, a 3rd-party solution, such as Avecto Privilege Guard, could be deployed to allow a standard user to run only pre-approved applications with elevated privileges, greatly reducing the risk involved. Even if a technician must perform a task regularly on a DC, think twice before granting permanent permissions to sensitive production systems and always make sure that all actions are audited.

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.

Signing policies from within the Management Console

Use an exported PFX file to sign a Privilege Guard policy

Delegated Policy Management
Signing policies is achieved through the Privilege Guard Management Console from the right click menu on the ‘Privilege Guard Policies’. Any policies that have previously been signed cannot be edited unless you know the PFX password. This prevents any other domain or local administrators from adding or implementing unwanted policy settings, either within Active Directory or on the local endpoints.

Password must be entered before editing a signed policy

Cached Policy Assurance
The signatures embedded into deployed policies verify that policies stored in the local cache have not been tampered with, adding an extra layer of security on endpoints.

Three Modes of Operation
The Privilege Guard Agent can be installed in one of three operational modes, depending on the level of signed policy enforcement required:

1. Certificate Enforcement Mode – The agent will load correctly signed policies. Unsigned or incorrectly signed policies will not be loaded, and an error will be audited.
2. Certificate Warning Mode – The agent will load correctly signed policies. Unsigned and incorrectly signed policies will also be loaded, but a warning will be audited.
3. Standard Mode – The agent will load both correctly signed and unsigned policies. Incorrectly signed policies will also be loaded, but a warning will be audited.

Policy Auditing
New events have been added which audit all policy activity on the client, including the source, version and security status. Depending on the agent installation mode and state of the policy, the event number and severity will be audited as follows:

New policy auditing events in version 2.8

Signed policies significantly enhance the security of Privilege Guard by restricting which administrators are allowed to modify centrally or locally managed policies, and ensures that cached policies have not been tampered with or overwritten.

– A new application groups view
– A choice of application views
– Inline filtering and highlighting of applications

New Application Groups View

You can now view all application groups in a single view, by selecting the ‘Application Groups’ node in the navigation tree.

Choice of Application Views

There are now three different views for displaying the applications for all application groups or within a particular application group:

1. Summary View – this view shows a summarized description of the matching rules for each application in the group. Only the applied rules are displayed and icons are displayed under each application to show which advanced options have been enabled.

Summary view of all application groups

2. Light View – this view is similar in style to the summary view, but the light view shows only the description of each application within the group.

Light view of all application groups

3. Detailed View – this view shows a detailed list of all application rules and advanced option settings. Color coding is used to clearly indicate which rules and options are being applied.

Detailed view of all application groups

Inline Filtering and Highlighting of Applications

There is now an inline filter control, which allows you to refine the applications being displayed in each view, based on the text you enter into the filter edit box. Only applications that match the text (based on any property) are shown, and the matching text is highlighted.

Instant filtering and highlighted results

The new application group enhancements allow you to quickly locate and identify applications in your policies.

The very nature of a privilege management solution means that it elevates the privileges of processes. In the majority of cases these elevated processes will not provide the user with a way to interfere with the privilege management solution itself. However, in some situations you may want to allow more technical users to elevate command prompts and system management tools, such as the Services console and Registry Editor. At this point, there is a risk that the user could use these tools to tamper with the privilege management solution.

To eliminate this risk, the new anti-tamper mechanism in Privilege Guard dynamically inserts a special protection group into the access tokens of all elevated processes. This protection group is then used to restrict access to the Privilege Guard software, configuration settings and cached policies, relying on native NTFS security to enforce it. In essence, any process that has been elevated by Privilege Guard has no more rights than a standard user if it attempts to interfere with the Privilege Guard solution.

To demonstrate the anti-tamper mechanism in action, let’s see what happens when the user is given access to an elevated command prompt. Although the command prompt below is running with full administrator rights, any attempt to stop the Privilege Guard service, change directory to the Avecto program data directory or tamper with the software binaries, results in an access denied error. Try doing this with any other privilege management solution and don’t be surprised to see a very different result!

Anti-tamper Protection - Command Prompt

Since the anti-tamper mechanism relies on native NTFS security to restrict access based on the special Privilege Guard protection group, it ensures that this protection extends to all elevated applications. For instance, in the screenshots below you will notice that the options to manipulate the Privilege Guard service in the Services console are disabled and any attempt to delete the Avecto registry key in the local machine hive using Registry Editor is denied. Both of these applications are running with full administrative rights, but are incapable of tampering with Privilege Guard.

Anti-tamper Protection - Services Console

Anti-tamper Protection - Registry Editor