I Am the Software Über Admin!
SecureEXE locks down executables to help keep users out of trouble.
- By Roberta Bragg
SecureWave's SecureEXE can be set up to give
you the ability to control who runs what. Unlike
the Windows 2000 permission model, which too often
assumes every user is innocent until proven guilty,
SecureEXE assumes that all users logging on to
computers managed by the program have malicious
intent and removes their ability to run any code.
You must explicitly give them the ability to run
anything. They can't even log on and get their
desktop unless you've given them permission to
use the appropriate files in the OS.
If that sounds like a daunting task, it's not quite as bad as it seems.
Granting Run permission is sort of like assigning ACLs on groups of files,
instead of individual files. Part of your SecureEXE setup consists of
creating these file groups from installation CD-ROMS, applications correctly
installed on remote computers and manual listings. Once I got the program
installed in a clean test network environment, adding the ability for
all users to log on and run Win2K Pro took about five minutes.
|When users run software, the use is logged along with
time, location and access approval codes. The logs can be fetched
from any registered client computer and examined from the SecureWave
Management console. (Click image to view larger version.)
SecureEXE used that time to create a cryptographic hash of each executable,
.dll, and other files in the installation CD-ROM I386 directory at which
I pointed it. Each hash is placed in the SecureEXE database. Each collection
of hashes is organized into a file group. To give users the ability to
run the files, you must assign a group they're a member of to the file
group. When a user logs on, his computer receives a list of hashes for
each file group to which he's been assigned. If some action on his part
requires the code in a file, the SecureEXE client compares the stored
hash to a fresh hash made from the local file. Do they match? The file
can be run. They don't? The user gets an error message.
To fully deploy SecureEXE requires making a file group for each program
or set of programs your users need to use and then assigning the file
groups to groups of users who are authorized to use them. Deploying Office
XP? Make a file group. Want to let help desk personnel run some Resource
Kit utilities? Make a file group. Have home-grown applications? Build
another file group. Now comes the fun part: No user can run a program
unless she, or some group she's a member of, has been assigned to the
file group. Who's more powerful? Domain Admin? Enterprise Admin? Nah,
the SecureEXE Administrator is truly the Über Admin in your enterprise.
After setting up a few file groups with varying permissions, I installed
the SecureEXE client on my Win2K Pro system. I logged on as various users
and tried it out. It all worked as advertised. I was even able to give
specific users permission to install a driver that members of the Domain
Admins group couldn't touch.
SecureEXE can give you serious control over user activities in your network,
but does require extensive setup. Are there any vulnerabilities or problems
with the product? My experience with the product isn't deep enough to
offer an opinion. To deploy this product in your network requires extensive
effort and requires you to rely on the security of the database, user
caches of hashes, and the strength of its cryptography. Before deployment
I'd want to invest more significant effort in testing and gain more details
on its underpinnings.
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.