Product Reviews

Keep Power Users Under Control

PolicyMaker Application Security lets you apply specific, application-level privileges.

• By Bill Heldman
• 10/01/2006

Engineers and software developers present a special challenge for IT managers.

Unlike others in the workplace, these groups require admin privileges to do their jobs -- a problem that can really complicate management for PC and server administrators. Group Policy Objects (GPOs) and their associated management interfaces -- the Group Policy Management Console (GPMC) and the Group Policy Object Editor (GPOE) MMCs -- only get you part of the way there.

PolicyMaker Application Security 2.0 REDMOND RATING Documentation 15% 9 Installation 10% 7 Feature Set 35% 8 Performance 30% 8 Management 10% 7 Overall Rating: 8.0 —————————————— Key: 1: Virtually inoperable or nonexistent 5: Average, performs adequately 10: Exceptional

If you're a full-time GPO manager, you probably mastered GPOs a long time ago. Still, you probably can't send a single policy to a group of users to increase their privilege for a single application. You can decrease privileges all you like, but increasing them is tough.

For example, software developers using Visual Studio need advanced rights to compile applications. If you're like most administrators and simply allot them full administrative rights, you set yourself up for the probability of completely crashed machines at the close of the day.

PolicyMaker Application Security effectively limits a user's capability, while simultaneously granting the permissions needed to run applications. DesktopStandard calls it "least-privilege." The tool is now in version 2.0 (version 3.0 will support Vista).

Why is this so important? According to industry reports, power users and admin-level users are the ones who leave the door open to 98 percent of viruses and malware on the local machine. It may not be Sally in the accounting department who can create the most trouble. It might be Bob, the senior programmer in your applications development unit.

There are two components to PolicyMaker Application Security. The first is a GPMC and GPOE snap-in, the second is a client component. The client component is deployed as an .MSI. It acts as a driver on the local computer, monitoring the Resultant Set of Policies (RSoP), listening to process launches and checking them against any PolicyMaker privilege rules.

The client makes this happen by managing the security token for the user, elevating his privileges for that application and only that application. This has a positive effect in three ways:

• It doesn't require secondary accounts
• It doesn't increase the security exposure of the computer
• Applications that write to HKEY_CURRENT_USER run as the authenticated user

Living by the Rules
There are many ways to set up PolicyMaker rules (see Figure 1). You can target an application based on its program file path, a simple hash of the file, all of the applications in a given folder, applications targeted by an .MSI file path or by installed ActiveX components.

Figure 1. Select rules from a list of categories.

If you set up a rule based on its file path, for example, the resulting dialog lists various supported applications. It will also list functions you may want to control (and points out any different service pack elements). For example, suppose you have Web programmers who need to work extensively with data that traverses the Windows Firewall. Those programmers belong to the WebDev OU.

You would set up this rule to elevate the Windows Firewall security context and denote the WebDev OU. You could also establish various permissions like "Replace a Process Level Token," or even apply filters to rules (see Figure 2).

Figure 2. There is a list of filters you can apply to your rules as well.

Once you're finished, this policy becomes a part of whatever Group Policy you're working with. It will ship as part of the GPO to those OUs, domains and sites (even single users) assigned to receive it. Upon receiving the GPO, the PolicyMaker client sees that it has to elevate permissions, apply additional privileges or introduce a filter for a given program.

In native Windows GPOs, there are more than 1,700 individual policies you can set within GPOE. You can also stack them so a given set of users may have an RSoP that is different than what you expect. Add to that the complexity of different user needs -- even though they may work side by side in the same department -- and you can see what a daunting task it is to administer GPOs. PolicyMaker does indeed give you more arrows in your quiver, but doesn't necessarily make you a better archer. You still have to determine which rule set will work best.

One of the best things about PolicyMaker is its ability to "shatter-proof" a computer. Windows is a message-based system. Programmers don't write code that manipulates Windows -- they write code that passes messages to Windows asking it to perform a certain way.

Hackers can pass messages to break a system, without even having to worry about the security context. Because message passing is at the heart of Windows, a well-crafted message or two could "shatter" Windows. PolicyMaker has a process-isolation rule that can "shatter-proof" a computer.

Ups and Downs
The documentation for PolicyMaker Application Security is first-rate. It includes two appendices at the end of the user guide for first-timers wanting to learn more about GPOs. I particularly liked the "I want to …" section of the documentation. For example, your question might be "I want to inoculate against shatter attacks." The answer would be "Select any type of rule, then enable Process Isolation (ShatterProof) in the administrative template."

What I didn't like was the process I had to go through to get the product licensed. As per the well-written instructions (complete with helpful screen shots) you install the code and launch GPOE. Next, you go through a mini Q&A session to establish how many OUs and possible users you have. You send the results to an XML-based file, e-mail it to DesktopStandard and you're sent back an unlock key. It took me a week, plus the compulsory conference call, to get my 20-node evaluation license.

When companies like Oracle are putting all of their software on the Web completely unlocked, a complex licensing methodology becomes a hindrance. To be fair, when I queried the marketing folks, they said, "Hey, if someone just calls us up, we can get them licensed and out the door." Nevertheless, the licensing methodology could be simplified.

At $27 per node (including the cost per node for premium support and upgrade assurance), it also seems pricey. You'll want to run a cost-benefit analysis to see what kind of savings you'll realize by being able to apply application-level permissions and privileges for certain groups.

Keep in mind that you won't need this kind of tool for your run-of-the-mill user. This is for securing power users, so it's not as though you'd be looking at a million-dollar deployment. Still, you'll have to look at the cost versus the payback of reducing power-user headaches.

If you're in a larger enterprise where desktops are locked down as a matter of corporate policy, PolicyMaker Application Security offers a way to efficiently dole out heightened privileges to those who truly need it.