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.

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.

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.

Platform permissions

These permissions only apply to items the user created.

Vulnerability exception permissions

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

Vulnerability investigation permissions

These permissions only apply to assets to which this 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.
• Creating, managing, viewing, and deleting projects.

Security Manager and Site Owner

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

• Manage Report Templates
• Appear on 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 and edit Insight Platform feature items
• View and manage vulnerability investigations

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 Report Lists
• View Site Asset Data
• Start Unscheduled Scans
• View Group Asset Data
• Create Reports
• View vulnerability investigations

User

Although user can refer generically to any owner of a Nexpose 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 and edit Insight Platform feature items
• View vulnerability investigations

Managing and creating user accounts

The Users links on the Administration page provide access to pages for creating and managing user accounts. Click Manage users under the Users section. On the Users 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 manage a user account:

1. Click the Administration tab.
2. Under the Users section, click Manage users.
3. Hover to the right side of the user role that you want to manage.
4. Click the blue ellipsis button.
5. Select Edit, Delete or Deactivate.

The process for editing an account is the same as the process for creating a new user account. See Configure general user account attributes.

Adding a new user

To add a new user you must complete the following pages with the required information: User Info, User Role, Site Permissions, and Asset Group Permissions.

Using external sources for user authentication

You can integrate the Security Console 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.

The application provides single-sign-on external authentication with the following 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. See Configuring LDAP authentication for instructions.
• Kerberos: Kerberos is a secure authentication method that validates user credentials with encrypted keys and provides access to network services through a ticket system. See Configuring Kerberos authentication for instructions.
• SAML 2.0: Security Assertion Markup Language version 2.0 is an XML-based protocol that authenticates users by way of statement packages (known as assertions) communicated between identity and service providers. See Configuring SAML 2.0 authentication for instructions.

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.

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.

To customize a password policy:

1. In the Security Console, go to the Administration page, and click Users > Password Policy.
2. Change the policy name.
3. Select the desired parameters for the password requirements.
4. Click Save Password Policy.

Once the password policy is set, it is reflected 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. If a user attempts to save a password that does not meet all the requirements, an error message appears.