Access Control

Access control is an essential feature of any application. Depending on the infrastructure standards, it is valuable to insist on an external authentication mechanism. Roles and access rights likely will have to be defined in the VM system but external authentication should be possible.

Active Directory

Active Directory^® is one of the most commonly used authentication mechanisms for Windows systems. Later versions support lightweight directory access protocol (LDAP) and LDAP over SSL for directory loading. Kerberos and NTLM are common options for authentication. Since Active Directory capabilities are so common in the corporate environment and standards are available to interface with other systems, this is a good choice. However, any LDAP directory service should work. There are two common approaches to Active Directory integration.

One method synchronizes directory information periodically, looking for additions and deletions. A copy of the directory entries is stored in the VM database for quick reference to access privileges. This is the most common and compatible approach that will use LDAP. Usually, special credentials have to be created to log into the directory system and retrieve the basic information about the users. Using LDAP also affords the system the option of portability to other directory services platforms.

Later, when a user attempts to log into the VM system, the credentials supplied by the user are sent to the authentication system using NTLM or Kerberos. Once the credentials are accepted, the VM system will apply the privileges stored in the VM database for that user.

A second approach is to natively integrate with Active Directory using the Active Directory in Application Mode (AD/AM) capability that comes with Windows .Net™ erver 2003. This enables the VM application to have its own instance of a directory service with schema extensions and built-in attributes but still participate in the security structure of the Active Directory domain. Naturally, the services that support this capability must run on a Microsoft-technology-based server. This provides a tightly integrated directory product for Microsoft-directory-committed organizations. A significant advantage of this approach is that Active Directory groups can be used to grant privileges in the VM system rather than creating an internal set of roles or user groups. The disadvantage is that you may be committed to the Active Directory platform.

RADIUS and TACACS+

In a more network-centric environment, RADIUS is a very common protocol option. It is an old method typically used for dial-in systems. However, the protocol is no less useful for network equipment. With RADIUS and TACACS+ , however, the user ID must be entered into the VM system since no directory service is provided. This user ID must exactly match that which is expected by the authentication server. The most significant difference between RADIUS and TACACS+ is the use of UDP versus TCP, respectively. TCP has the security advantage of being able to communicate with an authenticating source without spoofing since there is a handshake process in the protocol.

Some vendors of network authentication products go so far as to support RADIUS, LDAP, Kerberos, TACACS+, and other methods. These authentication products are able to effectively “glue” together various authorities and protocols, allowing a variety of methods to be employed.

Changing from one authentication method to another can be difficult, depending on the implementation. To avoid complications in the future, select a method from the beginning and stay with it.

Authorization

Authorization capabilities should be able to meet the various roles you have planned for operations. This is one key reason that requirements must be defined prior to beginning the RFP process. One of those requirements is a definition of who will perform what functions and what capabilities are needed. Role-based access control is the mechanism that will have to be vetted during the selection process. You should consider some of the following capabilities:

• Separation by network: Some users will be permitted only to take actions against certain networks. Local IT personnel in Mumbai should not be able to examine any vulnerability reports for Chicago, for example. Scan parameters should not be modifiable by anyone except the VM administrator.
• Actions: Closer to the definition of a role, there are the specific activities to be performed, such as defining a network or administering IP ranges.
• Running reports: Many people are likely to be able to perform this function. Being able to generate a report is fundamental.
• Conducting a scan: Few people should be able to conduct a scan. Active scanning capabilities are potentially disrupting to operations, and therefore should remain in the custody of those who are qualified to assess the impact on the network and the need for current audit results.
• Maintaining the health of the overall system and available audit parameters: The parameters of audits should rarely be tampered with unless extensive testing has been done. Adding TCP ports or additional checks can impact the entire scanning schedule. Only a few people should be able to make changes to this. These people likely have a combination of security and compliance roles.

A good way to document authorization requirements is with a permissions grid. This grid should indicate the capabilities across the top and the roles down the side. See Table 1 for an example. Where a particular function can be performed, a “Y” or “N” is indicated. If access type is specified, then an “R” and/or a “W” are specified for “Read” and “Write,” respectively.

Table 1: Permissions Grid Example 

ROLE/CAPABILITY	REPORT	SCAN	SCHEDULE	MAINTENANCE	PARAMETERS
System administrator	N	N	Y	Y	R
Local IT	Y	N	N	N	N
Regional security manager	Y	N	N	N	N
Global security	Y	Y	Y	N	RW
Global compliance	Y	N	N	N	R