Managing users and authentication

Effective use of scan information depends on how your organization analyzes and distributes it, who gets to see it, and for what reason. Managing access to information in the application involves creating asset groups and assigning roles and permissions to users. This chapter provides best practices and instructions for managing users, roles, and permissions.

Mapping roles to your organization

It is helpful to study how roles and permissions map to your organizational structure.

Note:  A user authentication system is included. However, if your organization already uses an authentication service that incorporates Microsoft Active Directory or Kerberos, it is a best practice to integrate the application with this service. Using one service prevents having to manage two sets of user information.

In a smaller company, one person may handle all security tasks. He or she will be a Global Administrator, initiating scans, reviewing reports, and performing remediation. Or there may be a small team of people sharing access privileges for the entire system. In either of these cases, it is unnecessary to create multiple roles, because all network assets can be included in one site, requiring a single Scan Engine.

Example, Inc. is a larger company. It has a wider, more complex network, spanning multiple physical locations and IP address segments. Each segment has its own dedicated support team managing security for that segment alone.

One or two global administrators are in charge of creating user accounts, maintaining the system, and generating high-level, executive reports on all company assets. They create sites for different segments of the network. They assign security managers, site administrators, and system administrators to run scans and distribute reports for these sites.

The Global Administrators also create various asset groups. Some will be focused on small subsets of assets. Non-administrative users in these groups will be in charge of remediating vulnerabilities and then generating reports after follow-up scans are run to verify that remediation was successful. Other asset groups will be more global, but less granular, in scope. The non-administrative users in these groups will be senior managers who view the executive reports to track progress in the company's vulnerability management program.

Configuring roles and permissions

Whether you create a custom role or assign a preset role for an account depends on several questions: What tasks do you want that account holder to perform? What data should be visible to the user? What data should not be visible to the user.

For example, a manager of a security team that supports workstations may need to run scans on occasion and then distribute reports to team members to track critical vulnerabilities and prioritizing remediation tasks. This account may be a good candidate for an Asset Owner role with access to a site that only includes workstations and not other assets, such as database servers.

Note:  Keep in mind that, except for the Global Administrator role, the assigning of a custom or preset role is interdependent with access to site and asset groups.

If you want to assign roles with very specific sets of permissions you can create custom roles. The following tables list and describe all permissions that are available. Some permissions require other permissions to be granted in order to be useful. For example, in order to be able to create reports, a user must also be able to view asset data in the reported-on site or asset group, to which the user must also be granted access.

The tables also indicate which roles include each permission. You may find that certain roles are granular or inclusive enough for a given account. A list of preset roles and the permissions they include follows the permissions tables. See Give a user access to asset groups.

Permissions tables

Global permissions

These permissions automatically apply to all sites and asset groups and do not require additional, specified access.

Site permissions

These permissions only apply to sites to which a user has been granted access.

Asset Group permissions

These permissions only apply to asset groups to which a user has been granted access.

Report permissions

The Create Reports permission only applies to assets to which a user has been granted access. Other report permissions are not subject to any kind of access.

Ticket permissions

These permissions only apply to assets to which a user has been granted access.

Vulnerability exception permissions

These permissions only apply to sites or asset groups to which a user has been granted access.

List of roles

Global Administrator

The Global Administrator role differs from all other preset roles in several ways. It is not subject to site or asset group access. It includes all permissions available to any other preset or custom role. It also includes permissions that are not available to custom roles:

• Manage all functions related to user accounts, roles, and permissions.
• Manage Dynamic Discovery connections that allow you to pull assets from systems such as VMWare, AWS, DHCP, and Infoblox.
• Manage configuration, maintenance, and diagnostic routines for the Security Console.
• Manage shared scan credentials.

Security Manager and Site Owner

The Security Manager and Site Owner roles include the following permissions:

• Manage Report Templates 
• Appear on Ticket and Report Lists
• View Site Asset Data
• Specify Site Metadata
• Assign Scan Template
• Manage Scan Alerts
• Manage Site Credentials
• Schedule Automatic Scans
• Start Unscheduled Scans
• View Group Asset Data  (Security Manager only)
• Create Reports
• Create Tickets

The only distinction between these two roles is the Security Manager’s ability to work in accessible sites and assets groups. The Site Owner role, on the other hand, is confined to sites.

Asset Owner

The Asset Owner role includes the following permissions in accessible sites and asset groups:

• Manage Report Templates 
• Appear on Ticket and Report Lists
• View Site Asset Data
• Start Unscheduled Scans
• View Group Asset Data
• Create Reports

User

Although “user” can refer generically to any owner of aNexpose account, the name User, with an upper-case U, refers to one of the preset roles. It is the only role that does not include scanning permissions. It includes the following permissions in accessible sites and asset groups:

• Manage Report Templates 
• Manage Policies
• View Site Asset Data
• View Group Asset Data  (Security Manager only)
• Create Reports
• Create Tickets

ControlsInsight User

This role provides complete access to ControlsInsight with no access to Nexpose.

Managing and creating user accounts

The Users links on the Administration page provide access to pages for creating and managing user accounts. Click manage next to Users to view the Users page. On this page, you can view a list of all accounts within your organization. The last logon date and time is displayed for each account, giving you the ability to monitor usage and delete accounts that are no longer in use.

To edit a user account: 

1. Click Edit for any listed account, and change its attributes.

The application displays the User Configuration panel. The process for editing an account is the same as the process for creating a new user account. See Configure general user account attributes.

To delete an account and reassign tickets or reports:

1. Click Delete for the account you want to remove.

A dialog box appears asking you to confirm that you want to delete the account.

2. Click Yes to delete the account.

If that account has been used to create a report, or if that account has been assigned a ticket, the application displays a dialog box prompting you to reassign or delete the report or ticket in question. You can choose delete a report or a ticket that concerns a closed issue or an old report that contains out-of-date information.

3. Select an account from the drop-down list to reassign tickets and reports to.
4. (Optional) Click Delete tickets and reports to remove these items from the database.
5. Click OK to complete the reassignment or deletion.

Configure general user account attributes

You can specify attributes for general user accounts on the User Configuration panel.

To configure user account attributes:

1. Click New User on the Users page.
2. (Optional) Click Create next to Users on the Administration page. The Security Console displays the General page of the User Configuration panel.
3. Enter all requested user information in the text fields.
4. (Optional) Select the appropriate source from the drop-down list to authenticate the user with external sources.

Before you can create externally authenticated user accounts you must define external authentication sources. See Using external sources for user authentication.

5. Check the Account enabled check box.

You can later disable the account without deleting it by clicking the check box again to remove the check mark.

6. Click Save to save the new user information.

Assign a role and permissions to a user

Assigning a role and permissions to a new user allows you to control that user’s access to Security Console functions.

To assign a role and permissions to a new user:

1. Go to the Roles page.
2. Choose a role from the drop-down list.

When you select a role, the Security Console displays a brief description of that role.

If you choose one of the five default roles, the Security Console automatically selects the appropriate check boxes for that role.

If you choose Custom Role, select the check box for each permission that you wish to grant the user.

3. Click Save to save the new user information.

Give a user access to specific sites

A Global Administrator automatically has access to all sites. A security manager, site administrator, system administrator, or nonadministrative user has access only to those sites granted by a global administrator.

To grant a user access to specific sites:

1. Go to the Site Access page.
2. (Optional) Click the appropriate radio button to give the user access to all sites.
3. (Optional) Click the radio button for creating a custom list of accessible sites to give the user access to specific sites.
4. Click Add Sites.
5. The Security Console displays a box listing all sites within your organization.
6. Click the check box for each site that you want the user to access.
7. Click Save.

The new site appears on the Site Access page.

8. Click Save to save the new user information.

Give a user access to asset groups

A global administrator automatically has access to all asset groups. A site administrator user has no access to asset groups. A security manager, system administrator, or nonadministrative user has access only to those access groups granted by a global administrator.

To grant a user access to asset group:

1. Go to the Asset Group Access page.
2. (Optional) Click the appropriate radio button to give the user access to all asset groups.
3. (Optional) Click the radio button for creating a custom list of accessible asset groups to give the user access to specific asset groups.
4. Click Add Groups.

The Security Console displays a box listing all asset groups within your organization.

5. Click the check box for each asset group that you want this user to access.
6. Click Save.

The new asset group appears on the Asset Group Access page.

7. Click Save to save the new user information.

Using external sources for user authentication

You can integrate Nexpose with external authentication sources. If you use one of these sources, leveraging your existing infrastructure will make it easier for you to manage user accounts.

Note:  The Security Console's Two Factor Authentication is not currently compatible with Active Directory (LDAP) and Kerberos authentication methods. For more information, see Enabling Two Factor Authentication.

The application provides single-sign-on external authentication with two sources:

• LDAP (including Microsoft Active Directory): Active Directory (AD) is an LDAP-supportive Microsoft technology that automates centralized, secure management of an entire network's users, services, and resources.
• Kerberos: Kerberos is a secure authentication method that validates user credentials with encrypted keys and provides access to network services through a “ticket” system.

Note:  The Security Console's Two Factor Authentication is not currently compatible with Active Directory (LDAP) and Kerberos authentication methods. For more information, see Enabling Two Factor Authentication.

The application also continues to support its two internal user account stores:

• XML file lists default “built-in” accounts. A Global Administrator can use a built-in account to log on to the application in maintenance mode to troubleshoot and restart the system when database failure or other issues prevent access for other users.
• Datastore lists standard user accounts, which are created by a global administrator.

Before you can create externally authenticated user accounts you must define external authentication sources.

To define external authentication sources:

1. Go to the Authentication page in the Security Console Configuration panel.
2. Click Add... in the area labelled LDAP/AD authentication sources to add an LDAP/Active Directory authentication source

The Security Console displays a box labeled LDAP/AD Configuration.

3. Click the check box labeled Enable authentication source.
4. Enter the name, address or fully qualified domain name, and port of the LDAP server that you wish to use for authentication.

Note:  It is recommended that you enter a fully qualified domain name in all capital letters for the LDAP server configuration. Example: SERVER.DOMAIN.EXAMPLE.COM

Default LDAP port numbers are 389 or 636, the latter being for SSL. Default port numbers for Microsoft AD with Global Catalog are 3268 or 3269, the latter being for SSL.

5. (Optional) Select the appropriate check box to require secure connections over SSL.
6. (Optional) Specify permitted authentication methods, enter them in the appropriate text field. Separate multiple methods with commas (,), semicolons (;), or spaces.

Note:   It is not recommended that you use PLAIN for non-SSL LDAP connections.

Simple Authentication and Security Layer (SASL) authentication methods for permitting LDAP user authentication are defined by the Internet Engineering Task Force in document RFC 2222 (http://www.ietf.org/rfc/rfc2222.txt). The application supports the use of GSSAPI, CRAM-MD5, DIGEST-MD5, SIMPLE, and PLAIN methods.

7. Click the checkbox labeled Follow LDAP referrals if desired.

As the application attempts to authenticate a user, it queries the target LDAP server. The LDAP and AD directories on this server may contain information about other directory servers capable of handling requests for contexts that are not defined in the target directory. If so, the target server will return a referral message to the application, which can then contact these additional LDAP servers. For information on LDAP referrals, see the document LDAPv3 RFC 2251 (http://www.ietf.org/rfc/rfc2251.txt).

8. Enter the base context for performing an LDAP search if desired. You can initiate LDAP searches at many different levels within the directory.

To force the application to search within a specific part of the tree, specify a search base, such as CN=sales,DC=acme,DC=com.

9. Click one of the three buttons for LDAP attributes mappings, which control how LDAP attribute names equate, or map, to attribute names.

Your attribute mapping selection will affect which default values appear in the three fields below. For example, the LDAP attribute Login ID maps to the user’s login ID. If you select AD mappings, the default value is sAMAccountName. If you select AD Global Catalog mappings, the default value is userPrincipalName. If you select Common LDAP mappings, the default value is uid.

10. Click Save.

The Security Console displays the Authentication page with the LDAP/AD authentication source listed.

To add a Kerberos authentication source:

1. Click Add... in the area of the Authentication page labeled Kerberos Authentication sources.

The Security Console displays a box labeled Kerberos Realm Configuration.

2. Click the checkbox labeled Enable authentication source.
3. Click the appropriate checkbox to set the new realm that you are defining as the default Kerberos realm.

The Security Console displays a warning that the default realm cannot be disabled.

4. Enter the name of the realm in the appropriate text field.
5. Enter the name of the key distribution center in the appropriate field.
6. Select the check box for every encryption type that your authentication source supports. During authentication, the source runs through each type, attempting to decrypt the client’s credentials, until it uses a type that is identical to the type used by the client.
7. Click Save.

The Security Console displays the Authentication page with the new Kerberos distribution center listed.

Once you have defined external authentication sources, you can create accounts for users who are authenticated through these sources.

8. Click the Administration tab on the Home page.
9. Click Create next to Users on the Administration page,

The Security Console displays the User Configuration panel.

On the General page, the Authentication method drop-down list contains the authentication sources that you defined in the Security Console configuration file.

10. Select an authentication source.

Note:  If you log on to the interface as a user with external authentication, and then click your user name link at the top right corner of any page, the Security Console displays your account information, including your password; however, if you change the password on this page, the application will not implement the change.

The built-in user store authentication is represented by the Nexpose user option.

The Active Directory option indicates the LDAP authentication source that you specified in the Security Console configuration file.

If you select an external authentication source, the application disables the password fields. It does not support the ability to change the passwords of users authenticated by external sources.

11. Fill in all other fields on the General page.
12. Click Save.

Manually setting Kerberos encryption types

If you are authenticating users with Kerberos, you can increase security for connections to the Kerberos source, by specifying the types of ticket encryptions that can be used in these connections. To do so, take the following steps:

1. Using a text editor, create a new text file named kerberos.properties.
2. Add a line that specifies one or more acceptable encryption types. For multiple types, separate each types with a character space:

default_tkt_enctypes=<encryption_type encryption_type>

You can specify any of the following ticket encryption types:

• des-cbc-md5
• des-cbc-crc
• des3-cbc-sha1
• rc4-hmac
• arcfour-hmac
• arcfour-hmac-md5
• aes128-cts-hmac-sha1-96
• aes256-cts-hmac-sha1-96

Example:

default_tkt_enctypes= aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96

3. Save the file in the installation_directory/nsc/conf directory.

The changes are applied at the next startup.

Setting a password policy

Global Administrators can customize the password policy in your Nexpose installation. One reason to do so is to configure it to correspond with your organization's particular password standards.

Note:  When you update a password policy, it will take effect for new users and when existing users change their passwords. Existing users will not be forced to change their passwords.

To customize a password policy:

1. In the Security Console, go to the Administration page.
2. Select password policy.

Navigating to the password policy configuration

3. Change the policy name.
4. Select the desired parameters for the password requirements.

Note:  If you do not want to enforce a maximum length, set the maximum length to 0.

Example: This policy is named Test Policy and enforces a minimum length of 8 characters, maximum length of 24 characters, at least one capital leter, at least one numeric value, and at least one special character.

5. Click Save.

Once the password policy is set, it will be enforced on the User Configuration page.

As a new password is typed in, the items on the list of requirements turn from red to green as the password requirements are met.

As a user types a new password, the requirements on the list change from red to green as they are fulfilled.

If a user attempts to save a password that does not meet all the requirements, an error message will appear.