Many years ago, users’ only access to company
data occurred through dumb terminals
to a mainframe. The data resided safely in
the data center, and the only way it might
physically leave that data center was on reel-to-reel
tape or large, heavy hard drives. By contrast, today’s users have multiple
access points to company data—for example, USB drives, floppy drives,
and even burnable CD/DVD drives. Dishonest employees can easily use
these points of access to steal sensitive data. If you’ve considered blasting
your users’ USB ports with hot glue, you aren’t alone. But perhaps
there’s a more elegant solution available to you.
The two products I investigate in this comparative review—Smart-
Line’s DeviceLock and ControlGuard’s Endpoint Access Manager—can
help you take back control of all those vulnerable access points. I’ve
focused on only two representative products here, but keep in mind
that other options are available, including functionality that Microsoft
introduced in Windows XP SP2—see the sidebar “A Snapshot of the
Endpoint Security Market,” for more information.
Smartline DeviceLock
DeviceLock Security’s installation starts with the execution of a typical
setup.exe file. However, I found the installation a bit confusing. The
installation wizard has two main options to choose from: Use the Service
+ Consoles option to install the DeviceLock service and management
consoles, or use the Server + Consoles option to install the server component
and the consoles.
At first, these options
look the same, but as
you can see, one is the
DeviceLock service
and the other is the
server product. The
first option is selected
by default, leading to
my confusion.
According to the
DeviceLock Manual
PDF guide, the
“DeviceLock Service
should be installed on
the computer so you
can control the access to devices on that computer.” Is the DeviceLock
Service required on the management server? I called the company to
ask for clarification. A friendly technician explained that the service is
necessary only if you want to protect USB and other endpoints on the
server. Otherwise, you can skip the service installation on the server and
deploy it just to the user’s PC. I find it a bit odd that the service is selected
by default, but apparently it’s provided as a convenience.
There’s also a Custom option. I used this
method to install the service and the server.
The optional DeviceLock Enterprise Server
component—which requires a SQL Server
back end—allows for the centralized collection
and storage of shadow data and audit
logs. If you have a SQL Server infrastructure,
ControlGuard recommends that you use that.
If you don’t have SQL Server available, the PDF
manual provides a direct link for downloading
SQL Server 2005 Express.
After the installation was complete, I was
presented with three separate consoles on the
desktop: DeviceLock Management Console
(a Microsoft Management Console—MMC—
snap-in), DeviceLock Service Settings Editor
(similar to the new tools that DeviceLock adds
to Group Policy), and DeviceLock Enterprise
Manager (recommended if you have a large
network without Active Directory—AD). These
consoles were a bit overwhelming, combined
with the product’s promise of Group Policy
integration.
To keep things initially simple, I started with
DeviceLock Enterprise Manager and remotely
installed the DeviceLock Service onto my test XP
machine. As I expected, the service wasn’t able
to install because the XP SP2 firewall was blocking
it. The DeviceLock Manual provides detailed
instructions for either opening the XP firewall
with the necessary ports or setting a specific
port for all DeviceLock communication. I used
Group Policy to configure
the XP firewall, and I was
able to install the service
remotely.
The DeviceLock Service
is also available in an
MSI format, so you can
install it through Group
Policy or SMS. I highly
recommend a structured
AD with hierarchal organizational
units (OUs), in
which users and computers
are taken out of the
default containers. This
setup helps you organize
and find user and
computer leaf objects,
and makes Group Policy
deployment much
easier.. I would place
a policy at the highest
All Computers OU, then
deploy the DeviceLock Service from there. There isn’t a built-in
automated method to deploy the client agent (as the ControlGuard product offers), so I had
to set up my own way to ensure that all desktops
had the DeviceLock
agent installed as soon
as they were added to
the domain. To do this,
I applied a Group Policy
to an OU containing all
the users’ computers.
Now, every time I add a
computer to the domain,
the client software is
installed automatically.
Figure 1 shows Device-
Lock’s smooth integration
with your existing
GPOs.
After I verified that
the DeviceLock agent
was running (it runs as
a typical NT service), I
used DeviceLock Enterprise
Manager to deploy
my first policy. This
simple process lets you
select specific AD users or groups, the date and time those users or
groups are permitted to access the device,
and even the specific user rights (i.e., Read,
Write, Format, Eject) allowed for each device.
You can secure not only USB ports but also
Bluetooth ports, CD/DVD drives, FireWire
ports, floppy drives, hard disks, infrared (IR)
ports, parallel ports, removable devices, serial
ports, tape drives, Wi-Fi access points (APs),
and Windows Mobile devices. When you
think of points of access, USB is probably the
first type that comes to mind, but data can be
compromised from many entry points. For a
listing of endpoints that DeviceLock protects,
see Table 1.
As soon as I attempted to access a USB
device on the XP client, a dialog box immediately
informed me that access was denied.
I tried to find a way around the policy but was
thwarted at every attempt. I even tried to stop
the DeviceLock service, but the Stop button
was disabled.
Integrating DeviceLock management with
Group Policy is a brilliant idea. After using
DeviceLock Enterprise Manager to play around
with policies, I decided to deploy a policy using
a Group Policy Object (GPO). Opening a new
GPO brings up a new addition called SmartLline
DeviceLock—not a simple administrative
(ADM) template but a fully functional GUI that
looks and feels just like the aforementioned
DeviceLock Service Settings Editor. Using this
screen, I was able to deploy endpoint security
settings to users’ computers just as I had done
through DeviceLock Enterprise Manager. If
you already have structured AD and Group Policy management procedures in place, I
highly recommend that you use this method
to deploy the settings.
As you apply policies to secure endpoints,
it can quickly become difficult to determine a
given PC’s actual settings. Because DeviceLock
is heavily integrated with AD and Group Policy,
it can take advantage of Microsoft’s Resultant
Set Of Policy (RSOP) tool.