Product Reviews

I Am the Software Über Admin!

SecureEXE locks down executables to help keep users out of trouble.

• By Roberta Bragg
• 10/01/2001

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.