Keep Power Users Under Control

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.

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.