Get the Party Started

We set out to define a policy that could perform a number of functions.

FYI The SANS Institute's Security Policy Project offers free guidelines on instituting strong password policies for users, administrators and developers. You can find the complete SANS document here.

First, we wanted to assign user groups that would have access to data of varying sensitivity levels. Thus, each group would have unique authentication requirements. Most users don't require token or biometric authentication because they'll access only low-value or internal-network resources. Passwords would be satisfactory, provided we could enforce a policy to strengthen them in a uniform manner. NMAS, with Enhanced Passwords, excels here, letting you force users to create hard-to-guess passwords. NMAS also is the only product that lets you require that users place symbols in the middle of the password rather than at the beginning or the end--a useful feature because users typically choose an exclamation point (!) as the first or last character in a password when a symbol is required.

Second, we required multiple authentication methods for those user groups we considered critical or that had access to sensitive resources. All the products we tested let us enforce our security policy, though the methods were very different. BioNetrix offered a robust policy definition, based on Boolean logic, that could include simple policies, like "use a password AND a token," or more complex rules, like "use a password AND a token OR a biometric." Novell NMAS used simple Boolean logic--an AND or an OR but not both--but users could be assigned multiple policies. Secure Computing's paradigm relies on authentication strength to satisfy PremierAccess.

Third, we wanted our policies to specify other criteria, such as time of day or user location, such as "local network" or "remote user."

Finally, and recognizing that we are treading a fine line between authentication and access control, we were looking for graded authentication--increasing levels of authentication based on the applications that are being accessed. For example, if users are just checking e-mail, a password would be sufficient, but if they try to access a critical application or resource, they need to present more credentials. Here is where custom development is required to integrate the authentication methods with existing applications, with Web-enabled applications favored.

Why Web-enabled? The source code is available to the owner, and at some point you can force an authentication. Also, Web-based applications are inherently thin client, so end users don't need client software other than a browser, possibly with ActiveX or Java. Of course, maintaining state with Web-based applications is difficult, but there's a whole crop of products aimed at providing Web-based authentication and access control (see "Authentication Gets Tough").

User Management

A huge hurdle to leap when rolling out strong or stronger authentication is getting users to adjust to new methods. You, as a security administrator, want the best authentication possible, but if you make the process too difficult, users will write down passwords or tape PINs to tokens--in other words, make their lives easier while weakening your security.

Building an authentication policy is one thing. Implementing, managing and enforcing it is a different matter.

Authentication-Management System Features Click here to enlarge

In addition, bringing users into and out of your organization is a complicated process. You have active orphaned user accounts, don't you? Go ahead. Admit it. Often, the process for enrolling and removing users is spread across several people, and there are gaps (if you're sitting there nodding your head, see "Employee Provisioning," at www.nwc.com/1317/1317f1.html). None of the products we tested synchronize accounts with external user directories, though both SecureComputing's and BioNetrix's products could import users, and NMAS can synchronize with other LDAP-enabled directories. If we ran Novell's eDirectory everywhere, replacing the native user directories, we might have been able to get a unified user directory, but that's another can of worms.

If you can have a single point of authentication against which all users must authenticate, you can easily and quickly deactivate an account as you wait for other departments to catch up. At least that user can't log in--in theory anyway: Unfortunately, the BioNetrix Authentication Server didn't let us enforce our password policy in cases where BAS didn't have a record of the user, a major flaw.

Finally, what is authentication without accounting and logging? Once you know who someone is, you need to log his or her activities. Both Secure Computing's and BioNetrix's products have detailed logging that can be used for troubleshooting and accounting. In addition, administrative actions are also logged. Unfortunately, we couldn't get Novell's accounting software to run, and after conferring with engineers at the company, we found that we had stumbled across a known issue. Novell is working on a solution but didn't have it ready for our testing.

In the end we give our Editor's Choice nod to Secure Computing because it offers the most complete solution with the most robust policy definition. The products from Novell and BioNetrix have their strengths, however. If you are running eDirectory, stick with NMAS. And if you have relatively simple needs and don't have to support hardware tokens, BioNetrix just might fill the bill.