The CyberGatekeeper server sits between the corporate LAN and remote-access entry point on the private side of a VPN or dial-up server. It doesn't inspect network traffic -- rather, it checks for policy compliance. When a remote user connects to the LAN, CyberGatekeeper checks the policies you set and the user machine simultaneously. If at any time during the VPN session the user does something to take his or her machine out of compliance, the server can cut the machine off in a few seconds.

Vendor Information CyberGatekeeper Suite 1.1, agent starts at $59 per seat; server: $6,500. InfoExpress, (650) 623-0260. www.infoexpress.com.

Because the device does not look at network traffic, a firewall and IDS infrastructure are still necessary. In my tests, at Real-World Labs® at Syracuse University, I used a Nortel Contivity 2600 as my VPN server and used the built-in Microsoft Windows 2000 PPTP client to create the secure tunnel. The server sat behind the private side of the Contivity.

Testing Compliance

The management interface is straightforward and simple to use. As administrator, your first task is to create the basic tests that will serve as the skeleton of your CyberGatekeeper policies. The tests can be configured to check the user's computer for process name, file sizes, file checksums, dates, version numbers, file presence, and configuration-file values using exact or wildcard values. You can also check for Windows registry keys and data, exact matches or binary equality (equal, greater than or less than), operating system version, computer name and IP address. In fact, you can check for any application.

You can perform multiple checks within a basic test, but all checks must be true for the basic test to be true. A basic test could be used to check whether the user is running the latest version of Symantec's Norton AntiVirus with the most recent definitions, for instance; the test could check whether all the Norton executables are present and running, whether the Norton MD5 checksum matches a known and clean value, and whether the version number in the definitions file is at least a certain value. If any of the checks are false, the basic test result is false.

You also can create compound tests -- groupings of basic tests. Unlike a test with multiple checks for which all must be true, with a compound test, if any single basic test is true, the compound test is true. In my setup, I wanted to make sure my users were running at least one of two firewalls. I created a compound test called Firewall_check comprised of a test for Zone Labs ZoneAlarm and a test for InfoExpress CyberArmor. As long as my users were running one of these firewalls, the test came back true.

InfoExpress also includes preconfigured tests for personal firewalls from Internet Security Systems, Network Associates, Symantec, Sygate, Tiny Software, Zone Labs and InfoExpress. Included in these tests are the executable path, process ID, registry entries and location of supporting library files. CyberGatekeeper also includes tests to look for antivirus software from Network Associates, Symantec and Trend Micro. Because CyberGatekeeper lets you test for "at least version X or higher," your users can be notified to upgrade to a new release without instantly going out of compliance. This is important because some antivirus vendors update their definitions weekly.

Creating Policies

As soon as your test situations are set up, you can create policies. A policy can require or prohibit the use of something, or it can let the user know if something is desired but not required. For example, a policy prohibiting certain applications could be used to save bandwidth: You could set a policy to prohibit your users from running Kazaa (a peer-to-peer sharing program) while connected to the network. To do so, you would create a basic test for Kazaa, then create a policy with the requirement to prohibit Kazaa. The "desired" option could be used to warn users that they need to upgrade or correct something soon, or risk being cut off at a later date.

Good News Easy to use. VPN vendor-neutral. Ships with preconfigured tests. Bad News Limited reporting capabilities. Creating tests may require some research.

When defining policies, you need to state when they are to be used and what the requirements are. For example, you could create a "when" item to test for IP addresses: Any IP address that isn't on a trusted network would be assigned a firewall requirement. The "what" is indicated by the tests that the policy is built to run.

If you have multiple policies, CyberGatekeeper will check the "when" clause of each policy and enable the first policy in which all conditions match for each user being tested. The product checks policies in alphabetical order. I found this design decision cumbersome. You should be able to arrange policies in any order. There is a workaround, however: You can add a prefix, such as "A" or "B," to the name of your policies.

When setting the policies, you can configure the server to send a message to the user when he or she fails to meet a requirement, explaining why. This message can appear in the log file, as an alert dialog box or both.

Policies are exported to the servers. There are some centralized management options here, too. If you have multiple CyberGatekeeper servers, you can specify which policy files go on which servers. If you have multiple VPN endpoints across various branch offices, more than one server can carry the same policy. And if you make a change to any policy, re-exporting will update the policy on all the servers to which the policy has been assigned.

Easy Installation

One of the last steps is to build the user-agent software. The custom-built installer software is given to the users preconfigured. Users just need to run the installer and walk away. My build was only 1.15 MB, so it fit on a standard floppy disk. This design makes installation simple for the user -- he or she doesn't need to enter passwords or IP addresses or answer any questions.

For one of my tests, I wanted to verify that my remote users were running Norton AntiVirus 2002 and had an enabled firewall.

I installed the CGAgent program on my remote client machine and connected to the VPN, and traffic flowed to the corporate LAN. I killed the NAV 2002 executable and within five seconds the CG server dropped my traffic. A warning message told me I needed to run NAV. The VPN connection was not dropped, only my traffic was denied. When I restarted NAV, my traffic was permitted to flow once again. I also tested to see if Microsoft Internet Explorer 6 was installed. All my tests resulted in accurate appraisals, notifications and disconnections when necessary.

CyberGatekeeper offers failover capabilities as well. Two CyberGatekeeper servers can sit in tandem and when one fails, the other takes over. Pre-existing IP connections will continue uninterrupted, so your large FTP transfer won't abort if one server fails.

The CyberGatekeeper server has a Web interface for report information. This area is primitive. You can see individual machine statistics -- connect time, policy enforcement information and IP address, for instance. When a user is denied access, the reason is listed in the log file. CyberGatekeeper could use some more work in the reporting space. For instance, there could be better sorting capabilities, graphs and a report that states which users have the most frequent violations. But for protecting the corporate network from external contamination via remote workstations, CyberGatekeeper does the job.

Michael J. DeMaria is an associate technology editor based at Network