eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Winternals Software’s Protection Manager 1.0 merges application privilege escalation and execution control into a single package that allows companies to provide proactive security by thoroughly locking down the desktop.
As we’ve seen with products from DesktopStandard and FullArmor, Protection Manager modifies an application’s security token, allowing legacy apps to run with administrative permissions while the user retains otherwise restricted permissions.
But Protection Manager also adds application execution controls that allow an administrator to create a whitelist of approved applications, while denying users the ability to run other unspecified applications-similar to functions provided by host intrusion-prevention products such as those from Bit9, yet more manageable and flexible than the Software Restriction Policies in Microsoft’s Group Policy.
During tests, eWEEK Labs found that Protection Manager’s privilege escalation functionality worked well, enabling us to run a number of applications that ordinarily don’t play nicely for restricted users. Protection Manager also provided a good set of tools for creating an application execution whitelist. Implementing this practice across a large enterprise will be a daunting task, however, likely leading to a lot of administrative effort-especially at first.
Pricing for Protection Manager, which started shipping in March, starts at $25 per managed desktop or $250 per managed server. There is also a $69 charge for the management console.
Flexible solution
Unlike DesktopStandard’s PMAS (PolicyMaker Application Security), Protection Manager operates outside Microsoft’s Group Policy framework, allowing great flexibility in the way policy can be assigned.
Protection Manager does tie in to Active Directory, however, so we could create Roles that included existing Organizational Units, Users, Computers and Groups. This allowed us to assign application permissions as needed, without altering the fundamental structure of our directory.
We liked the tools provided to help create File Sets-logical groups of applications for which permissions can be enabled or blocked. Administrators can apply per-application rules to allow, deny, run as administrator or run with limited privileges.
Unlike PMAS, Protection Manager adds only the administrator security token; it does not provide the ability to assign and adjust specific privileges. We found Protection Managers broad strokes sufficient for the applications we tested against, but administrators are likely to find situations where PMAS-like granularity is needed or desired.
To help organize security across many Roles, we found it helpful to create a base line policy of all commonly acceptable applications in our base client image. We then created and applied additional, highly specific policies to deal with applications used by subsets of our user population.
An agent must be installed on each managed client (agents can be installed only on Microsoft Windows 2000-, Windows XP- and Windows Server 2003-based machines), and Protection Manager provides integrated tools to push the agent to workstations in the Active Directory domain-provided the workstation can be contacted on the common Microsoft networking ports. We also needed to make sure the agent and central console could communicate on TCP ports 52388 and 52389.
From the console, we triggered a desktop scan, which indexes each managed workstations hard drive to inventory all found executables. This scan causes significant disk and CPU utilization on the client and is best performed outside peak usage hours.
The results of the scan are coalesced in the console’s Application Browser. During tests, the Application Browser offered multiple views of the thousands of executables found across our network, organizing applications according to file system location, company, signer, owner or host computer.
From the Application Browser, we could then click and drag groups of applications to a new File Set, specifying whether Protection Manager should identify applications by specific location, hash or signer. Unlike PMAS, Protection Manager does not offer privilege escalation for ActiveX controls or MSI (Microsoft System Installer) installation packages.
Flexibility to fine-tune on the fly
Protection Manager offers four modes of operation for every Role, allowing administrators to put policies in place while maintaining the flexibility to fine-tune them on the fly.
Disabled mode does not enforce policy at all and is strictly for use while building a Role; Silent and Interactive modes provide the ability to enforce some rules while logging activity (either silently or interactively); on the draconian end of the scale, Enforced mode applies defined rules and blocks untrusted applications, which are simply applications not specifically named in the Roles File Set.
From the users perspective, application privilege escalation occurs seamlessly behind the scenes. And when a user tries to engage an application blocked by policy, the user is shown a pop-up explaining what happened and is given a chance to send a policy exemption request to the Roles Delegator.
Delegators are administrators defined with dominion over a particular Role. When a user interacts with an untrusted application, the Delegator is automatically notified by an icon in the system tray that an application has been identified for action in a File Set. When getting started with Protection Manager, Delegators can expect a lot of notifications. (Seriously, it started getting annoying.)
Delegators can engage the console interface no matter what workstation they are currently sitting at. The only management difference we could discern when working at a remote workstation was that the contents of the Application Browser were not displayed.
We noticed an unfortunate side effect for remote workers tied to a role in Silent or Interactive modes, however. In these modes, whenever an off-site user started an untrusted application, the client agent attempted to contact the central console to check one last time for an updated policy.
Since the agent cannot contact the console, the user experienced a delay of application launch for 20 to 30 seconds. There is no warning that this will occur, so this problem is sure to lead to a flood of support calls from users complaining about system performance.
As some companies may leverage Protection Manager specifically for its ability to raise an applications permissions within a Least Privilege User Authority environment, we feel Winternals should add support for a fifth deployment mode that enforces specified rules while ignoring the use of untrusted applications. Winternals officials said they are considering this feature for future revisions.
Evaluation Shortlist: Related Products
Bit9’s Parity Creates an acceptable application whitelist but does not provide the ability to add administrative permissions for legacy applications (www.bit9.com)
DesktopStandard’s PMAS Is heavily tied to Microsoft’s Group Policy, so deploying policies is less flexible than it is with competing products, but it does provide more granular controls to target and elevate specific permissions (www.desktopstandard.com)
FullArmor’s IntelliPolicy Controls application rights, dictates desktop configuration and locks down USB devices (www.fullarmor.com)
Technical Analyst Andrew Garcia can be reached at andrew_garcia@ziffdavis.com.’