You are on page 1of 182

Nexpose

Administrator's Guide
Product version: 6.3

Contents
Contents

Revision history

About this guide

A note about documented features

Other documents and Help

Document conventions

10

For technical support

11

Configuring maximum performance in an enterprise environment

12

Configuring and tuning the Security Console host

12

Setting up an optimal RAID array

14

Maintaining the database

15

Tuned PostgreSQL settings

16

Disaster recovery considerations

21

Using anti-virus software on the server

21

Planning a deployment

22

Understanding key concepts

22

Define your goals

25

Linking assets across sites

31

Option 1

31

Option 2

31

What exactly is an "asset"?

32

Do Iwant to link assets across sites?

32

Enabling or disabling asset linking across sites

34

Ensuring complete coverage

36

Planning your Scan Engine deployment

37

Contents

View your network inside-out: hosted vs. distributed Scan Engines

37

Distribute Scan Engines strategically

38

Deploying Scan Engine Pools

41

Setting up the application and getting started

43

Planning for capacity requirements

46

Typical scan duration and disk usage for unauthenticated scanning

48

Typical scan duration and disk usage for authenticated scanning

48

Disk usage for reporting on unauthenticated scans

49

Disk usage for reporting on authenticated scans

49

Managing users and authentication

61

Mapping roles to your organization

61

Configuring roles and permissions

62

Managing and creating user accounts

69

Using external sources for user authentication

72

Setting a password policy

76

Setting password policies

80

Managing the Security Console

81

Changing the Security Console Web server default settings

81

Changing default Scan Engine settings

84

Creating a trusted pairing from a Scan Engine to a Security Console

85

Changing Scan Engine communication direction in the Console

87

Managing the Security Console database

90

Running in maintenance mode

99

Enabling dashboards

100

Enabling or disabling dashboards from the Administration page

104

Setting Up a Sonar Query

108

Contents

Connecting to Project Sonar

108

Setting up a Sonar query

109

Filtering data fromProject Sonar

112

Setting the scan date for Sonar queries

113

Clearing the Sonar Cache

113

Deleting a Sonar query

115

Database backup/restore and data retention

116

Important notes on backup and restore

116

What is saved and restored

116

Performing a backup

117

Scheduling a Backup

118

Restoring a backup

122

Migrating a backup to a new host

123

Performing database maintenance

124

Setting data retention preferences

125

Managing versions, updates and licenses

127

Viewing version and update information

127

Viewing, activating, renewing, or changing your license

128

Managing updates with an Internet connection

132

Configuring proxy settings for updates

136

Managing updates without an Internet connection

139

Enabling FIPS mode

141

Using the command console

144

Accessing the command console

144

Available commands

145

Troubleshooting

148

Contents

Working with log files

148

Sending logs to Technical Support

151

Using a proxy server for sending logs

151

Troubleshooting scan accuracy issues with logs

152

Running diagnostics

155

Addressing a failure during startup

155

Addressing failure to refresh a session

156

Resetting account lockout

157

Long or hanging scans

157

Long or hanging reports

159

Out-of-memory issues

159

Update failures

160

Interrupted update

161

SCAP compliance

163

How CPE is implemented

163

How CVE is implemented

164

How CVSS is implemented

164

How CCE is implemented

165

Where to find SCAP update information and OVAL files

165

Glossary

166

Contents

Revision history
Copyright 2015 Rapid7, LLC. Boston, Massachusetts, USA. All rights reserved. Rapid7 and Nexpose are trademarks of
Rapid7, Inc. Other names appearing in this content may be trademarks of their respective owners.
For internal use only.

Revision date

Description

June 15, 2010

Created document.

August 16, 2010

Added instructions for enabling FIPS mode, offline activations and updates.

September 13, 2010

Corrected a step in FIPS configuration instructions; added information


about how to configure data warehousing.

September 22, 2010

Added instructions for verifying that FIPS mode is enabled; added section
on managing updates

October 25, 2010

Updated instructions for activating, modifying, or renewing licenses.

December 13, 2010

Added instructions for SSH public key authentication.

December 20, 2010

Added instructions for using Asset Filter search and creating dynamic asset
groups. Also added instructions for using new asset search features when
creating static asset groups and reports.

March 16, 2011

Added instructions for migrating the database, enabling check correlation,


including organization information in site configuration, managing assets
according to host type, and performing new maintenance tasks.

March 31, 2011

Added a note to the database migration verification section.

April 18, 2011

Updated instructions for configuring Web spidering and migrating the


database.

July 11, 2011

Added information about Scan Engine pooling, expanded permissions, and


using the command console.

July 25, 2011

Corrected directory information for pairing the Security Console with Scan
Engines.

September 19, 2011

Updated information about Dynamic Scan Pooling and FIPS mode


configuration.

November 15, 2011

Added information about vAsset discovery, dynamic site management, new


Real Risk and TemporalPlus risk strategies, and the Advanced Policy
Engine.

December 5, 2011

Added note about how vAsset discovery currently finds assets in vSphere
deployments only. Corrected some formatting issues.

January 23, 2012

Added information about the platform-independent backup option.

Revision history

Revision date

Description

March 21, 2012

Added information about search filters for virtual assets, logging changes,
and configuration options for Kerberos encryption.

June 6, 2012

Nexpose 5.3: Removed information about deprecated logging configuration


page.

August 8, 2012

Nexpose 5.4: Added information about PostgreSQL database tuning;


updated required JAR files for offline updates; added troubleshooting
guidance for session time-out issues.

December 10, 2012

Nexpose 5.5: Added information about using the show host command and
information about migrating backed-up data to a different device.

April 17, 2013

Nexpose 5.6: Added section on capacity planning.

May 29, 2013

Updated offline update procedure with the correct file location.

June 19, 2013

Added information about new timeout interval setting for proxy servers.

July 17, 2013

Nexpose 5.7: Updated capacity planning information.

July 31, 2013

Nexpose 5.7: Removed references to a deprecated feature.

September 18, 2013

Added information on new processes for activating and updating in private


networks. Updated information on console commands.

November 13, 2013

Nexpose 5.8: Updated page layout and version number.

March 26, 2014

Nexpose 5.9: Added information about the Manage Tags permission and
data retention.

August 6, 2014

Updated document look and feel.

October 10, 2014

Made minor formatting changes.

October 23, 2014

Added information about Scan Engine pooling, cumulative scan results, and
update scheduling.

March 11, 2015

Corrected issue that prevented equations from appearing in capacity


planning section.

April 8, 2015

Nexpose 5.13: Added information about linking matching assets across


sites.

May 27, 2015

Nexpose 5.14: Added information about password policy configuration;


Scan Engine communication direction; database updates.

June 24, 2015

Nexpose 5.15: Added note that the option for linking assets across sites is
enabled as of the April 8, 2015, product update. See Linking assets across
sites on page 31.

July 29, 2015

Nexpose 5.16: Added instructions for Setting password policies on page 80.

August 26, 2015

Nexpose 5.17: Updated product version.

Revision history

Revision date

Description

October 8, 2015

Nexpose 6.0: Updated screen shots to reflect new look and feel of Web
interface. Added instructions on Troubleshooting scan accuracy issues with
logs on page 152.

October 28, 2015

Removed reference to Ubuntu 8.04, which is no longer supported. Added


the directory path to the postgresql.conf in Tuned PostgreSQL settings on
page 16.

March 23, 2016

Added a section on setting up Sonar queries.

May 5, 2016

Revised section on ACESlogging to new enhanced logging.

June 7, 2016

Nexpose 6.3: Updated to reflect the opt-in feature to access newly added
dashboards and cards enabled with advanced exposure analytics.

Revision history

About this guide


This guide helps you to ensure that Nexpose works effectively and consistently in support of your
organizations security objectives. It provides instruction for doing key administrative tasks:
l

configuring host systems for maximum performance

database tuning

planning a deployment, including determining how to distribute Scan Engines

capacity planning

managing user accounts, roles, and permissions

administering the Security Console and Scan Engines

working with the database, backups, and restores

using the command console

maintenance and troubleshooting

Who should read this guide


You should read this guide if you fit one or more of the following descriptions:
l

It is your responsibility to plan your organizations Nexpose deployment.


You have been assigned the Global Administrator role, which makes you responsible for
maintenance, troubleshooting, and user management.

A note about documented features


All features documented in this guide are available in the Nexpose Enterprise edition. Certain
features are not available in other editions. For a comparison of features available in different
editions see http://www.rapid7.com/products/nexpose/compare-editions.jsp.

Other documents and Help


Click the Help link on any page of the Security Console Web interface to find information quickly.
You can download any of the following documents from the Support page in Help.

About this guide

Users guide
The users guide helps you to gather and distribute information about your network assets and
vulnerabilities using the application. It covers the following activities:
l

logging onto the Security Console and familiarizing yourself with the interface

managing dynamic discovery

setting up sites and scans

running scans manually

viewing asset and vulnerability data

creating remediation tickets

using preset and custom report templates

using report formats

reading and interpreting report data

configuring scan templates

configuring other settings that affect scans and report

API guide
The API guide helps you to automate some Nexpose features and to integrate its functionality
with your internal systems.

Document conventions
Words in bold are names of hypertext links and controls.

Words in italics are document titles, chapter titles, and names of Web interface pages.
Steps of procedures are indented and are numbered.
Items in Courier font are commands, command examples, and directory paths.
Items in bold Courier font are commands you enter.
Variables in command examples are enclosed in box brackets.
Example: [installer_file_name]
Options in commands are separated by pipes. Example:
$ /etc/init.d/[daemon_name] start|stop|restart

Document conventions

10

Keyboard commands are bold and are enclosed in arrow brackets.Example:


Press and hold <Ctrl + Delete>
Note: NOTES contain information that enhances a description or a procedure and provides
additional details that only apply in certain cases.
Tip: TIPS provide hints, best practices, or techniques for completing a task.

Warning: WARNINGS provide information about how to avoid potential data loss or damage or
a loss of system integrity.
Throughout this document, Nexpose is referred to as the application.

For technical support


l

Send an e-mail to support@rapid7.com (Enterprise and Express Editions only).

Click the Support link on the Security Console Web interface.

Go to community.rapid7.com.

For technical support

11

Configuring maximum performance in an enterprise


environment
This chapter provides system configuration tips and best practices to help ensure optimal
performance of Nexpose in an enterprise-scale deployment. The emphasis is on the system that
hosts the Security Console. Some considerations are also included for Scan Engines.
Even if you are configuring the application for a smaller environment, you may still find some of
this information helpful, particularly the sections maintaining and tuning the database, Scan
Engine scaling, and disaster recovery considerations.

Configuring and tuning the Security Console host


The Security Console is the base of operations in a deployment. It manages Scan Engines and
creates a repository of information about each scan, each discovered asset, and each discovered
vulnerability in its database. With each ensuing scan, the Security Console updates the
repository while maintaining all historical data about scans, assets, and vulnerabilities. The
Security Console includes the server of the Web-based interface for configuring and operating
the application, managing sites and scans, generating reports, and administering users.
The Security Console is designed to meet the scaling demands of an enterprise-level
deployment. One Security Console can handle hundreds of Scan Engines, thousands of assets,
and any number of reports as long as it is running on sufficient hardware resources and is
configured correctly.

Configuring maximum performance in an enterprise environment

12

Scan volume drives resource requirements


In an enterprise environment, the Security Consoles most resource-intensive activities are
processing, storing, and displaying scan data.
To determine resource sizing requirements, consider these important factors:
l

The number of IP addresses that the application will scan: Every target generates a certain
amount of data for the Security Console to store in its database. More targets mean more
data.
The frequency with which it will scan those assets: Scanning daily produces seven times more
data than scanning weekly.
The depth of scanning. A Web scan typically requires more time and resources than a
network scan.
The amount of detailed, historical scan data that it will retain over time: To the extent that scan
data is retained in the database, this factor acts as a multiplier of the other two. Each retained
set of scan data about a given target builds up storage overhead, especially with frequent
scans.

Selecting a Security Console host for an enterprise deployment


The Security Console is available in Windows and Linux software versions that can be installed
on your organizations hardware running a supported operating system. It is also available in a
variety of convenient plug-and-play hardware Appliances, which are easy to maintain.
The software version of the Security Console is more appropriate for bigger deployments since
you can scale its host system to match the demands of an expanding target asset environment.
The following hardware configuration is recommended to host the Security Console in an
enterprise-level deployment. The definition of enterprise-level can vary. Experience with past
deployments indicates that 25,000 IP addresses or more, scanned with any reasonable
frequency, warrants this recommended configuration:
l

vendor: preferably IBM or Hewlett-Packard (These products are lab tested for performance)
processor: 2x Intel quad-core Xeon 55xx Nehalem CPUs (2 sockets, 8 cores, and 16
threads total)
RAM: 48-96 GB with error-correction code (ECC) memory; some 2-socket LGA1366
motherboards can support up to 144GB, with 8GB DDR3 modules
storage: 8-12 x 7200RPM SATA/SAS hard drives, either 3.5 or 2.5 (if the chassis can only
support that many drives in this form factor); total capacity should be 1+TB
network interface card (NIC): 2 x 1GbE (one for scans, and one for redundancy or for a
private-management subnet)

Configuring and tuning the Security Console host

13

Examples of products that meet these specifications include the following:


l

HP ProLiant DL380 G6

IBM System x3650 M2Y

Your IT department or data center operations team may have preferred vendors. Or, your
organization may build white box servers from commodity parts.
Linux expertise is essential
If your requirements dictate that you use a Linux-based host, consider the level of expertise in
your organization for maintaining a Linux server.
Note that Red Hat Enterprise Linux 5.4 and 5.5 64-bit are the supported versions.
Note that the following Linux distributions are supported:
l

Red Hat Enterprise Linux 5 64-bit

Red Hat Enterprise Linux 6 64-bit

Ubuntu 10.04 LTS 64-bit

Ubuntu 12.04 LTS 64-bit

Setting up an optimal RAID array


It should also be noted that the application cannot completely avoid querying data on disk. So,
configuring a performance-friendly RAID array is important, especially given the fact that disk
requirements can range up to 1TB.
Rapid7recommends arranging multiple disks in a configuration of striped mirrors, also known as
a RAID 1+0 or RAID 10 array, for better random disk I/O performance without sacrifice to
redundancy. Nexpose and PostgreSQL should be installed on this high-performing RAID 1+0
array. The PostgreSQL transaction log should be on independent disks, preferably a 2-drive
mirror array (RAID 1). The operating system, which should generate very little disk I/O, may
share this 2-drive mirror with the PostgreSQL transaction log.
A good purchasing approach will favor more disks over expensive disks. 8 to 12 disks are
recommended. The application, the operating system, and PostgreSQL should each run on its
own partition.

Setting up an optimal RAID array

14

Maintaining the database


Given the amount of data that an enterprise deployment will generate, regularly scheduled
backups are important. Periodic backups are recommended. During a database backup,
Nexpose goes into a maintenance mode and cannot run scans. Planning a deployment involves
coordinating backup periods with scan windows. The time needed for backing up the database
depends on the amount of data and may take several hours to complete.
A backup saves the following items:
l

the database

configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)

licenses

keystores

report images

custom report templates

custom scan templates

generated reports

scan logs

It is recommended that you perform the following database maintenance routines on a regular
basis:
l

Clean up the database to remove leftover data that is associated with deleted objects, such as
sites, assets, or users.

Compress database tables to free up unused table space.

Rebuild database indexes that may have become fragmented or corrupted over time.

Another maintenance task can be used to regenerate scan statistics so that the most recent
statistics appear in the Security Console Web interface.
Additionally, a database optimization feature applies optional performance improvements, such
as vulnerability data loading faster in the Security Console Web interface. It is recommended that
you run this feature before running a backup.
For information on performing database backups and maintenance, see Database
backup/restore and data retention on page 116.

Maintaining the database

15

PostgreSQL also has an autovacuum feature that works in the background performing several
necessary database maintenance chores. It is enabled by default and should remain so.

Tuned PostgreSQL settings


The following table lists PostgreSQL configuration parameters, their descriptions, default
settings, and their recommended tuned settings. The table continues on the following page.
The file to be edited is located in [installation_directory]/nsc/nxpgsql/nxpdata/postgresql.conf.
The Recommended midrange settings are intended to work with a Nexpose 64-bit Appliance
running on 8 GB of RAM, or equivalent hardware.
The Recommended enterprise business settings are intended to work in a higher-scan-capacity
environment in which the application is installed on high-end hardware with 72 GB of RAM. See
Selecting a Security Console host for an enterprise deployment on page 13

Tuned PostgreSQL settings

16

Parameter

shared_
buffers

Description
This is the amount of memory
that is dedicated to PostgreSQL
for caching data in RAM.
PostgreSQL sets the default
when initializing the database
based on the hardware capacity
available, which may not be
optimal for the application.
Enterprise configurations will
benefit from a much larger
setting for shared_buffers.
Midrange configurations should
retain the default that
PostgreSQL allocates on first
installation.

Default
value

Recommended Recommended
midrange
enterprise
settings
settings

This value is
set on
PostgreSQL
startup
24 MB
based on
operating
system
settings.

1950 MB

Note: Increasing the default


value may prevent the database
from starting due to kernel
limitations. To ensure that
PostgreSQL starts, see
Increasing the shmmax kernel
parameter on page 20

max_
connections

This is the maximum number of


concurrent connections to the
database server. Increase this
value if you anticipate a significant
rise in the number of users and
concurrent scans. Note that
increasing this value requires
approximately 400 bytes of shared
memory per connection slot.

100

work_mem

This is the amount of memory that


internal sort operations and hash
tables use before switching to
temporary disk files.

1 MB

200

300

32 MB

32 MB

Tuned PostgreSQL settings

17

Parameter

Default
value

Description

Recommended Recommended
midrange
enterprise
settings
settings

checkpoint_
segments

PostgreSQL writes new


transactions to the database in files
known as write ahead log (WAL)
segments, which are 16 MB in size.
These entries trigger checkpoints,
or points in the transaction log
sequence at which all data files
have been updated to reflect the
content of the log. The checkpoint_
3
segments setting is the maximum
distance between automatic
checkpoints. At the default setting
of 3, checkpoints can be can be
resource intensive, producing 48
MB (16 MB multiplied by 3) and
potentially causing performance
bottlenecks. Increasing the setting
value can mitigate this problem.

effective_
cache_size

This setting reflects assumptions


about the effective portion of disk
cache that is available for a single
query. It is factored into estimates
of the cost of using an index. A
higher value makes an index scan
more likely. A lower value makes
sequential scans more likely.

4 GB (For
configurations
with more than
16 GB of RAM, 32 GB
use half of the
available RAM
as the setting.)

128 MB

32

Tuned PostgreSQL settings

18

Parameter

Description

Default
value

Recommended Recommended
midrange
enterprise
settings
settings

logging: log_
min_error_
statement

This setting controls whether or not


the SQL statement that causes an
error condition will be recorded in
the server log. The current SQL
statement is included in the log
entry for any message of the
specified severity or higher. Each
value corresponds to one of the
following severity levels in
ascending order: DEBUG5,
DEBUG4, DEBUG3, DEBUG2,
ERROR
DEBUG1, INFO, NOTICE,
WARNING, ERROR, LOG,
FATAL, and PANIC. The default
value is ERROR, which means
statements causing errors or more
severe events will be logged.
Increasing the log level can slow
the performance of the application
since it requires more data to be
logged.

ERROR

ERROR

logging: log_
min_
duration_
statement

This setting causes the duration of


each completed statement to be
logged if the statement ran for at
least the specified number of
milliseconds. For example: A value
of 5000 will cause all queries with
an execution time longer than 5000
ms to be logged. The default value
of -1 means logging is disabled. To
enable logging, change the value -1
to 0. This will increase page
response time by approximately 5
percent, so it is recommended that
you enable logging only if it is
required. For example, if you find a
particular page is taking a long time
to load, you may need to
investigate which queries may be
taking a long time to complete.

-1 (Set
recommended
value to 0 only if
required for
debugging)

-1 (Set
recommended
value to 0 only if
required for
debugging)

Tuned PostgreSQL settings

19

Parameter

Description

Default
value

Recommended Recommended
midrange
enterprise
settings
settings

This is the amount of memory used


in shared memory for write ahead
log (WAL) data. This setting does
not affect select/update-only
performance in any way. So, for an 64 KB
application in which the
select/update ratio is very high,
wal_buffers is almost an irrelevant
optimization.

64 KB

8 MB

This setting specifies the maximum


amount of memory to be used by
maintenance_ maintenance operations, such as
16 MB
work_mem
VACUUM, CREATE INDEX, and
ALTER TABLE ADD FOREIGN
KEY.

16 MB

512 MB

wal_buffers

Increasing the shmmax kernel parameter


If you increase the shared_buffers setting as part of tuning PostgreSQL, check the shmmax
kernel parameter to make sure that the existing setting for a shared memory segment is greater
than the PostgreSQL setting. Increase the parameter if it is less than the PostgreSQL setting.
This ensures that the database will start.
1. Determine the maximum size of a shared memory segment:
# cat /proc/sys/kernel/shmmax

2. Change the default shared memory limit in the proc file system.
# echo [new_kernel_size_in_bytes] > /proc/sys/kernel/shmmax

It is unnecessary to restart the system.


Alternatively, you can use sysctl(8) to configure the shmax parameters at runtime:
# sysctl -w kernel.shmmax=[new_kernel_size_in_bytes]

Note: If you do not make this change permanent, the setting will not persist after a system restart.

Tuned PostgreSQL settings

20

To make the change permanent, add a line to the /etc/sysctl.conf utilities file, which the host
system uses during the startup process. Actual command settings may vary from the following
example:
# echo "kernel.shmmax=[new_kernel_size_in_bytes]" >> /etc/sysctl.conf

Disaster recovery considerations


As previously mentioned, one Security Console is sufficient for handling all activities at the
enterprise level. However, an additional, standby Security Console may be warranted for your
organizations disaster recovery plan for critical systems. If a disaster recovery plan goes into
effect, this cold standby Security Console would require one database-restore routine in order
to contain the most current data.
Disaster recovery may not warrant doubling the fleet of Scan Engines in the data center. Instead,
a recovery plan could indicate having a number of spares on hand to perform a minimal
requirement of scansfor example, on a weekly basis instead of dailyuntil production conditions
return to normal. For example, if your organization has 10 Scan Engines in the data center, an
additional 5 may suffice as temporary backup. Having a number of additional Scan Engines is
also helpful for handling occasional scan spikes required by events such as monthly Microsoft
patch verification.

Using anti-virus software on the server


Anti-virus programs may sometimes impact critical operations that are dependent on network
communication, such as downloading updates and scanning. Blocking the latter may cause
degraded scan accuracy.
If you are running anti-virus software on your intended host, configure the software to allow the
application to receive the files and data that it needs for optimal performance in support your
security goals:
l

Add the application update server, updates.rapid7.com, to a whitelist, so that the application
can receive updates.
Add the application installation directory to a whitelist to prevent the anti-virus program from
deleting vulnerability- and exploit-related files in this directory that it would otherwise regard as
malicious.

Consult your anti-virus vendor for more information on configuring the software to work with the
application.

Disaster recovery considerations

21

Planning a deployment
This chapter will help you deploy the application strategically to meet your organizations security
goals. If you have not yet defined these goals, this guide will give you important questions to ask
about your organization and network, so that you can determine what exactly you want to
achieve.
The deployment and configuration options in the application address a wide variety of security
issues, business models, and technical complexities. With a clearly defined deployment strategy,
you can use the application in a focused way for maximum efficiency.

Understanding key concepts


Understanding the fundamentals of the application and how it works is key to determining how
best to deploy it.
Understanding the application
Nexpose is a unified vulnerability solution that scans networks to identify the devices running on
them and to probe these devices for vulnerabilities. It analyzes the scan data and processes it for
reports. You can use these reports to help you assess your network security at various levels of
detail and remediate any vulnerabilities quickly.
The vulnerability checks identify security weaknesses in all layers of a network computing
environment, including operating systems, databases, applications, and files. The application can
detect malicious programs and worms, identify areas in your infrastructure that may be at risk for
an attack, and verify patch updates and security compliance measures.
Understanding the components
The application consists of two main components:

Scan Engines perform asset discovery and vulnerability detection operations. You can deploy
Scan Engines outside your firewall, within your secure network perimeter, or inside your DMZ to
scan any network asset.
The Security Console communicates with Scan Engines to start scans and retrieve scan
information. All exchanges between the Security Console and Scan Engines occur via encrypted
SSL sessions over a dedicated TCP port that you can select. For better security and
performance, Scan Engines do not communicate with each other; they only communicate with
the Security Console after the Security Console establishes a secure communication channel.

Planning a deployment

22

When the application scans an asset for the first time, the Security Console creates a repository
of information about that asset in its database. With each ensuing scan that includes that asset,
the Security Console updates the repository.
The Security Console includes a Web-based interface for configuring and operating the
application. An authorized user can log onto this interface securely, using HTTPS from any
location, to perform any application-related task that his or her role permits. See Understanding
user roles and permissions on page 24. The authentication database is stored in an encrypted
format on the Security Console server, and passwords are never stored or transmitted in plain
text.
Other Security Console functions include generating user-configured reports and regularly
downloading patches and other critical updates from the Rapid7 central update system.
Nexpose components are available as a dedicated hardware/software combination called an
Appliance. You also can download software-only Linux or Windows versions for installation on
one or more hosts, depending on your Nexpose license. Another option is to purchase remote
scanning services from Rapid7.
Nexpose is agentless
The application performs all of its scanning operations over the network, using common Windows
and UNIX protocols to gain access to target assets. This architecture makes it unnecessary for
you to install and manage software agents on your target assets, which lowers the total cost of
ownership (TCO) and eliminates security and stability issues associated with agents.
Understanding sites and asset groups
The Security Console interface enables you to plan scans effectively by organizing your network
assets into sites and asset groups.
When you create a site, you identify the assets to be scanned, and then define scan parameters,
such as scheduling and frequency. You also assign that site to a Scan Engine. You can only
assign a given site to one Scan Engine. However, you can assign many sites to one Scan
Engine.
You also define the type of scan you wish to run for that site. Each site is associated with a
specific scan. The application supplies a variety of scan templates, which can expose different
vulnerabilities at all network levels. Template examples include Penetration Test, Microsoft
Hotfix, Denial of Service Test, and Full Audit. You also can create custom scan templates.
Another level of asset organization is an asset group. Like the site, this is a logical grouping of
assets, but it is not defined for scanning. An asset group typically is assigned to a user who views

Understanding key concepts

23

scan reports about that group in order to perform any necessary remediation. An asset must be
included within a site before you can add it to an asset group.
Note: If you are using RFC1918 addressing (192.168.x.x or 10.0.x.x addresses) different assets
may have the same IP address. You can use site organization to enable separate Scan Engines
located in different parts of the network to access assets with the same IP address.
Only designated global administrators are authorized to create sites and asset groups. For more
details about access permissions, see Understanding user roles and permissions on page 24.
Asset groups can include assets listed in multiple sites. They may include assets assigned to
multiple Scan Engines, whereas sites can only include assets assigned to the same Scan
Engine. Therefore, if you wish to generate reports about assets scanned with multiple Scan
Engines, use the asset group arrangement. You also can configure reports for combination of
sites, asset groups, and assets.
Understanding user roles and permissions
User access to Security Console functions is based on roles. You can assign default roles that
include pre-defined sets of permissions, or you can create custom roles with permission sets that
are more practical for your organization. See Managing and creating user accounts on page 69.
Once you give a role to a user, you restrict access in the Security Console to those functions that
are necessary for the user to perform that role.
There are five default roles:
l

Global Administrator on page 67

Security Manager and Site Owner on page 68

Asset Owner on page 68 Asset Owner

Managing users and authentication on page 61

Understanding key concepts

24

Define your goals


Knowing in advance what security-related goals you want to fulfill will help you design the most
efficient and effective deployment for your organization.
Know your business case to know your goals
If you have not yet defined your goals for your deployment, or if you are having difficulty doing so,
start by looking at your business model and your technical environment to identify your security
needs.
Consider factors such as network topology, technical resources (hardware and bandwidth),
human resources (security team members and other stake holders), time, and budget.
How big is your enterprise?
How many networks, subnetworks, and assets does your enterprise encompass?
The size of your enterprise is a major factor in determining how many Scan Engines you deploy.
What is the geography of your enterprise?
In how many physical locations is your network deployed? Where are these locations? Are they
thousands or tens of thousands of miles away from each other, or across town from each other,
or right next to each other? Where are firewalls and DMZs located?
These factors will affect how and where you deploy Scan Engines and how you configure your
sites.
How is your network segmented?
What is the range of IP addresses and subnets within your enterprise?
Network segmentation is a factor in Scan Engine deployment and site planning.
How do you want to view an asset in multiple sites?
Assets are scanned in logical groupings called sites. For more information about attaching assets
to sites, see the topic Best practices for adding assets to a site in Help or the user's guide.
Depending on your needs, you may want to scan the same asset in multiple sites. For example,
an asset may belong to one site because of it's geographical location and another because it is
part of a PCIaudit.
If you plan to have assets in multiple sites, consider whether you want to link instances of each
asset in different sites so that it is regarded as the same entity throughout your deployment, or

Define your goals

25

treat each instance as a unique entity. For more information about these options, see Linking
assets across sites on page 31
What is your asset inventory?
What kinds of assets are you using? What are their functions? What operating systems,
applications, and services are running on them? Which assets are physical hardware, and which
are virtual? Where are these different assets located relative to firewalls and DMZs? What are
your hidden network components that support other assets, such as VPN servers, LDAP
servers, routers, switches, proxy servers, and firewalls? Does your asset inventory change
infrequently? Or will today's spreadsheet listing all of your assets be out of date in a month?
Asset inventory influences site planning and scan template selection.

Does your asset inventory include laptops that employees take home? Laptops open up a whole
new set of security issues that render firewalls useless. With laptops, your organization is
essentially accepting external devices within your security perimeter. Network administrators
sometimes unwittingly create back doors into the network by enabling users to connect laptops or
home systems to a virtual private network (VPN).
Additionally, laptop users working remotely can innocently create vulnerabilities in many different
ways, such as by surfing the Web without company-imposed controls or plugging in personal
USB storage devices.
An asset inventory that includes laptops may require you to create a special site that you scan
during business hours, when laptops are connected to your local network.

Define your goals

26

One possible environment: Example, Inc.


As you answer the preceding questions, you may find it helpful to create a table. The following
table lists network and asset information for a company called Example, Inc.

Network segment

Address
space

Number of
assets

Location

Asset
function

New York Sales

10.1.0.0/22

254

Building 1:
Floors 1-3

Work stations

New York
IT/Administration

10.1.10.0/23

50

Building 2:
Floor 2

Work stations
Servers

New York printers

10.1.20.0/24

56

Buildings 1 & 2

Printers

New York DMZ

172.16.0.0/22

30

Co-location
facility

Web server
Mail server

Madrid sales

10.2.0.0/22

65

Building 3:
Floor 1

Work stations

Madrid development

10.2.10.0/23

130

Building 3:
Floors 2 & 3

Work stations
Servers

Madrid printers

10.2.20.0/24

35

Building 3:
Floors 1-3

Printers

Madrid DMZ

172.16.10.0/24 15

Building 3:
dark room

File server

What are the hot spots in your enterprise?


What assets contain sensitive data? What assets are on the perimeter of your network? Do you
have Web, e-mail, or proxy servers running outside of firewalls?
Areas of specific concern may warrant Scan Engine placement. Also, you may use certain scan
templates for certain types of high-risk assets. For example, a Web Audit scan template is most
appropriate for Web servers.
What are your resources?
How much local-area network (LAN) and wide-area network (WAN) bandwidth do you have?
What is your security budget? How much time do you have to run scans, and when can you run
these scans without disrupting business activity?
These considerations will affect which scan templates you use, how you tune your scans, and
when you schedule scans to run. See the Discover section in the users guide for information on
setting up sites and scans.

Define your goals

27

What exactly are the security risks to your organization?


How easy is it for hackers to penetrate your network remotely? Are there multiple logon
challenges in place to slow them down? How difficult is it for hackers to exploit vulnerabilities in
your enterprise? What are the risks to data confidentiality? To data integrity? To data availability?
The triad of confidentiality, integrity, and availability (CIA) is a good metric by which to quantify
and categorize risks in your organization.
Confidentiality is the prevention of data disclosure to unauthorized individuals or systems. What
happens if an attacker steals customer credit card data? What if a trojan provides hacker access
to your companys confidential product specifications, business plans, and other intellectual
property?
Integrity is the assurance that data is authentic and complete. It is the prevention of unauthorized
data modification. What happens when a virus wipes out records in your payroll database?
Availability refers to data or services being accessible when needed. How will a denial-of-service
hack of your Web server affect your ability to market your products or services? What happens if
a network attack takes down your phones? Will it cripple your sales team?
If your organization has not attempted to quantify or categorize risks, you can use reports to
provide some guidelines. The algorithm that produces a risk score for each scanned asset
calculates the score based on CIA factors.
Other risks have direct business or legal implications. What dangers does an attack pose to your
organizations reputation? Will a breach drive away customers? Is there a possibility of getting
sued or fined?
Knowing how your enterprise is at risk can help you set priorities for deploying Scan Engines,
creating sites, and scheduling scans.
The application provides powerful tools for helping you to analyze and track risk so you prioritize
remediation and monitor security trends in your environment over time. See the topics Working
with risk strategies to analyze threats and Working with risk trends in reports in the users guide.
What are your compliance requirements?
Many organizations have a specific reason for acquiring Nexpose: they have to comply with a
specific set of security requirements imposed by the government or by a private-sector entity that
regulates their industry.
Health care providers must protect the confidentiality of patient data as required by the Health
Insurance Portability and Accountability Act (HIPAA).

Define your goals

28

Many companies, especially those in the financial sector, are subject to security criteria specified
in the Sarbanes-Oxley Act (SOX).
U.S. government organizations and vendors who transact business with the government must
comply with Federal Desktop Core Configuration (FDCC) policies for their Microsoft Windows
systems.
Merchants, who perform credit and debit card transactions, must ensure that their networks
comply with Payment Card Industry (PCI) security standards.
The application provides a number of compliance tools, such as built-in scan templates that help
you verify compliance with these standards. For a list of scan templates and their specifications,
see Where to find SCAP update information and OVAL files on page 165.
For official PCI scans the application provides additional tools, including PCI-sanctioned reports,
Web interface features for PCI-specific site configuration and vulnerability exception
management, and expanded application program interface (API) functionality for managing
report distribution. For more information, see the ASV Guide, which you can request from
Technical Support.
Verifying compliance with configuration standards
The application provides several tools to assess configuration against various established
standards:
l

a built-in United States Government Configuration Baseline (USGCB) scan template that
includes Policy Manger checks for compliance with USGCB configuration policies (see the
appendix on scan templates in the users guide.)
a built-in Federal Desktop Core Configuration (FDCC) scan template that includes Policy
Manger checks for compliance with FDCC configuration policies (see the appendix on scan
templates in the users guide.)
a built-in Center for Internet Security (CIS) scan template that includes Policy Manger checks
for compliance with CIS configuration benchmarks (see the appendix on scan templates in the
users guide.)
Web interface tools for tracking and overriding policy test results (see the chapter Working
with data from scans in the users guide.)
XML and CSV reports for disseminating policy test result data. (See Creating a basic report in
the users guide.)
Web interface tools for viewing SCAP data and working with OVAL files (see Where to find
SCAP update information and OVAL files on page 165.)

These tools require a license that enables the Policy Manager and policy scanning for the specific
desired standards.

Define your goals

29

What are your goals beyond compliance?

Compliance goals may help you to define your deployment strategy, but its important to think
beyond compliance alone to ensure security. For example, protecting a core set of network
assets, such as credit card data servers in the case of PCI compliance, is important; but it may not
be enough to keep your network securenot even secure enough to pass a PCI audit.
Attackers will use any convenient point of entry to compromise networks. An attacker may exploit
an Internet Explorer vulnerability that makes it possible to install a malicious program on an
employee's computer when that employee browses the Web. The malware may be a remote
execution program with which the hacker can access more sensitive network assets, including
those defined as being critical for compliance.
Compliance, in and of itself, is not synonymous with security. On the other hand, a well
implemented, comprehensive security plan will include among its benefits a greater likelihood of
compliance.
Who is your security team?

Are you a one-person company or IT department? Are you the head of a team of 20 people, each
with specific security-related tasks? Who in your organization needs to see asset/security data,
and at what level of technical detail? Whos in charge of remediating vulnerabilities? What are the
security considerations that affect who will see what information? For example, is it necessary to
prevent a security analyst in your Chicago branch from seeing data that pertains to your
Singapore branch?
These considerations will dictate how you set up asset groups, define roles and permissions,
assign remediation tickets, and distribute reports. See Managing users and authentication on
page 61.

Define your goals

30

Linking assets across sites


You can choose whether to link assets in different sites or treat them as unique entities. By linking
matching assets in different sites, you can view and report on your assets in a way that aligns with
your network configuration and reflects your asset counts across the organization. Below is some
information to help you decide whether to enable this option.

Option 1
A corporation operates a chain of retail stores, each with the same network mapping, so it has
created a site for each store. It does not link assets across sites, because each site reflects a
unique group of assets.

Option 2
A corporation has a global network with a unique configuration in each location. It has created
sites to focus on specific categories, and these categories may overlap. For example, a Linux
server may be in one site called Finance and another called Ubuntu machines. The corporation
links assets across sites so that in investigations and reporting, it is easier to recognize the
Linux server as a single machine.

Linking assets across sites

31

What exactly is an "asset"?


An asset is a set of proprietary, unique data gathered from a target device during a scan. This
data, which distinguishes the scanned device when integrated into Nexpose, includes the
following:
l

IPaddress

host name

MAC address

vulnerabilities

risk score

user-applied tags

site membership

asset ID (a unique identifier applied by Nexpose when the asset information is integrated into
the database)

If the option to link assets across sites is disabled, Nexpose regards each asset as distinct from
any other asset in any other site whether or not a given asset in another site is likely to be the
same device.
For example, an asset named server1.example.com, with an IPaddress of 10.0.0.1 and a MAC
address of 00:0a:95:9d:68:16 is part of one site called Boston and another site called PCI targets.
Because this asset is in two different sites, it has two unique asset IDs, one for each site, and thus
is regarded as two different entities.
Note: Assets are considered matching if they have certain proprietary characteristics in common,
such as host name, IPaddress, and MAC address.
If the option to link assets across sites is enabled, Nexpose determines whether assets in
different sites match, and if they do, treats the assets that match each other as a single entity .

Do Iwant to link assets across sites?


The information below describes some considerations to take into account when deciding
whether to enable this option.
Use Cases
You have two choices when adding assets to your site configurations:

What exactly is an "asset"?

32

Link matching assets across sites. Assets are considered matching if they have certain
characteristics in common, such as host name, IPaddress, and MAC address. Linking makes
sense if you scan assets in multiple sites. For example, you may have a site for all assets in
your Boston office and another site of assets that you need to scan on a quarterly basis for
compliance reasons. It is likely that certain assets would belong to both sites. In this case, it
makes sense to link matching assets across all sites.
Treat each asset within each site as unique. In other words, continue using Nexpose in the
same way prior to the release of the linking capability. This approach makes sense if you do
not scan any asset in more than one site. For example, if your company is a retail chain in
which each individual store location is a site, you'll probably want to keep each asset in each
site unique.

Security considerations
l

Once assets are linked across sites, users will have a unified view of an asset. Access to an
asset will be determined by factors other than site membership. If this option is enabled, and a
user has access to an asset through an asset group, for instance, that user will have access to
all information about that asset from any source, whether or not the user has access to the
source itself. Examples: The user will have access to data from scans in sites to which they do
not have access, discovery connections, Metasploit, or other means of collecting information
about the asset.

Site-level controls
l

With this option enabled, vulnerability exceptions cannot be created at the site level through
the user interface at this time. They can be created at the site level through the API. Site-level
exceptions created before the option was enabled will continue to apply.
When this option is enabled, you will have two distinct options for removing an asset:
l Removing an asset from a site breaks the link between the site and the asset, but the
asset is still available in other sites in which is it was already present. However, if the
asset is only in one site, it will be deleted from the entire workspace.
l

Deleting an asset deletes it from throughout your workspace in the application.

Transition considerations
l

Disabling asset linking after it has been enabled will result in each asset being assigned to the
site in which it was first scanned, which means that each assets data will be in only one site.
To reserve the possibility of returning to your previous scan results, back up your application
database before enabling the feature.
The links across sites will be created as assets are scanned. During the transition period until
you have scanned all assets, some will be linked across sites and others will not. Your risk
score may also vary during this period.

Do Iwant to link assets across sites?

33

If you choose to link assets across all sites on an installation that preceded the April 8, 2015
release, you will see some changes in your asset data and reports:
l

You will notice that some assets are not updating with scans over time. As you scan, new data
for an asset will link with the most recently scanned asset. For example if an asset with
IPaddress 10.0.0.1 is included in both the Boston and the PCI targets sites, the latest scan
data will link with one of those assets and continue to update that asset with future scans. The
non-linked, older asset will not appear to update with future scans. The internal logic for
selecting which older asset is linked depends on a number of factors, such scan authentication
and the amount of information collected on each "version"of the asset.
Your site risk scores will likely decrease over time because the score will be multiplied by
fewer assets.

Enabling or disabling asset linking across sites

Note: The cross-site asset linking feature is enabled by default for new installations as of the April
8, 2015, product update.
To enable assets in different sites to be recognized as a single asset:
1. Review the above considerations.
2. Log in to the application as a Global Administrator.
3. Go to the Administration page.
4. Under Global and Console Settings, next to Console, select Manage.
5. Select Asset Linking.
6. Select the check box for Link all matching assets in all sites.

Enabling or disabling asset linking across sites

34

Enabling linking assets across sites.

To disable linking so that matching assets in different sites are considered unique:
1. Review the above considerations. Also note that removing the links will take some time.
2. Log in to the application as a Global Administrator.
3. Go to the Administration page.
4. Under Global and Console Settings, next to Console, select Manage.
5. Select Asset Linking.
6. Clear the check box for Link all matching assets in all sites.
7. Click Save under Global Settings.

Enabling or disabling asset linking across sites

35

Ensuring complete coverage


The scope of your Nexpose investment includes the type of license and the number of Scan
Engines you purchase. Your license specifies a fixed, finite range of IP addresses. For example,
you can purchase a license for 1,000 or 5,000 IP addresses.
Make sure your organization has a reliable, dynamic asset inventory system in place to ensure
that your license provides adequate coverage. It may not be unusual for the total number of your
organization's assets to fluctuate on a fairly regular basis. As staff numbers grow and recede, so
does the number of workstations. Servers go on line and out of commission. Employees who are
travelling or working from home plug into the network at various times using virtual private
networks (VPNs).
This fluidity underscores the importance of having a dynamic asset inventory. Relying on a
manually maintained spreadsheet is risky. There will always be assets on the network that are
not on the list. And, if they're not on the list, they're not being managed. Result: added risk.
According to a paper by the technology research and advisory company, Gartner, Inc., an up-todate asset inventory is as essential to vulnerability management as the scanning technology
itself. In fact, the two must work in tandem:
The network discovery process is continuous, while the vulnerability assessment scanning
cycles through the environment during a period of weeks. (Source: A Vulnerability
management Success Story published by Gartner, Inc.)
The paper further states that an asset database is a foundation that enables other vulnerability
technologies and with which remediation becomes a targeted exercise.
The best way to keep your asset database up to date is to perform discovery scans on a regular
basis.

Ensuring complete coverage

36

Planning your Scan Engine deployment


Your assessment of your security goals and your environment, including your asset inventory, will
help you plan how and where to deploy Scan Engines. Keep in mind that if your asset inventory is
subject to change on continual basis, you may need to modify your initial Scan Engine
deployment over time.
Any deployment includes a Security Console and one or more Scan Engines to detect assets on
your network, collect information about them, and test these assets for vulnerabilities. Scan
Engines test vulnerabilities in several ways. One method is to check software version numbers,
flagging out-of-date versions. Another method is a safe exploit by which target systems are
probed for conditions that render them vulnerable to attack. The logic built into vulnerability tests
mirrors the steps that sophisticated attackers would take in attempting to penetrate your network.
The application is designed to exploit vulnerabilities without causing service disruptions. It does
not actually attack target systems.
One way to think of Scan Engines is that they provide strategic views of your network from a
hackers perspective. In deciding how and where to deploy Scan Engines, consider how you
would like to see your network.

View your network inside-out: hosted vs. distributed Scan Engines


Two types of Scan Engine options are availablehosted and distributed. You can choose to use
only one option, or you can use both in a complementary way. It is important to understand how
the options differ in order to deploy Scan Engines efficiently. Note that the hosted and distributed
Scan Engines are not built differently. They merely have different locations relative to your
network. They provide different views of your network.
Hosted Scan Engines allow you to see your network as an external attacker with no access
permissions would see it. They scan everything on the periphery of your network, outside the
firewall. These are assets that, by necessity, provide unconditional public access, such as Web
sites and e-mail servers.

Planning your Scan Engine deployment

37

Note: If your organization uses outbound port filtering, you would need to modify your firewall
rules to allow hosted Scan Engines to connect to your network assets.
Rapid7 hosts and maintains these Scan Engines, which entails several benefits. You dont have
to have to install or manage them. The Scan Engines reside in continuously monitored data
centers, ensuring high standards for availability and security.
With these advantages, it might be tempting to deploy hosted Scan Engines exclusively.
However, hosted Scan Engines have limitations in certain use cases that warrant deploying
distributed Scan Engines.

Distribute Scan Engines strategically


Distributed Scan Engines allow you to inspect your network from the inside. They are ideal for
core servers and workstations. You can deploy distributed Scan Engines anywhere on your
network to obtain multiple views. This flexibility is especially valuable when it comes to scanning a
network with multiple subnetworks, firewalls, and other forms of segmentation.

Distribute Scan Engines strategically

38

Note: Scan Engines do not store scan data. Instead, they immediately send the data to the
Security Console.

But, how many Scan Engines do you need? The question to ask first is, where you should you put
them?
In determining where to put Scan Engines, its helpful to look at your network topology. What are
the areas of separation? And where are the connecting points? If you can answer these
questions, you have a pretty good idea of where to put Scan Engines.
It is possible to operate a Scan Engine on the same host computer as the Security Console.
While this configuration may be convenient for product evaluation or small-scale production
scenarios, it is not appropriate for larger production environments, especially if the Scan Engine
is scanning many assets. Scanning is a RAM-intensive process, which can drain resources away
from the Security Console.
Following are examples of situations that could call for the placement of a Scan Engine.

Distribute Scan Engines strategically

39

Firewalls, IDS, IPS, and NAT devices


You may have a firewall separating two subnetworks. If you have a Scan Engine deployed on
one side of this firewall, you will not be able to scan the other subnetwork without opening the
firewall. Doing so may violate corporate security policies.
An application-layer firewall may have to inspect every packet before consenting to route it. The
firewall has to track state entry for every connection. A typical scan can generate thousands of
connection attempts in a short period, which can overload the firewalls state table or state
tracking mechanism.
Scanning through an Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) can
overload the device or generate an excessive number of alerts. Making an IDS or IPS aware that
Nexpose is running a vulnerability scan defeats the purpose of the scan because it looks like an
attack. Also, an IPS can compromise scan data quality by dropping packets, blocking ports by
making them appear open, and performing other actions to protect assets. It may be desirable
to disable an IDS or IPS for network traffic generated by Scan Engines.
Having a Scan Engine send packets through a network address transition (NAT) device may
cause the scan to slow down, since the device may only be able to handle a limited number of
packets per second.
In each of these cases, a viable solution would be to place a Scan Engine on either side of the
intervening device to maximize bandwidth and minimize latency.
VPNs
Scanning across virtual private networks (VPNs) can also slow things down, regardless of
bandwidth. The problem is the workload associated with connection attempts, which turns VPNs
into bottlenecks. As a Scan Engine transmits packets within a local VPN endpoint, this VPN has
to intercept and decrypt each packet. Then, the remote VPN endpoint has to decrypt each
packet. Placing a Scan Engine on either side of the VPN tunnel eliminates these types of
bottlenecks, especially for VPNs with many assets.
Subnetworks
The division of a network into subnetworks is often a matter of security. Communication between
subnetworks may be severely restricted, resulting in slower scans. Scanning across subnetworks
can be frustrating because they are often separated by firewalls or have access control lists
(ACLs) that limit which entities can contact internal assets. For both security and performance
reasons, assigning a Scan Engine to each subnetwork is a best practice

Distribute Scan Engines strategically

40

Perimeter networks (DMZs)


Perimeter networks, which typically include Web servers, e-mail servers, and proxy servers, are
out in the open, which makes them especially attractive to hackers. Because there are so many
possible points of attack, it is a good idea to dedicate as many as three Scan Engines to a
perimeter network. A hosted Scan Engine can provide a view from the outside looking in. A local
Scan Engine can scan vulnerabilities related to outbound data traffic, since hacked DMZ assets
could transmit viruses across the Internet. Another local Scan Engine can provide an interior view
of the DMZ.
ACLs
Access Control Lists (ACLs) can create divisions within a network by restricting the availability of
certain network assets. Within a certain address space, such as 192.168.1.1/254, Nexpose may
only be able to communicate with 10 assets because the other assets are restricted ay an ACL. If
modifying the ACL is not an option, it may be a good idea to assign a Scan Engine to ACLprotected assets.
WANs and remote asset locations
Sometimes an asset inventory is distributed over a few hundred or thousand miles. Attempting to
scan geographically distant assets across a Wide Area Network (WAN) can tax limited
bandwidth. A Scan Engine deployed near remote assets can more easily collect scan data and
transfer that data to more centrally located database. It is less taxing on network resources to
perform scans locally. Physical location can be a good principle for creating a site. See the topic
Configuring scan credentials in the users guide. This is relevant because each site is assigned to
one Scan Engine.
Other factors that might warrant Scan Engine placement include routers, portals, third-partyhosted assets, outsourced e-mail, and virtual local-area networks.

Deploying Scan Engine Pools


If your license enables Scan Engine pooling, you can use pools to enhance the consistency and
speed of your scan coverage. A pool is a group of Scan Engines over which a scan job is
distributed. Pools are assigned to sites in the same way that individual Scan Engines are.
Tip: See Finding out what features your license supports in Help or the user's guide.

Deploying Scan Engine Pools

41

Pooling provides two main benefits:


l

Scan load balancing prevents overloading of individual Scan Engines. When a pool is
assigned to a site, scan jobs are distributed throughout the pool, reducing the load on any
single Scan Engine. This approach can improve overall scan speeds.
Fault tolerance prevents scans from failing due to operational problems with individual Scan
Engines. If the Security Console contacts one pooled Scan Engine to start a scan, but the
Scan Engine is offline, the Security Console simply contacts the next pooled Scan Engine. If a
Scan Engine fails while scanning a given asset, another engine in that pool will scan the asset.
Also, the application monitors how many jobs it has assigned to the pooled engine and does
not assign more jobs than the pooled engine can run concurrently based on its memory
capacity.

Note: The algorithm for how much memory a job takes is based on the configuration options
specified in the scan template.
You can configure and manage pools using the Web interface. See the topic Working with Scan
Engine pools in Help or the user's guide. You also can use the extended API v1.2. See the API
Guide.
Best practices for deploying and scaling pools
For optimal performance, make sure that pooled Scan Engines are located within the same
network or geographic location. Geographically dispersed pools can slow down scans. For
example, if a pool consists of one engine in Toronto and one in Los Angeles, and this pool is used
to scan a site of assets located in Los Angeles, part of that load will be distributed to the Toronto
engine, which will take longer to scan the assets because of the geographical distance.
To improve the performance of pools, you can add Scan Engines or increase the amount of RAM
allocated to each pooled engine. By increasing RAM, you can increase the number of
simultaneous sites that can be scanned and increase the number of assets that each engine
scans simultaneously, which, in turn, expands the scanning capacity of the pool. See the topic
Tuning performance with simultaneous scan tasks in Help or the user's guide.

Deploying Scan Engine Pools

42

Setting up the application and getting started


Once youve mapped out your Scan Engine deployment, youre more than halfway to planning
your installation. The next step is to decide how you want to install the main componentsthe
Security Console and Scan Engines.
Understanding deployment options
Nexpose components are available in two versions. The hardware/software Appliance is a plugand-play device that contains the components of a Security Console and a Scan Engine. When
you purchase an Appliance, it can be configured to run as a Scan Engine or as a Security
Console with a local Scan Engine.
In some ways, an Appliance is a simpler solution than the software-only version of the product,
which requires you to allocate your own resources to meet system requirements. When you
install Nexpose software on a given host, your options as with the Applianceinclude running
the application as a just a Scan Engine or as a Security Console and Scan Engine.
Installation scenarioswhich one are you?

The different ways to install Nexpose address different business scenarios and production
environments. You may find one of these to be similar to yours.
Small business, internal network

The owner of a single, small retail store has a network of 50 or 60 work stations and needs to
ensure that they are PCI compliant. The assets include registers, computers for performing
merchandise look-ups, and file and data servers. They are all located in the same building. A
software-only Security Console/Scan Engine on a single server is sufficient for this scenario.
Mid-size company with some remote locations

A company has a central office and two remote locations. The headquarters and one of the other
locations have only a handful of assets between them. The other remote location has 300 assets.
Network bandwidth is mediocre, but adequate. It definitely makes sense to dedicate a Scan
Engine to the 300-asset location. The rest of the environment can be supported by a Security
Console and Scan Engine on the same host. Due to bandwidth limitations, it is advisable to scan
this network during off-hours.
Global enterprise with multiple, large remote locations

A company headquartered in the United States has locations all over the world. Each location
has a large number of assets. Each remote location has one or more dedicated Scan Engines.
One bank of Scan Engines at the U.S. office covers local scanning and provides emergency
backup for the remote Scan Engines. In this situation, it is advisable not to use the Scan Engine

Setting up the application and getting started

43

that shares the host with the Security Console, since the Security Console has to manage
numerous Scan Engines and a great deal of data.
Where to put the Security Console
Unlike Scan Engines, the Security Console is not restricted in its performance by its location on
the network. Consoles initiate outbound connections with Scan Engines to initiate scans. When a
Security Console sends packets through an opening in a firewall, the packets originate from
inside the firewall and travel to Scan Engines outside. You can install the Security Console
wherever it is convenient for you.
One Security Console is typically sufficient to support an entire enterprise, assuming that the
Security Console is not sharing host resources with a Scan Engine. If you notice that the Security
Consoles performance is slower than usual, and if this change coincides with a dramatic
increase in scan volume, you may want to consider adding a second Security Console.
Configuring the environment involves pairing each installed Scan Engine with a Security
Console. For information on pairing Security Consoles and Scan Engines, see Starting a static
site configuration in the users guide.
A deployment plan for Example, Inc.
Lets return to the environment table for Example, Inc.

Network segment

Address space

No. of
assets

Location

Asset function

New York Sales

10.1.0.0/22

254

Building 1:
Floors 1-3

Work stations

New York IT/Administration

10.1.10.0/23

50

Building 2:
Floor 2

Work stations
Servers

New York printers

10.1.20.0/24

56

Buildings 1 & 2

Printers

New York DMZ

172.16.0.0/22

30

Co-location facility

Web server
Mail server

Madrid sales

10.2.0.0/22

65

Building 3:
Floor 1

Work stations

Madrid development

10.2.10.0/23

130

Building 3:
Floors 2 & 3

Work stations
Servers

Madrid printers

10.2.20.0/24

35

Building 3:
Floors 1-3

Printers

Madrid DMZ

172.16.10.0/24

15

Building 3:
dark room

File server

Setting up the application and getting started

44

A best-practices deployment plan might look like this:


The eight groups collectively contain a total of 635 assets. Example, Inc., could purchase a fixednumber license for 635 licenses, but it would be wiser to purchase a discovery for the total
address space. It is always a best practice to scan all assets in an environment according to
standards such as PCI, ISO 27002, or ISO 27001. This practice reflects the hacker approach of
viewing any asset as a possible attack point.
Example, Inc., should distribute Nexpose components throughout its four physical locations:
l

Building 1

Building 2

Building 3

Co-Location facility

The IT or security team should evaluate each of the LAN/WAN connections between these
locations for quality and bandwidth availability. The team also should audit these pipes for
devices that may prevent successful scanning, such as firewalls, ACLs, IPS, or IDS.
Finally the team must address any logical separations, like firewalls and ACLs, which may
prevent access.
The best place for the Security Console is in New York because the bulk of the assets are there,
not to mention IT and administration groups.
Assuming acceptable service quality between the New York buildings, the only additional
infrastructure would be a Scan Engine inside the Co-Location facility.
Example, Inc., should install at least one Scan Engine in the Madrid location, since latency and
bandwidth utilization are concerns over a WAN link.
Finally, its not a bad idea to add one more Scan Engine for the Madrid DMZ to bypass any
firewall issues.
The following table reflects this plan.
Asset

Location

Security Console

New York: Building 2

Scan Engine #1

New York: Co-Location Facility

Scan Engine #2

Madrid: Building 3

Scan Engine #3

Madrid: dark room

Setting up the application and getting started

45

Your deployment checklist


When you are ready to install, configure, and run Nexpose, its a good idea follow a general
sequence. Certain tasks are dependent on others being completed.
You will find yourself repeating some of these steps:
l

install components

log onto the Security Console Web interface

configure Scan Engines, and pair them with the Security Console

perform vAsset discovery, if your license enables it

create one or more sites

assign each site to a Scan Engine

select a scan template for each site

schedule scans

create user accounts, and assign site-related roles and permissions to these accounts

run scans

configure and run reports

create asset groups to view reports and asset data

create user accounts, and assign asset-group-related roles and permissions to these
accounts

assign remediation tickets to users

re-run scans to verify remediation

perform maintenance tasks

Planning for capacity requirements


If youre a Nexpose administrator, use the capacity planning guidelines in this section to estimate
total scan time, disk usage over time, and network bandwidth usage so that the application can
continue to function and scale as needed. This document helps you predict your minimum system
requirements, such as CPU, RAM, network, and disk required for application deployment.
Tuning options for maximum scan performance are also provided, including how many Scan
Engines and scan threads to use. These guidelines address capacity needs across a wide variety
of deployment types. Different scanning and reporting scenarios and formulas are provided to
help you calculate capacity needs for each unique deployment.

Planning for capacity requirements

46

The purpose of capacity planning


Capacity planning is the process of determining the resources needed by an application over time
by identifying current usage trends and analyzing growth patterns. As usage grows, the main
challenge is to ensure that system performance is consistent over long periods of time and the
system has enough resources to handle the capacity for future needs. This document gives
detailed information on the capacity usage patterns of the application based on intended usage,
so that you can plan, analyze and fix capacity issues before they become a problem.
The capacity planning approach
The approach is first to analyze the current capacity under certain conditions such as numbers of
assets, number of scans performed, and the frequency and number of reports that are generated
and then to plan for future capacity needs. Tests were completed with a wide variety of individual
assets in order to accurately capture the impact that different types of assets have on scan time,
network utilization, and disk usage. The results of these tests were then used to create formulas
that you can use to predict capacity needs for various usage scenarios. These formulas were
then tested with real-world scanning scenarios to get repeatable, empirical measurements of disk
usage, scan duration, and network utilization.
For the purpose of capacity testing, we used our Series 5000 Appliance for the Security Console
and our Series 1000 Appliance for our Scan Engine testing.
Single-asset scan duration and disk usage
Every asset is different due to variables such as operating system installed, responsiveness,
open ports, applications installed, services running, and patch levels. These variables, in addition
to scan configuration and network conditions, affect the application's scan time and disk usage
needs.
These capacity planning guidelines are based on results from authenticated and unauthenticated
scans that were run with the Full Audit scan template.
Since scan duration and disk usage needs vary based on types of assets and the network
environment, the capacity planning guidelines incorporate a variety of assets into calculations of
future capacity requirements. The following tables show average scan times and disk usage for
sample assets that might appear in your network. These assets were tested within a local
network with latency below 1 ms so that scan time could be isolated from network quality
variables.

Planning for capacity requirements

47

Typical scan duration and disk usage for unauthenticated scanning

Open
TCP
ports

Asset Type

Open UDP
ports

Disk
usage
(KB)

Discovered
vulnerabilities

Scan duration
(mins)

Windows XP Pro SP3

32

Windows 7 Pro SP1

10

28

Windows 2008 R2
w/Exchange

48

100

10

Mac OSX 10.6

28

516

RedHat Enterprise
Linux 6 WS

24

ESXi 5 Hypervisor

108

Cisco IOS 12.3

25

64

125

Average

Typical scan duration and disk usage for authenticated scanning

Total open
TCP ports

Asset Type

Total open
UDP ports

Discovered
vulnerabilities

Disk
usage
(KB)

Scan
duration
(mins)

Windows XP Pro
SP3

18

296

Windows 7 Pro
SP1

10

256

332

Windows 2008 R2
w/Exchange

48

177

628

14

Mac OSX 10.6

456

1052

RedHat Enterprise
1
Linux 6 WS

123

320

ESXi 5 Hypervisor

136

Cisco IOS 12.3

25

64

404

Average

Typical scan duration and disk usage for unauthenticated scanning

48

Disk usage for reporting on unauthenticated scans

Disk Usage
for
Remediation
Plan PDF
Report (KB)

Disk Usage for


Disk Usage for
PCI
Disk Usage for
CSV Export
Vulnerability XML Export 2.0
Report of all
Details PDF
Report (KB)
fields (KB)
Report (KB)

Windows XP Pro SP3

10

73

31

25

Windows 7 Pro SP1

73

28

20

Windows 2008 R2
w/Exchange

14

129

64

32

Mac OSX 10.6

15

189

89

63

RedHat Enterprise Linux 6


WS

72

28

21

ESXi 5 Hypervisor

12

95

49

37

Cisco IOS 12.3

13

190

104

75

Average

12

117

56

39

Asset Type

Disk usage for reporting on authenticated scans

Disk Usage
for
Remediation
Plan PDF
Report (KB)

Disk Usage for


Disk Usage for
PCI
Disk Usage for
CSV Export
Vulnerability XML Export 2.0
Report of all
Details PDF
Report (KB)
fields (KB)
Report (KB)

Windows XP Pro SP3

23

143

110

94

Windows 7 Pro SP1

97

1,939

1,432

1,048

Windows 2008 R2
w/Exchange

165

4,462

4,104

3,054

Mac OSX 10.6

38

1,821

901

642

RedHat Enterprise Linux 6


WS

115

1,726

2,314

1,708

ESXi 5 Hypervisor

13

101

51

38

Cisco IOS 12.3

13

190

104

75

Average

66

1,493

1,288

951

Asset Type

Disk usage for reporting on unauthenticated scans

49

Disk usage for Web scanning


The Web scanning feature can crawl Web sites to determine their structure and perform a variety
of checks for vulnerabilities. It evaluates Web applications for SQL injection, cross-site scripting
(CSS/XSS), backup script files, default configuration settings, readable CGI scripts, and many
other issues resulting from custom software defects or misconfigurations.
The following table compares disk usage, scan duration, and vulnerabilities found when using
three different scan settings for a sample asset with a known Web site. This table is based on the
Windows 2003 server in the Single Asset Scan Duration and Disk Usage section.
The Full Audit template scans all well-known ports. You can improve scan time for Web scanning
by restricting the ports to the ones used by your Web server.

Scan settings

Vulnerabilities
discovered

Disk usage (KB)

Scan duration (mins)

Full Audit, Web Spider off,


unauthenticated scan

41

224

13

Full Audit, Web Spider off,


authenticated scan

66

3128

13

Full Audit, Web Spider on,


authenticated scan

112

3596

19

Full Audit, Web Spider off,


unauthenticated scan

41

224

13

Disk usage for reporting on authenticated scans

50

The Web site used for testing was a discussion forum on a WAMP stack. The Web site is
approximately 8.5 MB in file size and contains approximately 100 unique Web pages or URLs.
The scan settings used are the default using on the Full Audit template:
l

Test cross-site scripting in a single scan = YES

Include query strings when spidering = NO

Check use of common user names and passwords = NO

Maximum number of foreign hosts to resolve = 100

Spider request delay (ms) = 20

Maximum directory levels to spider = 6

No spidering time limit

Spider threads per Web server = 3

HTTP daemons to skip while spidering = Virata-EmWeb, Allegro-Software-RomPager,


JetDirect, HP JetDirect, HP Web Jetadmin, HP-ChaiSOE, HP-ChaiServer, CUPS,
DigitalV6-HTTPD, Rapid Logic, Agranat-EmWeb, cisco-IOS, RAC_ONE_HTTP, RMC
Webserver, EWS-NIC3, EMWHTTPD, IOS
Maximum link depth to spider = 6

As the preceding tables indicate, the scan duration and disk usage varies based on the type of
asset and whether or not authentication is performed. Authenticated scans use credentials to
gain access to targets and, therefore, may discover more vulnerabilities than unauthenticated
scans due to the ability to enumerate software installed, users and groups configured, and file
and folder shares configured. Since all of this additional information is stored in the application,
the disk usage required for an authenticated scan is usually more than required for a
unauthenticated scan.
Effects of network latency on scan duration
Scan duration may vary based on network latency. The following graph shows the scan duration
for two sample assets when scanned with credentials under different network latencies. In the
capacity planning testing it was observed that network latencies of 100 ms increased scan times
by 15 to 25 percent, and network latencies of 300 ms increased scan times by approximately 35
percent for the assets tested. Actual impact may vary depending on the asset being scanned and
the scan settings.

Disk usage for reporting on authenticated scans

51

Single-asset policy scan duration and disk usage


By incorporating Policy Manager checks into your scans, you can verify compliance with industrystandard and U.S. government-mandated policies and benchmarks for secure configuration. If
you run Policy Manager scans, it is useful to factor their duration and impact on disk usage into
your capacity planning. The following table compares disk usage and scan duration for Policy
Manager scans of assets with different operating systems.
Each scan was authenticated, which is a requirement for Policy Manager. The scan templates
were customized versions of the built-in CIS (Center for Internet Security) template. For each
scan, the customized template included only those CIS benchmarks for the specific target
operating system.

Asset type and benchmark tested

Disk space consumed


(KB)

Scan time

Windows XP SP3 x86

3043

27 seconds

Windows 2008 R2 Enterprise x64

1816

15 seconds

Windows 7 Ultimate SP1 x86

1284

29 seconds

Red Hat 6.0 Workstation x64

1837

3 minutes

Disk usage: analysis and planning


As seen in the preceding section, varying disk usage is needed for scanning and reporting on
individual assets. Scanning and reporting account for the majority of disk usage for application
installations. This section will help you better understand the disk capacity needed over time

Disk usage for reporting on authenticated scans

52

when scanning large numbers of assets and generating a variety of reports from those scan
results.
The increase in disk space is proportional to the type of scans performed, the number of assets
being scanned, the number of scans, and number of reports generated. Based on the type of
installation and the overall usage, you can estimate required disk space to support your business
needs based on the following formula.
For the purpose of simplifying and normalizing capacity planning guidelines, it is assumed that
scan logs and log files are purged periodically and that application database maintenance is done
periodically. It is also assumed that application backups are stored outside of the application
directory. Periodic backups can use large amounts of disk space and should be archived offline in
case of disk failure.
This capacity planning data is based on scans with Nexpose. Newer versions may have different
capacity requirements due to increased vulnerability coverage and new features.
Total disk space requirement

Total Disk Space Required


= (K x NumberOfAssets x NumberOfScans )
+ (L x NumberOfAssets x NumberOfScans x NumberOfReportsGenerated )
+M

Parameter

Details

Disk usage by one scan of one asset

Disk usage of one report for one scan of one asset

Disk usage for fresh installation

The parameters K, L and M vary based on several characteristics of the assets being scanned
including the services running, software installed, vulnerabilities found and type of scan.
In order to calculate expected disk capacity needs, we can use values from the Single asset scan
duration and disk usage section as part of the formula. For example, let us assume 90 percent of
the environment is desktops and laptops and 10 percent of the environment is servers and
network infrastructure. The value for K can be calculated based on these assumptions:

Disk usage for reporting on authenticated scans

53

Asset type

Percentage

Disk usage for


scanning
unauthenticated (KB)

Disk usage for scanning


authenticated (KB)

RedHat Enterprise Linux


10%
6 WS

24

320

Windows 7 Pro SP1

70%

28

332

Windows 2008 R2

8%

100

628

Mac OSX 10.6

10%

516

1052

Cisco IOS 12.3

2%

64

64

83

421

Value of K (average disk usage


per scan of one asset)

The value for L can be calculated with the assumption that a remediation report and a CSV
export are generated for every single asset scanned, as seen in the following table:

Asset type

Percentage

Disk usage for


scanning
unauthenticated (KB)

Disk usage for scanning


authenticated (KB)

RedHat Enterprise Linux


10%
6 WS

30

1,823

Windows 7 Pro SP1

70%

28

1,145

Windows 2008 R2

8%

46

3,219

Mac OSX 10.6

10%

78

680

Cisco IOS 12.3

2%

88

88

36 KB

1,311 KB

Value of K (average disk usage


per scan of one asset)
Sample calculation

Now that the calculations for K and L have been made based on assumptions above, the total
disk capacity needs can be calculated. If 10,000 assets are scanned weekly and two reports are
generated for all assets every month, then the total disk space required for one year can be
calculated with the following formula:
Total disk space required for unauthenticated scanning of 10,000 assets weekly for one year and
generating two reports, CSV Export and Remediation Plan, every week:
= (0.081 X 10,000 X 52) + (0.035 X 10,000 X 2 X 52) + 1,240 MB
= 79,760 MB (~78 GB)

Disk usage for reporting on authenticated scans

54

Total disk space required for authenticated scanning of 10,000 assets weekly for one year and
generating two reports, CSV Export and Remediation Plan, every week:
= (.411 X 10,000 X 52) + (1.28 X 10,000 X 2 x 52) + 1,240 MB
= 1,546,160 MB (~1.47 TB)

Disk usage for reporting on authenticated scans

55

Scan Engine performance and network utilization


This section helps you answer the following questions:
l

How many scan engines do I need to scan X assets in Y days?

How long will it take me to scan X assets with N engines?

How much network bandwidth do I need to scan X assets at the same time?

Scan time estimation


The scan time depends on number of assets to be scanned, the type of assets being scanned,
the number of Scan Engines being used, and the network bandwidth. Scan time decreases as
the number of Scan Engines and number of scan threads increase for a fixed number of assets.
There is some additional overhead to adding Scan Engines due to the remote communication
required for retrieving the results; however, adding Scan Engines is the best way to horizontally
scale up the scanning ability of the application to larger numbers of assets in shorter periods of
time.
The following formula calculates estimated scan time based on number of assets, average scan
time per asset, number of scan threads and number of Scan Engines. Note that the network
configuration is also an important factor in number of scan engines needed. For example, if a
customer has 4 VLANS without connectivity between them, they will need one Scan Engines per
VLAN to be able to scan assets in that VLAN. Also, to scale horizontally across multiple scan
engines, the assets need to be split across sites.

Total Time in minutes

{For 1 Scan Engine }

1.2 x Avg .ScanTime (in minutes )x No.OfAssets


No .OfScanThreads

1.2 x Avg .ScanTimePerAsset (in minutes )x No.OfAssets


0.85x No .OfScanEngines x No.OfScanThreads

{For more than 1 Scan Engine }

The lower bound on both of these formulas will be the time it takes to scan the asset that takes the
longest. If one asset takes 30 minutes to scan, then the total scan time for all assets will never be
less than 30 minutes.
The preceding formula has been derived with number of simultaneous scan threads equal to 20.
Based on the information from the Single asset scan duration and disk usage section, the total
time to perform an unauthenticated scan of 10,000 assets with one Scan Engine would be the
following:
= (1.2 x 4 min x 10,000)/20 = 2,400 minutes = 40 hours

Disk usage for reporting on authenticated scans

56

The total time to perform an authenticated scan of 10,000 assets with one Scan Engine would be
the following:
= (1.2 x 6 min x 10,000)/20 = 3,600 minutes = 60 hours
Calculating the number of Scan Engines needed to scan X assets in Y days
Deciding how many Scan Engines to implement and where to put them requires a great deal of
careful consideration. It's one of the most important aspects of your deployment plan. If you do it
properly, you will have an excellent foundation for planning your sites, which is discussed in the
section Setting up the application and getting started. One way to project how many Scan
Engines you need is by tallying the total number of assets that you intend to scan and how quickly
you need to scan them. You can use the following formula to calculate number of Scan Engines
needed. For example, to scan 10,000 assets in four hours, use the following formula to calculate
the number of engines needed:

Total Engines =

1.2 x Avg .ScanTimePerAsset (in minutes ) x No .OfAssets


0.85 xNo .OfScanThreads x TotalTimeAvailable (in minutes )

For unauthenticated scanning, use the following:


= (1.2 x 4 min x 10,000)/(.85 x 20 x 240) = 12 engines required
For authenticated scanning use the following:
= (1.2 x 6 min x 10,000)/(.85 x 20 x 240) = 18 engines required
Note that the number of Scan Engines required may be determined by the scan templates used
and the accessibility of scan targets within the network topology. The preceding formula is to be
used for guidance in determining the number of Scan Engines needed for sheer throughput. It
assumes the Scan Engines have access to all the assets being scanned and that assets can be
equally distributed across sites. See Distribute Scan Engines strategically on page 38 in the for
more information for reasons why additional Scan Engines might be needed.
Network utilization
As the application scans for vulnerabilities over the network, a considerable amount of network
resources may be consumed. The amount of network bandwidth used is directly proportional to
number of assets being scanned simultaneously, the type of assets being scanned, and the scan
template settings. This section provides capacity guidelines of network utilization when assets
over the network were being scanned so that you can adjust your scan windows and scan
template settings to avoid affecting other critical network traffic or the accuracy of scan results.

Disk usage for reporting on authenticated scans

57

The following graph represents the network utilization for unauthenticated scans of different
numbers of assets in one site, with the number of scan threads (20) and the number of scan ports
(20) constant:

The network utilization would remain constant after a certain number of assets, because the
upper bound is determined by the total number of scan threads defined in the scan template.
Network utilization formulas are for the Scan Engine utilization only. The formulas and graphs do
not cover network utilization required to serve content to end users of the API or Web interface or
for communication between the Security Console and Scan Engines. Since the majority of
network usage and utilization is from Scan Engines, the other sources are considered negligible
for the purposes of capacity planning.
Running more simultaneous scans consumes more network bandwidth up to a certain point. The
following graph shows the network bandwidth consumption in two different scan scenarios
targeting a fixed number of assets.
l

Scenario 1: One site, unauthenticated scan, 20 threads configured , 20 ports scanned


Scenario 2: Two sites, unauthenticated scan, 20 threads configured for each site, 20 ports
scanned for each site
Scenario 3: Three Sites, unauthenticated scan, 20 threads configured for each site, 20 port
scanned for each site

The following graph shows the comparative network utilization based on these three scenarios:

Disk usage for reporting on authenticated scans

58

When you scan simultaneous assets scans with additional sites, scan duration would decrease,
but at the expense of network bandwidth and CPU utilization.

Peak Network Bandwidth (Mbps ) = 0.4x No .OfAssetsScanned Simultaneously


Average Network Bandwidth (Mbps ) = 0.45x PeakNetworkBandwidth
Tuning the database server for maximum performance
The application includes a PostgreSQL database server that can be tuned for better performance
based on the amount of RAM available to the Security Console host. See Tuned PostgreSQL
settings on page 16 for more information on how to tune the database.
Tuning scan templates for maximum performance
Scan templates have a wide variety of options that can you can adjust to deliver greater
throughput when scanning. Some of the most effective tuning options are to increase the number
of scan threads, reduce the number of retries, and identify the exact ports you want to scan.
These actions enable the Scan Engine to scan more assets simultaneously. See the Scan
Template section in the users guide or Help for information on how to tune templates for
maximum performance.
Scaling with multiple Scan Engines
As seen by the Scan Engine performance section, multiple Scan Engines can provide greater
throughput for scanning and enable application deployments to horizontally scale to large
numbers of assets. Since the Security Console is responsible for generating reports, integrating
scan results, and serving up content for end users, it is highly recommended that you use
distributed Scan Engines when scanning more than a few hundred assets.
Scaling with multiple Security Consoles
You also can deploy multiple Security Consoles in environments where certain geographic
regions have their own scanning or reporting needs; or consolidated reporting is either

Disk usage for reporting on authenticated scans

59

unnecessary, or can be done outside of application export capabilities or the API. Scaling with
multiple consoles can accelerate scan integration and report generation, which can allow you to
get information to the people responsible for remediation sooner. For more information, see
Where to put the Security Console on page 44.

Disk usage for reporting on authenticated scans

60

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 aGlobal
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 nonadministrative users in these groups will be senior managers who view the executive reports to
track progress in the company's vulnerability management program.

Managing users and authentication

61

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 on page 72.

Configuring roles and permissions

62

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

Description

Role

Manage Sites

Create, delete, and configure all attributes of sites, except


for user access. Implicitly have access to all sites. Manage
Global
shared scan credentials. Other affected permissions:
Administrator
When you select this permission, all site permissions
automatically become selected. See Site permissions.

Manage Scan
Templates

Create, delete, and configure all attributes of scan


templates.

Global
Administrator

Manage Report
Templates

Create, delete, and configure all attributes of report


templates.

Global
Administrator,
Security Manager
and Site Owner,
Asset Owner,
User

Manage Scan
Engines

Create, delete, and configure all attributes of Scan


Engines; pair Scan Engines with the Security Console.

Global
Administrator

Manage Policies

Copy existing policies; edit and delete custom policies.

Global
Administrator

Appear on user lists in order to be assigned remediation


tickets and view reports.
Appear on Ticket
and Report Lists

Prerequisite:A user with this permission must also have


asset viewing permission in any relevant site or asset
group: View Site Asset Data;View Group Asset Data

Global
Administrator,
Security Manager
and Site Owner,
Asset Owner,
User

Configure Global
Settings

Configure settings that are applied throughout the entire


Global
environment, such as risk scoring and exclusion of assets
Administrator
from all scans.

Manage Tags

Create tags and configure their attributes. Delete tags


except for built-in criticality tags.Implicitly have access to
all sites.

Global
Administrator

Configuring roles and permissions

63

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

Description

Role

View discovered information about all


assets in accessible sites, including IP
addresses, installed software, and
vulnerabilities.

Global Administrator,
Security Manager and Site
Owner,
Asset Owner,
User

Specify Site
Metadata

Enter site descriptions, importance


ratings, and organization data.

Global Administrator,
Security Manager and Site
Owner

Specify Scan
Targets

Add or remove IP addresses, address


ranges, and host names for site scans.

View Site Asset


Data

Assign Scan Engine Assign a Scan Engine to sites.


Assign Scan
Template

Assign a scan template to sites.

Create, delete, and configure all


Manage Scan Alerts attributes of alerts to notify users about
scan-related events.

Global Administrator
Global Administrator
Global Administrator,
Security Manager and Site
Owner
Global Administrator,
Security Manager and Site
Owner

Provide logon credentials for deeper


scanning capability on passwordprotected assets.

Global Administrator,
Security Manager and Site
Owner

Schedule Automatic Create and edit site scan schedules.


Scans

Global Administrator,
Security Manager and Site
Owner

Manage Site
Credentials

Start Unscheduled
Scans

Manually start one-off scans of


accessible sites (does not include ability
to configure scan settings).

Global Administrator, Security


Manager and Site Owner, Asset
Owner

Manually remove asset data from


accessible sites.
Purge Site Asset
Data

Prerequisites:A user with this


permission must also have one of the
following permissions: View Site Asset
Data;View Group Asset Data

Global Administrator

Manage Site Access Grant and remove user access to sites.

Global Administrator

Configuring roles and permissions

64

Asset Group permissions


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

Description

Manage
Dynamic
Asset
Groups

Create dynamic asset groups. Delete and configure all attributes


of accessible dynamic asset groups except for user access.
Implicitly have access to all sites.

Role

Global
Administrator

Note: A user with this permission has the ability to view all asset
data in your organization.
Manage
Static
Asset
Groups

Create static asset groups. Delete and configure all attributes of


accessible static asset groups except for user access.

View
Group
Asset
Data

View discovered information about all assets in accessible asset


groups, including IP addresses, installed software, and
vulnerabilities.

Manage
Group
Assets

Add and remove assets in static asset groups.

Manage
Asset
Group
Access

Grant and remove user access to asset groups.

Global
Prerequisite:A user with this permission must also have the
Administrator
following permissions and access to at least one site to effectively
manage static asset groups: Manage Group Assets; View Group
Asset Data

Note:This permission does not include ability to delete


underlying asset definitions or discovered asset data.
Prerequisite: A user with this permission must also have of the
following permission: View Group Asset Data

Global
Administrator ,
Security
Manager and
Site Owner,
Asset Owner,
User

Global
Administrator

Global
Administrator

Configuring roles and permissions

65

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.
Permission

Description

Role

Create
Reports

Create and own reports for accessible assets; configure


all attributes of owned reports, except for user access.

Use
Restricted
Report
Sections

Create report templates with restricted sections;


configure reports to use templates with restricted
sections.

Global Administrator ,
Security Manager and
Site Owner,
Prerequisites:A user with this permission must also have Asset Owner,
one of the following permissions: View Site Asset Data;
User
View Group Asset Data

Global Administrator
Prerequisites: A user with this permission must also have
one of the following permissions: Manage Report
Templates

Manage
Report
Access

Grant and remove user access to owned reports.

Global Administrator

Ticket permissions
These permissions only apply to assets to which a user has been granted access.
Permission
Create
Tickets

Description

Role

Create tickets for vulnerability remediation tasks.


Prerequisites:A user with this permission must also have
one of the following permissions: View Site Asset
Data;View Group Asset Data

Close
Tickets

Close or delete tickets for vulnerability remediation tasks.


Prerequisites:A user with this permission must also have
one of the following permissions:View Site Asset
Data;View Group Asset Data

Global Administrator ,
Security Manager and
Site Owner,
Asset Owner,
User
Global Administrator ,
Security Manager and
Site Owner,
Asset Owner,
User

Vulnerability exception permissions


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

Configuring roles and permissions

66

Permission

Description

Role

Submit
Vulnerability
Exceptions

Submit requests to exclude vulnerabilities from reports.

Global Administrator ,
Security Manager and
Site Owner,
Asset Owner,
User

Review
Vulnerability
Exceptions

Prerequisites:A user with this permission must also


have one of the following permissions: View Site Asset
Data; View Group Asset Data
Approve or reject requests to exclude vulnerabilities
from reports.
Prerequisites:A user with this permission must also
have one of the following permissions: View Site Asset
Data; View Group Asset Data

Delete
Vulnerability
Exceptions

Global Administrator

Delete vulnerability exceptions and exception requests.


Prerequisites:A user with this permission must also
have one of the following permissions: View Site Asset
Data; View Group Asset Data

Global Administrator

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:
l

Manage all functions related to user accounts, roles, and permissions.

Manage vConnections and vAsset discovery.

Manage configuration, maintenance, and diagnostic routines for the Security Console.

Manage shared scan credentials.

Configuring roles and permissions

67

Security Manager and Site Owner


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

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 Managers ability to work in
accessible sites andassets 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:
l

Manage Report Templates

Appear on Ticket and Report Lists

View Site Asset Data

Start Unscheduled Scans

View Group Asset Data

Create Reports

Configuring roles and permissions

68

User
Although user can refer generically to any owner of aNexposeaccount, 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:
l

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 Userslinks on the Administrationpage provide access to pages for creating and managing
user accounts. Click managenext to Users to view the Userspage. 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 Editfor any listed account, and change its attributes.
The application displays the User Configurationpanel. The process for editing an account is
the same as the process for creating a new user account. See Configure general user
account attributes on page 70.

Managing and creating user accounts

69

To delete an account and reassign tickets or reports:


1. Click Deletefor 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 Useron the Users page.
2. (Optional) Click Createnext to Userson the Administrationpage. The Security Console
displays the Generalpage 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 on page 72.
5. Check the Account enabledcheck 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.

Managing and creating user accounts

70

Assign a role and permissions to a user


Assigning a role and permissions to a new user allows you to control that users 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 Saveto 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.

Managing and creating user accounts

71

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.
The application provides single-sign-on external authentication with two sources:
l

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.
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.

Using external sources for user authentication

72

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 sourcesto 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 referralsif 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.

Using external sources for user authentication

73

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 IDmaps to the users 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 clients
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 Userson the Administration page,
The Security Console displays the User Configuration panel.

Using external sources for user authentication

74

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>

Using external sources for user authentication

75

You can specify any of the following ticket encryption types:


l

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.

Setting a password policy

76

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.

Setting a password policy

77

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.

Setting a password policy

78

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

Setting a password policy

79

Setting password policies


Setting user password policies for criteria such as size, complexity, or expiration is a security best
practice that makes it difficult for would-be attackers to brute-force or guess passwords. Your
organization may also mandate this practice as a security control.
If you are a Global Administrator, you can create a password policy by taking the following steps:
1. Click the Administration tab.
2. In the Users area of the Administration page, select the password policy link.
3. On the Password Policy page, enter a unique name to help you identify the policy.
4. Select values for the following password attributes as desired:
l

the number of days that elapse, after which the password expires

the maximum number of characters

the minimum number of characters

the required number of special characters; supported characters include the following:
`~!@#$%^&*()-_=+[{]}\\|;:\'\"<,>./?

the required number of numerals

the required number of capital letters

5. Click Save.
If you set a expiration window, the expiration date and time appears in the Users table, which you
can see by selecting the manage link for Users on the Administration page.

Setting password policies

80

Managing the Security Console


Although the default Security Console settings should work for a broad range of network
environments, you can change settings to meet specific scanning requirements.
Tip: Click Administer next to Console on the Administrationpage to launch the Security Console
Configuration panel.
Viewing general configuration settings
On the Generalpage, you can view the version and serial numbers for the instance of the
Security Console that you are using.

Changing the Security Console Web server default settings


The Security Console runs its own Web server, which delivers the user interface.
To change the Security Console web server default settings:
1. Go to the Administration page.
2. Click Manage settings for the Security Console.
3. Go to the Web Server page.
4. Enter a new number for the access port.
5. Enter a new session time-out. This value is the allowed number of seconds of user inactivity
after which the Security Console times out, requiring a new logon.
6. Enter new numbers for initial request and maximum request handler threads, if necessary.
It is recommended that you consult Technical Support first. In this context, threads refer to
the number of simultaneous connections that the Security Console will allow. Typically a
single browser session accounts for one thread. If simultaneous user demand is high, you
can raise the thread counts to improve performance. The Security Console will increase the
thread count dynamically if required, so manual increases may be unnecessary.
7. Enter a new number for failed logon threshold if desired. This is the number of failed logon
attempts that the Security Console permits before locking out the would-be user.
8. Click Save.

Managing the Security Console

81

Managing the HTTPS certificate


The application provides a self-signed X.509 certificate, which is created during installation. It is
recommended that you replace it with a certificate that is signed by a trusted certifying authority
(CA).
Note: The signed certificate must be based on an application-generated CSR. The application
does not allow you to import an arbitrary key pair or certificate that you generated.
To manage certificates and generate a new certificate signing request (CSR):
1. Go to the Administration page.
2. Click Manage settings for the Security Console.
3. Go to the Web Server page.
4. Click Manage Certificate.
The Security Console displays a box titled Manage Certificate.

Manage Certificate

Changing the Security Console Web server default settings

82

5. Click Create New Certificate.


The Security Console displays a box for new certificate information.
6. Enter the information and click Create.

Manage CertificateCreate New Certificate

A dialog box appears indicating that a new self-signed certificate was created.
7. Click Create CSR now.
You can click Laterto come back to this step and continue the process at another time.
8. Copy the generated CSR and send it to your CA.
9. Click Import Certificateon the Manage Certificatedialog after it is signed by your CA.
10. Paste it in the text box and click Import.

Changing the Security Console Web server default settings

83

Manage CertificateImport certificate signing request

11. Click Save to save the new Security Console information.


The new certificate name appears on the Web Server page.

Changing default Scan Engine settings


The Security Console communicates with distributed Scan Engines over a network to initiate
scans and retrieve scan results. If you want to obtain scan status information more quickly or
reduce bandwidth or resource consumption required for Security Console-to-Scan-Engine
communication, you can tune various settings on the Scan Engines page of the Security Console
Configurationpanel. See the following sections:
l

Configuring Security Console connections with distributed Scan Engines on page 84

Managing the Security Console on page 81

Retrieving incremental scan results from distributed Scan Engines on page 89

Configuring Security Console connections with distributed Scan Engines


The Security Console establishes connections with distributed Scan Engines to launch scans
and retrieve scan results. This communication can be disrupted by low network bandwidth, high
latency, or situations in which Scan Engines are performing high numbers of simultaneous scans.
If any of these conditions exist in your environment, you may want to consider increasing
connection settings on the Scan Engines configuration page:
Note: It is recommended that you consult with Technical Support before tuning these settings.

Changing default Scan Engine settings

84

The Connection timeoutsetting controls how long the Security Console waits for the creation
of a connection with a distributed Scan Engine.
The Response timeoutsetting controls how long the Security Console waits for a response
from an Scan Engine that it has contacted.

To configure these settings, take the following steps.


1. Go to the Scan Enginespage in the Security Console Configuration panel.
2. Click the Administration tab.
3. On the Administrationpage, click manage for the Security Console.
4. Click Scan Enginesin the Security Console Configuration panel.
5. Adjust the Connections settings.
6. Edit the value in the Connection timeout field to change the number of milliseconds that elapse
before a connection timeout occurs.
7. Edit the value in the Response timeout field to change the number of milliseconds that elapse
before the Security Console no longer waits for a response from an Scan Engine.
8. Click Save in the top bar of the panel to save the changes.
9. Restart the Security Console so that the configuration changes can take effect.
Tip: Because millisecond values can be difficult to read, a time value that is easier to read
appears to the right of each value field. As you change either timeout value, note how the
equivalent value changes.

Creating a trusted pairing from a Scan Engine to a Security Console


You can create a pairing from a Scan Engine to a Security Console by creating a trusted
connection between with them. A shared secret is a piece of data used so the console will
recognize and trust the incoming communication from the engine.
Note: Each generated shared secret can be used by multiple engines. A shared secret is valid for
60 minutes from when it was generated. After 60 minutes, you will need to generate a new
Shared Secret if you want to create additional trusted pairings.
To create a trusted pairing:

Creating a trusted pairing from a Scan Engine to a Security Console

85

1. Ensure that no network-based or host-based firewall is blocking access to port 40815 on


your Nexpose Security Console. If you want to use a port other than 40815, change this
line in your console's nsc.xml file (\[installation directory]\nsc\conf\nsc.xml) to the port you
want to use:
<EngineListener port="40815"/>

Restart your Security Console.


2. Generate a shared secret on the Security Console. To do so, go to the Administration page
and click manage next to Engines. Under Generate Scan Engine Shared Secret, click
Generate. Copy the Shared Secret to a text file.
3. Log on to the host where the Scan Engine is running and access the command line interface.
For Windows hosts, you can use Remote Desktop Protocol. For Unix and related hosts, you
can use SSH. For Linux, access the engine's console by using the command:
screen -r

4. Add the Security Console on your engine using the IP address or the hostname of the
machine hosting the Security Console. Example:
add console 10.1.1.4

5. Find the ID of the Security Console by typing


show consoles

6. Connect to the Security Console using the ID you just found. Example:
connect to console 2

7. Verify that the connection was successful. Type:


show consoles

For the console ID you just connected, the value of connectTo should be 1.
8. Add the shared secret to that Security Console on the engine. Example:
add shared secret 2

At the prompt, paste in the shared secret you copied from the Security Console.
You will see a verification message if the shared secret has been applied successfully.
9. Enable the console on the engine. Example:
enable console 2

You will see many lines logged as the pairing takes place.
10. Return to the Scan Engines page on the Security Console Web interface. Click Refresh
displayed Engines. Verify that the Scan Engine you just paired has been added. Click the
Refresh icon for that Scan Engine to confirm that the Security Console can query it.

Creating a trusted pairing from a Scan Engine to a Security Console

86

By default, when you have created a trusted pairing with this method, the comunication
direction will be from Engine to Console. To change it, see Changing Scan Engine
communication direction in the Console on page 87.

Changing Scan Engine communication direction in the Console


You can change the direction of communication initiation between the Security Console and each
remote Scan Engine. Which option is preferable depends on your network configuration. If the
direction of communication is from Console to Engine, which is the default setting, the Security
Console will initiate communication with the Scan Engine. If the direction of communication is
from Engine to Console, the Scan Engine will actively notify the console that it is available. This
option allows a Console that is behind a firewall and configured to allow inbound connections to
have a communication channel with the Scan Engine.
Note: The Engine to Console option is not available for the Local Scan Engine or Hosted
Engines.
To change the direction of Scan Engine communication:
1. Go to the Administration page.
2. Select manage next to Engines.

3. In the Communication Status column, toggle the setting so that the arrow points to and from
the intended directions.

Changing Scan Engine communication direction in the Console

87

You can also hover the cursor over the arrow to view the current status of the communication.
The possible options are:
l

Green Active

Orange Unknown
The console and engine could not communicate, but there was no error.
Note: This status sometimes appears when there has been a long time since the last
communication. In this case, hovering over the arrow will cause a ping, and if that
communication is successful the status will become Active.

Red Three options.


l Pending authorization
Authorize communication from the Scan Engine. See the topic Configuring
distributed Scan Engines in the user's guide or Help.
l

Incompatible
The console and engine are on different versions. Update them to the same version,
or choose a different engine to pair.

Down
The Scan Engine is not online. Perform troubleshooting steps to make it active again.

Allocating threads for monitoring scans


The Security Console allocates a thread pool for retrieving scan status information. You can
adjust the number of threads, which corresponds to the number of scan status messages that the

Changing Scan Engine communication direction in the Console

88

Security Console can retrieve simultaneously. For example, if you increase the number of
distributed Scan Engines and the number of scans running simultaneously, you can increase the
threads in the pool so that the Security Console can retrieve more status messages at the same
time.
Note: It is recommended that you consult with Technical Support before tuning these settings.
Keep in mind that retrieval time is subject to network conditions such as bandwidth and latency.
Whenever the number of active threads in use exceeds the overall number of threads in the pool,
the Security Console removes unused scan status threads after specific time interval. If you
notice an overall decrease in the frequency of scan status messages, you may want to consider
increasing the timeout value.
To adjust pool settings for scan status threads, take the following steps:
1. Go to the Scan Enginespage in the Security Console Configuration panel.
2. Click the Administration tab.
3. Click managefor the Security Console on the Administration page.
4. Click Scan Engines in the Security Console Configuration panel.
5. Adjust the Scan Status settings.
6. Edit the value in the Thread idle timeout field to change the number of milliseconds that
elapse before the Security Console removes unused scan threads.
7. Edit the value in the Thread pool size field to change the number of threads in the pool for
monitoring scan status.
8. Click Save in the top bar of the panel to save the changes.
9. Restart the Security Console so that the configuration changes can take effect.
Tip: Because millisecond values can be difficult to read, a time value that is easier to read
appears to the right of each value field. As you change either timeout value, note how the
equivalent value changes.
Retrieving incremental scan results from distributed Scan Engines
The Security Console communicates with Scan Engines over a network to retrieve scan results.
By default, the Security Console retrieves scan results from distributed Scan Engines
incrementally, displaying results in the Web interface as it integrates the data, rather than
retrieving the full set of results after each scan completes. This allows you to view scan results as
they become available while a scan is in progress.

Changing Scan Engine communication direction in the Console

89

Incremental retrieval modulates bandwidth usage throughout the scan. It also makes it
unnecessary for the Security Console to retrieve all the data at the end of the scan, which could
cause a significant, temporary increase in bandwidth usage, especially with large sets of data.
The Scan Engines page of the Security Console Configuration panel displays a check box for
incremental retrieval of scan results. It is selected by default. Do not disable this option unless
directed to do so by Technical Support.

Managing the Security Console database


Viewing Security Console database information
You can view the name and type of the Security Console database on the Database page of the
Security Console configuration panel. You also can change displayed database settings.
To save the changes, click Save.
Migrating the database
The applications database is a core component for all major operations, such as scanning,
reporting, asset and vulnerability management, and user administration. The efficiency with
which it executes these tasks depends heavily on database performance. The current
PostgreSQL database version, 9.4.1, features a number of performance and stability
enhancements. The application takes full advantage of these improvements to scale flexibly with
the needs of your environment. Future releases will include powerful features that will require the
latest PostgreSQL version.
Note: Only administrators can migrate the database.
If your installation is running an earlier version of PostgreSQL, you can easily migrate it to the
latest version, using a tool in the Security Console Web interface.
Migration involves five required tasks:
l

Preparing for migration on page 91

Starting and monitoring the migration on page 93

Verifying the success of the migration on page 95

Backing up the post-migration database on page 96

Restoring a backup of an older platform-dependent PostgreSQL database after migrating to the


new version is not supported. After you perform and verify the migration to the latest version and
ensure database consistency, it is very important that you back up the database immediately to

Managing the Security Console database

90

prevent the need to restore an earlier version of the database. See Backing up the postmigration database on page 96.
This document also provides instructions for optional post-migration tasks:
l

restoring backups

restoring tuned PostgreSQL settings

Preparing for migration


Some preparation will ensure that migration takes the least possible amount of time and is
successful:
l

Make sure port 50432 is open.


Make sure you have sufficient disk space. During the migration, the old database is backed up
and a new one is created, so you need to accommodate both databases. If you are unable to
run the migration because of insufficient disk space, you can take several steps to free up
space. See Freeing up disk space for migration on page 91.
Make sure that you have an authenticated global administrator account, so that you can
monitor the migration in the Security Console Web interface. If your account is authenticated
by an external source, such as LDAP or Kerberos, you will be able to start the migration.
However, when the application restarts in Maintenance Mode, you will not be able to log on to
the Security Console Web interface to monitor the migration. The database stores information
about the external authentication sources, and it wont be operational during the migration. If
you do not monitor the migration, you will not know if any issues have occurred requiring you
to restart it or take some other action. You have several options for monitoring the migration:
When the application restarts in Maintenance Mode, log on with an authenticated global
administrator account instead of an external source. This will allow you to monitor status
messages in the Security Console Web interface. If you do not have an authenticated
account, you can create one or modify an existing account accordingly. See Managing users
and authentication on page 61. You also can log on with the default administrator account that
was created during installation.
If you do not have an authenticated administrator account you can monitor the migration by
reading the nsc.log file, which is located in [installation_directory]/nsc. If you need to restart
the application manually, you can do so from the command prompt using the restart
command.

Freeing up disk space for migration


In most cases the Start Migrationbutton is disabled if you do not have enough disk space to
perform the migration. However, in some environments, the Start Migrationbutton may be
enabled but disk space issues may still occur during migration. For example, see the section

Managing the Security Console database

91

about Linux file systems. To free up disk space, try the solutions listed in the following sequence.
Check if the Start Migrationbutton is enabled after each step.
Note: It is recommended that your free disk space be equal to 1.6 GB + (1.3 x database_size).
Run the following database maintenance tasks, which remove unnecessary data and free up
unused table space:
l

re-indexing the database

cleaning up the database

compressing tables

If you have not run these tasks recently, doing so may free up considerable space. It is
recommended that you run each task individually in the following sequence. After completing
each task, try running the migration again. Re-indexing may provide all the space you need,
making it unnecessary to clean up the database or compress tables, which can take significant
time depending on the size of your database. See Performing database maintenance on page
124.
Move the following directories from the host system, and restore them after the migration is
complete:
l

backup files[installation_directory]/nsc/*.bak and[installation_directory]/nsc/*.zip

reports directory[installation_directory]/nsc/htroot/reports

access log directory, including the Tomcat log subdirectory[installation_directory]/nsc/logs

scan event data files directory[installation_directory]/nse/scans

Security Console logs[installation_directory]/nsc/*.log and /nsc/*.log*

PostgreSQL log[installation_directory]/nsc/nxpsql/nxpgsql.log

scan logs directory[installation_directory]/nse/nse.log and /nse/nse.log.

Note: These directories and files take up increasing amounts of disk space over time as the
application accumulates data.
To create free space for migration:
1. Move from the host system any files or directories extraneous to the application that are not
required by other applications to run. You can restore them after the migration is complete.
2. Delete the contents of the java.io.tmpdir directory on the host system. The location depends
on the operating system.

Managing the Security Console database

92

Note: If the disk space problem occurs after a previous migration attempt failed, see Addressing
a failed migration on page 98.
After taking the preceding steps, try starting the migration again. If you still dont have enough
disk space, contact Technical Support.
Creating free space in Linux
By default, Linux file systems reserve 5 percent of disk space for privileged, or root, processes.
Although this reserved space is not available for database migration, the application includes it in
the pre-migration calculation of total available space. As a result, a migration may be able to start,
but then fail, because the actual amount of free disk space is lower than what was detected in the
calculation. You can lower the amount of reserved disk space to make the amount of actual free
space more consistent with the results of the pre-migration calculation. To do so, use the tune2fs
utility. The command includes parameters for the percentage of reserved disk space and the
partition on which the application is installed.
Example: tune2fs -m 1 /dev/sdf1
Starting and monitoring the migration
To monitor the migrations:
1. Go to the Administration page.
2. Select Migration. This link will only be available if no one in your organization has performed
the migration yet.
3. Review your database migration status on the migration page.
4. Click Start Migrationif it indicates that your installed PostgreSQL version is earlier than 9.0.3
and that your system is ready for migration.
After you click Start Migration, the application goes into Maintenance Mode. Normal operations,
such as scanning and running reports, are unavailable. See Running in maintenance mode on
page 99. If youre an administrator, you can log on to monitor migration status messages.
During migration, the application copies data from the old PostgreSQL database to the new
PostgreSQL database. The migration requires enough disk space for both of these databases.
It also backs up the old PostgreSQL database and stores it in the directory [installation_directory]
/nsc/nxpgsql-backup-[timestamp] after the migration completes.
The estimated migration time is based on the size of the database.

Managing the Security Console database

93

After all migration processes finish, the application restarts, and you can resume normal
operations.
The PostgreSQL database applies its default settings after migration. If you modified
postgresql.confor pg_hba.conf prior to the migration you will need to reapply any custom settings
to those configuration files. See Restoring custom PostgreSQL settings on page 97. You can
refer to the modified configuration files in the old, archived version of PostgreSQL for custom
settings.
If you click the Cancel button to stop the migration before it completes, the application will
discontinue the migration process. You can then restart the application in normal, operational
mode.
If the migration fails, your current version of the PostgreSQL database will remain intact, and you
can continue using the application without interruption. See Addressing a failed migration on
page 98.
In very rare instances the application may display the migration FAQs while in Maintenance Mode
after the migration process has been executed, instead of a status message detailing the results
of the migration. If this occurs, contact Technical Support for assistance before restarting the
server. You should also contact Technical Support if this situation occurred and you inadvertently
restarted your server, or at any time after the migration if you note on the Database Migration
page that the version of PostgreSQL running in your environment is earlier than 9.4.
Addressing migration that takes a long time with no new status messages
Depending on the amount of data, the migration can take from 30 minutes to over an hour.
Therefore, a long migration time is not unusual, and extended periods without new status
messages do not necessarily indicate that the migration is hanging.
You can perform a couple of quick checks to confirm that the migration is still proceeding when no
status messages are visible:
1. Run top in Linux or Task manager in Windows, and check if a PostgreSQL process is running
and using CPU resources.
2. Check migration log files, located in [installation_directory]
/nsc/nxpgsql/pgsqlpgsql/bin/pgrade_*.log, for messages about database tables being copied.
The Security Console will display a notification when the processes have completed.

Managing the Security Console database

94

Verifying the success of the migration


To verify migration success, take the following steps:
1. Go to the Administration page.
2. Click Administer.
3. Go to the Database tab.
4. Read the installed version of PostgreSQL, which is displayed on the page.
If the migration was successful, the installed version will be 9.4.1.
OR
1. Open the nsc.log file, located in [installation_directory]\nsc\logs, to verify that PostgreSQL
9.4.1 is running.
2. Search for the string PostgreSQL. You will find the active PostgreSQL version number with
an instance of that string.
It will appear on a line that looks like the following example:
NSC 2015-06-11T18:45:01 PostgreSQL 9.4.1, compiled by Visual C++ build 1500, 64-bit

Upon confirming that the migration was successful, take the following steps:
1. Move back any files or directories that you moved off the host system to free up disk space for
migration. See Freeing up disk space for migration on page 91.
2. Move the [installation_directory]/nsc/nxpgsql-backup-[timestamp] directory to an external
location for storage.
It contains the pre-migration database, including the postgresql.conf file.
NOTE: Before you resume normal operations, make sure to verify database consistency as
described in the following section.
If you modified postgresql.conf or pg_hba.conf prior to the migration you will need to reapply any
custom settings to those configuration files. See Restoring custom PostgreSQL settings on page
97. You can refer to the modified configuration files in the old, archived version of PostgreSQL for
custom settings.
Ensuring database consistency
This procedure involves two steps. Checking database consistency and cleaning up the
database take little time.

Managing the Security Console database

95

To verify database consistency and respond appropriately:


1. Go to the Administration page.
2. Click Diagnose.
The Security Console displays the Troubleshooting page.
3. Select only the Database Diagnosticscheck box.
4. Click Perform Diagnostics.
A table appears on the page, listing the results of all diagnostic tests. Red circles containing
the letter Xindicate consistency issues.
5. Go to the Administration page.
6. Click Maintenance.
The Security Console displays the Database Maintenance page.
7. (Optional) Select the Clean up Databasetask to remove any unnecessary data.
8. Click Start Database Maintenance.
Note: All diagnostics options are selected by default, but only database diagnostics are
necessary for verifying database consistency after migration. To see only the information you
need for this task, clear any other selected check boxes.
Once you start these operations, the application shuts down and restarts in Maintenance Mode.
Any in-progress scans or reports will stop before completion and any related data will be lost. You
will have to rerun any reports or scans after it completes maintenance operations and restarts in
Normal Mode. For more information, see Running in maintenance mode on page 99.
Backing up the post-migration database
It is very important that you back up the database immediately after you verify the success of the
migration and ensure database consistency. This preserves a baseline instance of the postmigration database and prevents the need to restore a backup of a PostgreSQL 9.0 database.
Perform this step only after you have completed the preceding steps:
l

migrating the database

verifying the success of the migration

ensuring database consistency

Managing the Security Console database

96

For instructions on backing up the database, see Database backup/restore and data retention on
page 116.
Restoring a database that was backed up as part of a migration
After migration, the application backs up the PostgreSQL 9.0 database and stores it in the
directory [installation_directory]/nsc/nxpgsql-backup-[timestamp].
If you want to restore this particular database, take the following steps:
1. Shut down the application.
2. Rename the pgsql directory of the post-migration database.
It is located in [installation_directory]/nsc/nxpgsql.
3. Copy the backup directory, named nxpgsql-backup-[timestamp], into the [installation_
directory]/nsc directory, and rename it nxpgsql.
4. Start the application and resume operations.
Tip: Move the backup directory with all original permissions attributes preserved. Doing so
prevents the requirement on Linux that nxpgsql be the owner of the directory, as well as the
necessity on Windows to give the system user access to the directory.
If you are planning to restore the database that was backed up during the migration, keep several
things in mind:
If you run scans or reports after the migration and then restore the backup database, the Security
Console Web interface will not list scan or report instances from the period between the migration
and the restoration because the restored database does not contain those records.
When you start to run scans or reports after the restoration, the associated scan or report
instances that are being populated in the restored database will overwrite the instances that were
generated in the file system prior to the restoration.
Graphic charts will initially be out of synch with the restored database because they always reflect
the latest site, scan, or asset group information. Each chart will refresh and synchronize with the
restored database after an event associated with it. For example, running a scan will refresh and
synchronize the charts for any associated sites or asset groups.
Restoring custom PostgreSQL settings
The PostgreSQL database applies its default settings after migration. If you previously modified
the postgresql.conf file to tune database performance or the pg_hba.conf to enable remote
connections to the database, you will need to reapply those modified settings.

Managing the Security Console database

97

After the migration is complete, you can refer to the configuration files in the old, archived version
of PostgreSQL, which is stored in the directory [instsallation_directory]/nsc/nxpgsql-backup[timestamp].
Warning: Do not simply copy the old configuration files into the new database location. This may
prevent the database from starting due to compatibility issues. For each file, compare each
setting one by one, and edit only the properties that you modified in the previous PostgreSQL
installation.
Addressing a failed migration
If the migration fails, your current version of the PostgreSQL database will remain intact. Simply
restart the application and resume normal operations.
Before you run the migration again, find out if the failure occurred due to disk space errors. In
certain cases, migration may exceed available disk space before finishing, even if the automatic
pre-migration check determined that sufficient disk space was available.
To troubleshoot a failed migration:
l

Check your available space for the disk that the application is installed on.
(Optional) In Windows, right-click the icon for the disk and then click Properties from the popup menu. Read the amount of available disk space.
(Optional) In Linux, run the command to show disk space: df-h in the [installation_directory]
/nsc directory. Read the amount of available disk space.
If the available disk space is less than the database size, free up disk space, and run the
migration again. See Freeing up disk space for migration on page 91.
If your free disk space is equal to at least 1.6 GB + (1.3 x database_size), this suggests that
the migration did not fail due to disk space issues but for a different reason. Contact Technical
Support for assistance in completing the migration.

Note: If you do not wish to retry migration after failure, you should still delete the /nxpgsql-temp
directory, because it uses up considerable disk space.
If the migration fails due to a system failure or power outage and you attempt to run the migration
again, you may encounter a disk space limitation issue. This is because during the failed
migration attempt, the application created an nxpgsql-temp directory. Simply delete this directory
and start the migration again. The temp directory is located in [installation_directory]/nsc.

Managing the Security Console database

98

Running in maintenance mode

Note: Only global administrators are permitted to run the application in maintenance mode.
Maintenance mode is a startup mode in which the application performs general maintenance
tasks and recovers from critical failures of one or more of its subsystems. During maintenance
mode, you cannot run scans or reports. Available functions include logging, the database, and
the Security Console Web interface.
Note: The application automatically runs in maintenance mode when a critical internal error
occurs.
When the application is running in maintenance mode, you see the page
/admin/maintenance/index.htmlupon logging on. This page shows all available maintenance
tasks and indicates the current status of the task that is being performed. You cannot select a
new task until the current task is completed. Afterward, you can switch tasks or click Restart to
return to normal operating mode.
To work in Maintenance mode:
1. Click the Administration tab.
2. On the Administrationpage, click Maintenance.
The Security Console displays the Maintenance Mode page.

Running in maintenance mode

99

Enabling dashboards
As a Nexpose Global Administrator, you have the ability to enable dashboard functionality for
your organization. Dashboards are personalized views into your environment that allow users to
explore all of your vulnerability management data in one place and can be customized to focus on
the information each user cares about. Once the dashboard functionality is enabled, users can
access it automatically from their Nexpose consoles: their Nexpose credentials will serve as a
single sign-on. To learn more, see Overview of dashboards in the Nexpose User's Guide.
Dashboards are powered by the Rapid7 Insight platform. This means that when you enable
dashboards, your organization's data will be synchronized to an AWS cloud instance. Rapid7
takes your security and privacy seriously, and has put measures into place to protect your data
security. For more information, see https://www.rapid7.com/trust/. When enabling dashboards,
you will be asked to confirm that you are agreeing to synchronize your organization's data to the
cloud.
Your vulnerability and asset data will be synced to the Rapid7 Insight Platform after you activate
Exposure Analytics. During the initial syncing, the historical data from the past six months is
uploaded to the platform. The uploaded data, which includes your assets, vulnerabilities, and
sites, is used to by your dashboards to analyze and monitor trends in your environment. After the
initial syncing, your security data will be automatically uploaded to the platform as soon as it is
collected and assessed in your Nexpose Security Console.
In order to successfully upload data to the platform, your Nexpose Security Console must be able
to ping the following URLs:
l

data.insight.rapid7.com

s3.amazonaws.com

s3-external-1.amazonaws.com

exposure-analytics.insight.rapid7.com

To enable access to Nexpose dashboards, several conditions must be in place:


l

Your Nexpose instance must be licensed with an Enterprise or Ultimate license.


To learn more about this feature and activation, please visit http://www.rapid7.com/nexposenow.

If the above conditions are met, and you are a Global Administrator, you will have the option to
enable dashboard functionality. To do so:

Enabling dashboards

100

1. In the Nexpose console, select the dashboard icon

from the left navigation menu.

2. A welcome screen appears.

3. Click Next.
4. The Exposure Analytics opt-in screen appears. This is where you confirm that you are ready
to sync your organization's data to the cloud.

Enabling dashboards

101

5. To opt in, select Yes, I am ready.


Note: If you select Maybe later, the next step will exit you from the dialog. See Enabling or
disabling dashboards from the Administration page on page 104 for how to enable the
feature later when you are ready.
6. Click Next.
7. The Console name screen appears.

Enabling dashboards

102

8. Specify a name to make it clear to users of the dashboard that the data they are seeing comes
from this console.
9. Click Next.
10. The Cloud Region screen appears.

Enabling dashboards

103

11. Select the AWS region where your data will be stored.
12. Click Next.
13. The main screen of the dashboards appears. For more information, see Viewing and Working
with Dashboards in the Nexpose User's Guide .

Enabling or disabling dashboards from the Administration page


Another way to enable dashboards, or to disable them, is from the Administration page. This is
how you can enable dashboards if you initially opted out in the process described above.
Disabling dashboards
To have access to this section, the following conditions must apply:
l

Your Nexpose instance must be licensed with an Enterprise or Ultimate license.

You must be a Global Administrator for your Nexpose installation.

To learn more about this feature and activation, please visit http://www.rapid7.com/nexposenow.

To enable dashboards from the Administration page:

Enabling or disabling dashboards from the Administration page

104

1. On the Administration page, select Administer next to Console.

2. Select Exposure Analytics from the left menu.


3. Select Use Exposure Analytics.

Enabling or disabling dashboards from the Administration page

105

4. Click Save.

5. Select the dashboard icon

from the Nexpose left navigation menu.

6. Proceed according to the instructions above.


To disable dashboards from the Administration page:
1. On the Administration page, select Administer next to Console.

2. Select Exposure Analytics from the left menu.


3. Select Do not use Exposure Analytics.

Enabling or disabling dashboards from the Administration page

106

4. A message appears indicating that all data will be removed from the cloud. Select Disable
Exposure Analytics.

5. Click Save.
If you have disabled dashboards, you will still be able to enable them again at a later date as long
as the required conditions are still met. Similarly, the option to disable them will remain available
once they are enabled.

Enabling or disabling dashboards from the Administration page

107

Setting Up a Sonar Query


Project Sonar is an initiative by the Rapid7 Labs team to improve security through the active
analysis of public networks. It performs non-invasive scans of public IPv4 addresses for common
services, extracts information from the services, and makes the data available to everyone.
By analyzing Project Sonar data, you can:
l

View your environment from an outsider's perspective.

Find assets that belong to your organization that you may not have been tracking.

Get a snapshot of your public facing assets.

Obtain a better understanding of your exposure surface area.

Project Sonar data can be added to a site and treated like any other data. Please just remember
that Project Sonar data is not a definitive or comprehensive view; it's just a starting point you can
use to learn more about your public Internet presence.

Connecting to Project Sonar


Project Sonar is available to Nexpose Enterprise license key holders. If you have the proper
licensing, your console will automatically connect to Project Sonar if it can reach the server at
https://sonar.labs.rapid7.com via port 443. Your console must also have Dynamic Discovery
enabled.

Setting Up a Sonar Query

108

To check the status of your connection to Project Sonar:


1. Select Administration from the left navigation menu.

2. Under the Discovery Options, click the manage link for Connections.

3. On the Discovery Connections page, check the status for Sonar. It should beConnected.

Setting up a Sonar query


As a Nexpose Administrator, you can set up queries that pull data from Sonar and add them to
the console. These queries can also be used to set boundaries on the domains that Site
Administrators have permissions to scan. In addition to the query, you can add filters to further
refine the results that are added to the Nexpose Console. All results from Sonar are added to the
Discovered byConnection table on the Assets page.

Setting up a Sonar query

109

To set up a Sonar query:

Setting up a Sonar query

110

1. Select Administration from the left navigation menu.

2. Under the Discovery Options, click the manage link for Connections.

3. Click on the Sonar connection.

4. On the Sonar Queries page, click the New Sonar Query button.

Setting up a Sonar query

111

5. Enter a name for the query.

6. Add a filter for the domain you want to query. It can be a top level domain, such as
'rapid7.com', or a subdomain, such as 'community.rapid7.com'.

You can also add a scan date filter if you want to control the staleness of your asset data. The
shorter the range, the less likely the data will be stale.
7. Test the query by running it. It may take awhile to complete and will display any results in the
table.
8. Save the query when you are done.

Filtering data fromProject Sonar


A filter is a rule that you can use to refine the results from a Sonar query. You create them when
you want to specify requirements for the assets you add to your console. A filter comprises of a
filter type, search operator, and filter value.
Filter types
You can create filters based on:
l

A domain name, such as 'rapid7.com' or 'community.rapid7.com'

A scan date, such as 'within the last 30 days'

Search operators
A filter uses an operator to match assets to the value you have provided. You can use the
following operators to build a filter:

Filtering data fromProject Sonar

112

Contains Filters based on a partial match. For example, the filter 'domain name contains
rapid7.com' returns all assets that contain 'rapid7.com' in the domain.
Within the last Filters base on a time frame. This operator is only used with scan date filters
and only accepts an integer. For example, the filter 'Sonar scan date within the last 7 days'
returns assets that Sonar has scanned in the past week.

Setting the scan date for Sonar queries


You can create a scan date filter to control the staleness of your asset data. Stale data occurs
when the asset has been scanned by Sonar, but the asset has changed IP addresses since the
scan was performed. Typically, the longer it has been since Project Sonar has scanned an asset,
the more likely it is that the data is stale.
To reduce the possibility of adding stale data to your site, you should create a scan date filter. A
more recent scan date range, like 7 days, can help ensure that you don't accidentally add assets
that do not belong to you. If you apply a scan date filter and do not see any results from Sonar,
you may need to extend the range the filter is using.

Clearing the Sonar Cache


Clearing your Sonar cache will clear all Sonar assets from the Discovered byConnection table
on the Assets page. You may want to clear your Sonar cache after you have deleted a Sonar
query or you want to force a refresh on existing Sonar queries.

Setting the scan date for Sonar queries

113

To clear the Sonar cache:


1. Select Administration from the left navigation menu.

2. Under the Discovery Options, click the manage link for Connections.

3. Click on the Sonar connection.

4. Click the Clear All Sonar Assets button.

When you go to the Discovered byConnection table on the Assets page, you will not see any
Sonar assets listed. Any existing Sonar queries that you still have set up will continue to return
asset data, which will be added to the table the next time the query runs.

Clearing the Sonar Cache

114

Deleting a Sonar query


Deleting a Sonar query removes it from the connection. It does not delete the connection itself.
The connection will continue to persist, but will not add any data to your console. The data that
has already been added to the console will be retained.
To delete a Sonar query:
1. Select Administration from the left navigation menu.

2. Under the Discovery Options, click the manage link for Connections.

3. Click on the Sonar connection.

4. Click the Delete button next to the query you want to remove.
The query is deleted from the connection.

Deleting a Sonar query

115

Database backup/restore and data retention


Running regularly scheduled backup and restore routines ensures full recovery of the Security
Console in the event of hardware failure. The application performs actual backup and restore
procedures in maintenance mode. It cannot run these procedures while scans are in progress.
See Running in maintenance mode on page 99. However, you set up backup and restore
operations while the application is in normal mode.

Important notes on backup and restore


There are four possible options on the backup/restore page:
l

Backup data onto the applications file system.

Restore an installation from a prior backup already on the applications file system.

Copy an existing backup to external media using Browse.

Note: You should copy backup data to external storage media to prevent loss in the event of a
hardware failure.
l

Restore an installation from a prior backup on external storage.

What is saved and restored


A backup will save the following items:
l

database

configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)

licenses

keystores

report images

custom report templates

custom scan templates

generated reports

custom risk strategies

custom SCAP data

scan logs

Database backup/restore and data retention

116

Performing a backup
To perform a backup, take the following steps:
1. Go to the MaintenanceBackup/Restorepage, which you can access from the
Maintenancelink on the Administration page.

TheBackup/Restore page

2. In the area titled Create Backup, enter a short description of the new backup for your own
reference.
Note: Enabling the platform-independent option significantly increases backup time.
3. If you want to do a platform-independent backup, select the appropriately labeled check box.
This option is useful for restoring on a different host than that of the backup. It allows you to
restore backup files on any host with any supported operating system. This option also
reduces the size of the backup files.
4. Click Start backup.
The Security Console restarts in Maintenance Mode and runs the backup. In Maintenance
Mode, normal operations, such as scanning, are not available. If youre a Global
Administrator, you can log on to monitor the backup process. You will see a page that lists
each backup activity.

Performing a backup

117

The Security Console automatically restarts when the backup completes successfully.
Note: If the backup is unsuccessful for any reason or if the Security Console does not restart
automatically, contact Technical Support.
After you complete a backup and the Security Console restarts, the backup appears in a table on
the MaintenanceBackup/Restorepage, under the heading Restore Local Backup. If you want
to restore the backup on a different host or store the backup in a remote location, download the
backup by clicking the link in the Download column.

Scheduling a Backup
You can set up schedules to automatically back up data in your Security Console on a regular
basis.
To schedule a backup:

Scheduling a Backup

118

1. Select Administration from the left navigation menu.

2. Under the Maintenance, Storage and Troubleshooting options, click the maintenance link.

3. When the Maintenance page appears, select the Schedules tab.

4. Click Create Backup Schedule.

Scheduling a Backup

119

5. When the Create Backup Schedule window appears, verify the Enabled option is selected.

6. Enter the following information:


7. Start Date The date you want the schedule to begin.
8. Start Time The time you want the schedule to run at.
9. Cancel Backup The amount of time you want to wait for a backup to start before
canceling it. You can enter 0 if you do not want to cancel the backup; the backup will wait
until all local scans are complete or paused to run.
10. Frequency The frequency you want to backup your console, such as daily, weekly, or
monthly
7. Save the schedule.
Disabling a Backup Schedule
To pause or disable a backup schedule:

Scheduling a Backup

120

1. Select Administration from the left navigation menu.

2. Under the Maintenance, Storage and Troubleshooting options, click the maintenance link.

3. When the Maintenance page appears, select the Schedules tab.

4. When the Schedules page appears, find the backup schedule you want to disable and
deselect the Enabled option.

Scheduling a Backup

121

Restoring a backup
The restore procedure reverts the application to its exact state immediately preceding the
backup.
If a hardware failure has rendered the application unusable, you will need to reinstall it.
To restore a backup, take the following steps:
1. Go to the MaintenanceBackup/Restorepage, which you can access from the
Maintenancelink on the Administration page.
2. If you are restoring a backup that was stored locally on the Security Console host, go to the
table in the area titled Restore Local Backup. Locate the desired backup, and click the
Restore icon.
OR
If you are restoring a backup from a different host, make sure the backup has been
transferred to the local Security Console host. Then, click Choose Filein the area titled
Restore Remote Backup File. Locate and select the backup. Then, click Start upload and
restore.

Options for restoring a backup

3. The Security Console restarts in Maintenance Mode and runs the restore procedure.
In Maintenance Mode, normal operations, such as scanning, are not available. If you are a
Global Administrator, you can log on to monitor the backup process. You will see a page that
lists each backup activity.
The Security Console automatically restarts when the restore procedure completes
successfully.

Restoring a backup

122

Note: If the backup is unsuccessful for any reason or if the Security Console does not restart
automatically, contact Technical Support.

Migrating a backup to a new host


If you are ever required to change the host system for the application, you will have to migrate
your backup to the new host. For example, your organization may perform a hardware upgrade.
Or the original host system may have failed and is no longer in service. Migrating a backup to a
host system other than the one on which the backup occurred is simple and requires a few extra
steps:
1. Recommended:Apply the latest updates to the old host. See Managing versions, updates
and licenses on page 127.
This step ensures that when you install the application on the new host in step 5, the
database structure will be current with that of the latest installer, preventing any compatibility
issues that otherwise might occur.
2. Do a platform-independent backup, which ensures better integrity for the files when they are
restored. See Performing a backup on page 117.
3. Go to the backups directory on the host system:
[installation_directory]/nsc/backups. Copy all desired backups, including the one you just
completed, to external media. Your organizations policies may be required you to keep a
certain number of backups, such as for PCI audits.
Tip: Do not delete the backup host installation unless it is absolutely necessary. It may be useful
for troubleshooting in case you encounter issues running the restored files on the new host.
4. Shut down the application on the original host. This is an important step because the
application by default checks for updates every six hours. If the update server detects more
than one installation with the same serial number, it will block updates.
5. Install the application on the new host. For instructions, see the installation guide, which you
can download from the Support page in Help.
6. Apply any available updates to the installation on the new host.
This step ensures that installation includes any new updates that may have occurred since
the backup.
7. Manually create the backups directory on the new host:
[installation_directory/nsc/backups.

Migrating a backup to a new host

123

Note: For this migration process, it is unnecessary to request a product key during installation on
the new host. It is also unnecessary to activate the license after you finish the installation and log
on to the Web interface.
8. Transfer the backup files from the external media to the newly created backup directory.
9. In the application, refresh the Administration page in the Web browser.
10. Restore the backup(s). See Restoring a backup on page 122.
The application restarts in Maintenance Mode. Normal operations, such as scanning,
are not available. If you are a Global Administrator, you can log on to monitor the
backup process. You will see a page that lists each backup activity.
The Security Console automatically restarts when the backup completes successfully.
Note: If the backup is unsuccessful for any reason or if the Security Console does not
restart automatically, contact Technical Support.
11. Verify that all your restored content is available, such as sites and templates.
12. IMPORTANT: Contact Technical Support to reset the update history for your license. Since
you are transferring your license to a new host, resetting the history will cause the server to reapply all updates on the new host. This ensures that the update version of the migrated
application matches that of the backup on the old host.

Performing database maintenance


You can initiate several maintenance operations to maximize database performance and drive
space.
Database maintenance operations can take from a few minutes to a few hours, depending on
the size of the database. Once you start these operations, the application shuts down and
restarts in Maintenance Mode. Any in-progress scans or reports will stop before completion and
any related data will be lost. You will have to rerun any reports or scans after the application
completes maintenance operations and restarts in Normal Mode. For more information, see
Running in maintenance mode on page 99.
To perform database maintenance:
1. Go to the Administration page.
2. Click Maintenance.
3. Go to the Database Maintenance page and select any of the following options:

Performing database maintenance

124

Clean up Databaseremoves leftover data that is associated with deleted objects such as
sites, assets, or users.
Compress Database tables frees up unused table space.
Reindex Databaserebuilds indexes that may have become fragmented or corrupted over
time.

4. Click Start Database Maintenance.


The Security Console automatically restarts when the maintenance completes successfully.

Setting data retention preferences


The Security Consoles default policy is to retain all scan and report data. To optimize
performance and disk space, you can change the policy to retain only some of this data and
remove the rest.
To enact a partial data retention policy:
1. Go to the Administration page.
2. Click Maintenance on the Maintenance, Storage and Troubleshooting panel.
3. Click Data Retention.
4. Select the Retain only data within a specific time frame option.
5. Select the time frame of scan and/or report data to retain.
6. Click Save to enact the policy.
After you enact the policy, the Security Console runs a routine nightly which removes data
not included in the retention time frame. The routine begins at 12 a.m. and will not interrupt
your normal Security Console operations. If the routine is interrupted, it resumes where it left
off on the following evening. The duration of the routine depends on the amount of data
being removed.
Note: You cannot stop the routine once it starts, and all data removal is permanent.

Setting data retention preferences

125

Setting a data retention policy

Setting data retention preferences

126

Managing versions, updates and licenses


This section addresses how to keep the application updated.

Viewing version and update information


It is important to keep track of updates and to know which version of the application you are
running. For example, a new vulnerability check may require the latest product update in order to
work. If you are not seeing expected results for that check, you may want to verify that the
application has installed the latest product update. Also, if you contact Technical Support with an
issue, the support engineer may ask you which version and update of the application you are
running.
1. Click the Administration tab of the Security Console interface.
The Security Console displays the Administration page.

Administration tab

2. Click Managesettings for the Security Console, including auto-update and logging settings.
The Security Console displays the General page of the Security Console Configuration
panel.

Managing versions, updates and licenses

127

On this page you can view the current version of the application. You can also view the dates
and update IDs for the current product and content updates. Release announcements
always include update IDs, so you can match the IDs displayed on the Security Console
page with those in the announcement to verify that you are running the latest updates.

The Generalpage of the Security Console Configuration panel

Viewing, activating, renewing, or changing your license


On the Licensing page, you can see license-related information about your Security Console.
You also can activate a new license or start the process to modify or renew your license. Your
Security Console must be connected to the Internet to activate your license.
Note: If your Security Console is not connected to the Internet see Managing updates without
an Internet connection on page 139.
The License Activationarea displays general information about your license.
l

If your license is active, you will see a link for contacting Rapid7to modify your license, which
is optional.
If your license is expired, you will see a link for contacting Rapid7 to renew your license. You
will need an active license in order to run scans and create reports.

Viewing, activating, renewing, or changing your license

128

The Licensingpage with the activation button

Activating your license with a product key


If your Security Console has Internet access, you can activate your license with a product key.
Provided to you by the Account Management team, the key is a string of 16 numbers and letters
separated into four groups by hyphens.
1. On the Licensing page, click Activate a New License.
The Security Console displays a text box.
2. Enter the key in the text box.
You can copy the key from the e-mail that was sent to you from the Account Management
team.
3. Click Activate with key.
The Security Console displays a success message.
You do not have to click Save. The application does not have to restart.
See Troubleshooting your activation in Help if you receive errors during activation.

Viewing, activating, renewing, or changing your license

129

Entering a product key for activation

Activating your license with a license file


Watch a video about this feature.
If your Security Console does not have access to the Internet or to the updates.rapid7.com
server, you can activate your license with a license file. Provided to you by the Account
Management team, this file has a .lic extension and lists all the features and scanning capacities
that are available with your license.
To activate with a license file:
1. After you receive the license file from the Account Management team, download it.
2. Using the computer that you downloaded the file on, log onto the Security Console.
3. Click the Administration tab.
The Security Console displays the Administration page.
4. Click the Manage link for Security Console.
The Security Console displays the Security Console Configuration panel.
5. Click Licensing in the left navigation pane.
The Security Console displays the Licensing page.
6. Click Activate a New License.
7. Click the link labeled Use a license file.
A button appears for choosing a file.

Viewing, activating, renewing, or changing your license

130

8. Click the Choose file button.


9. Find the downloaded .lic file in your file system and select it.
The file name appears on the Licensing page.
10. Click the Activate with file button.
The Security Console displays a success message.
11. Click the OK button.
The Licensing page refreshes and displays the updated license information in the License
Details area.
You do not have to click Save, and the Security Console does not have to restart.

Uploading a license file for activation

Viewing, activating, renewing, or changing your license

131

Viewing license details


In the License Details area of the Licensing page, you can see more information about your
license:
l

The value for License Statusis one of four different modes, depending on the status of your
license.
The value for Expiration is the date that your current license expires.
The value for Max. Scan Enginesis the total number of internal Scan Engines that you can
use. These Scan Engines can be installed on any host computers on your network.
The value for Max. Assets to Scanis the total number of assets that you can scan with your
internal Scan Engines.
The value for Max. Assets to Scan w/ Hosted Engineis the total number of assets that you can
scan with a Hosted Scan Engine.
If the value for SCADA Scanningis Enabled, you can scan assets with the SCADA scan
template. For a description of this template, see Where to find SCAP update information and
OVAL files on page 165.
If the value for Discovery Scanningis Enabled, you can run discovery scans to determine
what assets are available on your network without performing vulnerability checks on those
assets.
If the value for PCI Reportingis Enabled, you can create reports using the PCI Executive
Overview and PCI Audit report templates. If this feature is disabled, it will still appear to be
available in your scan template, but it will not be active during scans.
If the value for Web Application Scanningis Enabled, you can scan Web applications with the
spider. If this feature is disabled, it will still appear to be available in your scan template, but it
will not be active during scans.
If the value for Policy Scanningis Enabled, you can scan assets to verify compliance with
configuration policies. If this feature is disabled, it will still appear to be available in your scan
template, but it will not be active during scans.

Managing updates with an Internet connection


By default, the Security Console automatically downloads and applies two types of updates.
Content updates
Content updates include new checks for vulnerabilities, patch verification, and security policy
compliance. Content updates always occur automatically when they are available.

Managing updates with an Internet connection

132

Product updates
Product updates include performance improvements, bug fixes, and new product features.
Unlike content updates, it is possible to disable automatic product updates and update the
product manually.

The Security Console Updates page

Disabling automatic product updates


You can disable automatic product updates and initiate one-time product updates on an asneeded basis. This gives your organization the time and flexibility to train staff or otherwise
prepare for updates that might cause changes in workflow. For example, a new feature may
streamline a particular workflow by eliminating certain steps.
Note: Some new vulnerability and policy checks, which are included in content updates, require
concurrent product updates in order to work properly.
To disable automatic product updates:
1. Click the Administration tab.
2. Click managenext to Security Console.

Managing updates with an Internet connection

133

The Security Console Configuration panel appears.


3. Select Updates from the menu on the left-hand side.
4. Clear the checkbox labeled Enable automatic product updates.
A warning dialog box appears about the risks of disabling automatic product updates.
Click Disable automatic product updatesto confirm that you want to turn off this feature.
Or click Cancel to leave automatic product updates enabled.
5. Click Save.
Whenever you change this setting and click Save, the application downloads any available
product updates. If you have disabled the setting, it does not apply any downloaded product
updates.
Enabling automatic product updates
Note: Your PostgreSQL database must be version 9. Otherwise, the application will not apply
product updates. If you are using an earlier version of PostgreSQL, see Migrating the database
on page 90.
Enabling automatic product updates ensures that you are always running the most current
version of the application.
To enable automatic product updates after they have been previously disabled:
1. Go to the Administration tab.
2. Click manage next to Security Console.
The Security Console Configuration panel appears.
3. Select Updates from the left navigation pane.
4. Select the Enable automatic product updatescheck box.
5. Click Save.
Whenever you change this setting and click Save, the application downloads any available
product updates. If you have enabled the setting, it also applies any downloaded product
updates and restarts.
Manual product updates
When automatic product updates have been disabled, you can manually download product
updates.

Managing updates with an Internet connection

134

Note: By using this one-time update feature, you are not enabling future automatic product
updates if they are not currently enabled.
To manually download a new product update:
1. Go to the Administrationpage.
2. Click manage next to Security Console.
The Security Console Configuration screen appears.
3. Select Updatesfrom the left navigation pane.
Current available updates appear on the Updatespage.
4. Click Manual Updateto install them.
A warning dialog box appears, indicating that the time to update will vary depending on the
number and complexity of updates, and that future automatic product updates will remain
disabled.
5. Click Complete this one-time update to perform the update.
6. (Optional) Click Cancel if you do not want to perform the update.
Scheduling automatic updates
By default the Security Console queries the update server for updates every six hours. If an
update is available, the console downloads and applies the update and then restarts. You can
schedule updates to recur at specfic times that are convenient for your business operations. For
example, you may want updates to only occur during non-business hours or at times when they
won't coincide with and disrupt scans.
Note: Content updates are always applied according to the schedule, and product updates are
applied according to the schedule only if they are enabled.
To schedule updates:
1. Go to the Administrationpage.
2. Click manage next to Security Console.
The Security Console Configuration screen appears.
3. Select Updatesfrom the left navigation pane.
The Updatespage appears.

Managing updates with an Internet connection

135

4. If you want to prevent the Security Console from applying any available updates whenever it
starts up, clear the appropriate checkbox. Disabling this default setting allows you to resume
normal operations after an unscheduled restart instead of delaying these operations until any
updates are applied.
5. Select a date and time to start your update schedule.
6. Select how frequently you want the Security Console to apply any available updates once the
schedule is in effect.
7. Click Save.

Configuring proxy settings for updates


If the Security Console does not have direct Internet access, you can use a proxy server for
downloading updates. In most cases, Technical Support will advise if you need to change this
setting. This topic covers configuring proxy settings for updates. You can also learn how about
Using a proxy server for sending logs on page 151.
Note: For information on configuring updates for an Appliance, see the Appliance Guide which
you can download from the Support page of Help.
To configure proxy settings for updates:
1. Click the Administration tab.
The Administration page appears.
2. On the Administration page, click the Manage link for Security Console.
The Security Console Configuration panel appears.

Configuring proxy settings for updates

136

3. Go to the Proxy Settings page.


4. Enter the information for the proxy server in the appropriate fields:
l The Name or addressfield is set to updates.rapid.7.comby default, which means that
the Security Console is configured to contact the update server directly. If you want to
use a proxy, enter the name or IP address of the proxy server.
l

The Portfield is set to 80by default because the Security Console contacts the update
server on that port. If you want to use a proxy, and if it uses a different port number for
communication with the Security Console, enter that port number.
The Response timeoutfield sets the interval that the Security Console will wait to
receive a requested package before initiating a timeout of the transfer. The default
setting is 30,000 ms, or 30 seconds. The minimum setting is 1,000 ms, and the
maximum is 2,147,483,647 ms. A proxy server may not relay an entire requested
package to the Security Console until it downloads and analyzes the package in its
entirety. Larger packages require more time. To determine how long to allow for a
response interval, see the following topic: Determining a response timeout interval for
the proxy.
The Security Console uses the information in the Domain, User name, and Password
fields to be authenticated on a proxy server. If you want to use a proxy server, enter
required values for those fields.

After you enter the information, click Save.

Configuring proxy settings for updates

137

Security Console Configuration panel - Proxy Settings page

Determining a response timeout interval for the proxy


To determine a timeout interval for the proxy server, find out how much time the Security Console
requires to download a certain number of megabytes. You can, for example, locate the
downloaded .JAR archive for a recent update and learn from the log file how long it took for the
Security Console to download a file of that size.
Open the nsc.log file, located in the [installation_directory]/nsc directory. Look for a sequence of
lines that reference the download of an update, such as the following:
2013-06-05T00:04:10 [INFO] [Thread: Security Console] Downloading update ID
1602503.
2013-06-05T00:04:12 [INFO] [Thread: Security Console] Response via 1.1
proxy.example.com.
2013-06-05T00:05:05 [INFO] [Thread: Security Console] Response via 1.1
proxy.example.com.

Configuring proxy settings for updates

138

2013-06-05T00:05:07 [INFO] [Thread: Security Console] Acknowledging receipt


of update ID 1602503.

Note the time elapsed between the first entry (Downloading update ID...) and the last entry
(Acknowledging receipt of update...).
Then go to the directory on the Security Console host where the .JAR archives for updates are
stored: [installation_directory]/updates/packages. Locate the file with the update ID referenced in
the log entries and note its size. Using the time required for the download and the size of the file,
you can estimate the timeout interval required for downloading future updates. It is helpful to use
a larger update file for the estimate.
Tip: In most cases, a timeout interval of 5 minutes (300,000 ms) is generally sufficient for most
update file sizes.

Managing updates without an Internet connection


Watch a video about this feature.
If your network environment is isolated from the Internet, you can apply an update by running the
installer that is released with that update. When you start the installer, it automatically scans your
current installation for files to repair or update and then applies those changes.
An "update" installation leaves your database and configuration settings in tact. The only changes
it makes to your deployment are the updates.
Note: You will require one computer to have Internet access, so that you can download the
installer.
The first step is downloading the latest installer that is appropriate for your operating system.
Hyperlinks for downloading installers are available in the Nexpose Community at Security Street
(community.rapid7.com). In Security Street, click Nexpose, and select Documents from the
drop-down list. Then click Installation in the left navigation pane to view all related
documentation. Select Nexpose installers, md5sum files, and Virtual Appliances for the latest
files.
You can also use the following hyperlinks:
l

Linux 64 installer

Windows 64 installer

Managing updates without an Internet connection

139

After you download the appropriate installer, take the following steps:
1. If the Nexpose service is running, stop it to allow the installer to apply updates or repairs. See
the topic Running the application in Help for directions on stopping the service.
2. Run the installer. For detailed directions, see the installation guide, which you can download
from the Support page in Help.
The installer displays a message that it will update the current installation, repairing any files
as necessary.
3. Click OK to continue with the updates and installation.
Upon completing the installation, the installer displays a success message.
4. Click Finish to exit the installer.
5. Restart the Nexpose service and log onto the Security Console.
The Security Console displays a page that summarizes the update. Many releases include
two updates: content and product. You can click the News link to see if another update has
been applied for the release date.

Managing updates without an Internet connection

140

Enabling FIPS mode


If you are operating the application in an environment where the use of FIPS-enabled products is
mandatory, or if you want the security of using a FIPS-certified encryption module, you should
enable FIPS mode. The application supports the use of Federal Information Processing
Standard (FIPS) 140-2 encryption, which is required by government agencies and companies
that have adopted FIPS guidelines.
What is FIPS?
The FIPS publications are a set of standards for best practices in computer security products.
FIPS certification is applicable to any part of a product that employs cryptography. A FIPScertified product has been reviewed by a lab and shown to comply with FIPS 140-2 (Standard for
Security Requirements for Cryptographic Modules), and to support at least one FIPS-certified
algorithm.
Government agencies in several countries and some private companies are required to use
FIPS-certified products.
What is FIPS mode?
FIPS mode is a configuration that uses FIPS-approved algorithms only. When the application is
configured to operate in FIPS mode, it implements a FIPS-certified cryptographic library to
encrypt communication between the Security Console and Scan Engines, and between the
Security Console and the user for both the browser and API interfaces.
FIPS mode considerations
It is important to note that due to encryption key generation considerations, the decision to run in
FIPS mode or non-FIPS mode is irrevocable. The application must be configured to run in FIPS
mode immediately after installation and before it is started for the first time, or else left to run in the
default non-FIPS mode. Once the application has started with the chosen configuration, you will
need to reinstall it to change between modes.
Activating FIPS mode
When Nexpose is installed, it is configured to run in non-FIPS mode by default. The application
must be configured to run in FIPS mode before being started for the first time. See Activating
FIPS mode in Linux on page 142.
When FIPS mode is enabled, communication between the application and non-FIPS enabled
applications such as Web browsers or API clients cannot be guaranteed to function correctly.

Enabling FIPS mode

141

Activating FIPS mode in Linux


You must follow these steps after installation, and BEFORE starting the application for the first
time.
To enable FIPS mode:
1. Install rng-utils.
The encryption algorithm requires that the system have a large entropy pool in order to
generate random numbers. To ensure that the entropy pool remains full, the rngd daemon
must be running while the application is running. The rngd daemon is part of the rng-utils
Linux package.
2. Download and install the rng-utils package using the systems package manager.
Tip: Add the rngd command to the system startup files so that it runs each time the server is
restarted.
3. Run the command rngd -b -r /dev/urandom.
4. Create a properties file for activating FIPS mode.
5. Create a new file using a text editor.
6. Enter the following line in this file:
fipsMode=1

7. Save the file in the [install_directory]/nsc directory with the following name:
CustomEnvironment.properties
8. Start the Security Console.
Activating FIPS mode in Windows
You must follow these steps after installation, and before starting the application for the first time.
To enable FIPS mode:
1. Create a properties file for activating FIPS mode.
2. Create a new file using a text editor.
3. Enter the following line in this file:
fipsMode=1

Enabling FIPS mode

142

Note: You can disable database consistency checks on startup using the
CustomEnvironment.properties file. Do this only if instructed by Technical Support.
4. Save the file in the [install_directory]\nsc directory with the following name:
CustomEnvironment.properties
5. Start the Security Console.
Verifying that FIPS mode is enabled
To ensure that FIPS mode has been successfully enabled, check the Security Console log files
for the following messages:
FIPS 140-2 mode is enabled. Initializing crypto provider
Executing FIPS self tests...

Enabling FIPS mode

143

Using the command console


If you are a Global Administrator, you can perform certain Security Console operations using the
command console. You can see real-time diagnostics and a behind-the-scenes view of the
application when you use this tool.
You can type helpto see a list of all available commands and their descriptions. For more
detailed information, see Available commands on page 145.

Accessing the command console


Global Administrators have access to the Security Console to perform administrative functions.
For a list of commands, see Available commands on page 145.
Accessing the command console in Windows
1. Click the Administration tab in the Security Console Web interface.
The Security Console displays the Administration page.
2. Click the link to Run console commands, which is displayed with the Troubleshootingitem.
The command console page appears with a box for entering commands.
3. Enter a command.
4. Click Execute.
Accessing the command console in Linux
To use the Security Console Web interface in Linux:
1. Start a console screen session if one is not already in progress.
If the host is remote, use SSH to log on first.
2. Type commands and click ENTER.
If you are running the Security Console on an Appliance, you can perform all operations using the
Appliances LCD or via the Security Console Web interface.
For more information on using the Appliance LCD, see the installation and quick-start guide,
which you can download from the Support page of Help.

Using the command console

144

Available commands
A list of available commands follows. Text in square brackets contain optional parameters, as
explained in the action descriptions. Text in arrow brackets contain variables.

Available commands

145

Command

Action

activate

Activate the application with a product key.

database
diagnostics

Check the database for inconsistencies, such as partially deleted sites or missing
synopsis data, which can affect counts of assets, sites, asset groups, scans, or
nodes as displayed in the Web interface.

[show] diag
[nostics]

Display diagnostic information about the Security Console.

exit

Stop the Security Console service.

garbagecollect

Start the garbage collector, a Java application that frees up drive space no longer
used to store data objects.

get property
[<name>]

View the value assigned to a parameter associated with the Scan Engine.
Example: get property os.version. The Security Console would return:
os.version=5.1.If you type get propertywithout a parameter name, the
Security Console will list all properties and associated values. You can view and set
certain properties, such as the IP socket number, which the application uses for
communication between the Security Console and the Scan Engine. Other
properties are for system use only; you may view them but not set them.

heap dump

Dump or list all the data and memory addresses piled up by the Java garbage
collector. The dump file is saved as heap.hprof in the nsc directory.

help

Display all available commands.

license
request fromemail-address
[mail-relayserver]

E-mail a request for a new license. The email-address parameter is your address
as the requestor. The optional mail-relay-server parameter designates an
internally accessible mail server to which the license server should connect to send
the e-mail. After you execute this command, the application displays a message
that the e-mail has been sent. When you receive the license file, store it in the
nsc/licensesdirectory without modifying its contents. Licenses have a .lic
suffix.

log rotate

Compress and save the nsc.log file and then create a new log.

ping
host-address
[tcp-port]

Ping the specified host using an ICNMP ECHO request, ICP ACK packet, and
TCP SYN packet. The default TCP port is 80.

quit

Stop the Security Console service.

restart

Stop the Security Console service and then start it again.

[show]
schedule

Display the currently scheduled jobs for scans, auto-update retriever, temporal risk
score updater, and log rotation.

show host

Display information about the Security Console host, including its name, address,
hardware configuration, and Java Virtual Machine (JVM) version. The command
also returns a summary of disk space used by the installation with respect to the
database, scans, reports, and backups.

Available commands

146

Command

Action

show licenses

Display information about all licenses currently in use. Multiple licenses may
operate at once.

show locked
accounts

List all user accounts locked out by the Security Console. The application can lock
out a user who attempts too many logons with an incorrect password.

show mem

List statistics about memory use.

[send] support
[from-emailaddress] [mailrelay-server]
[messagebody]

Send logs generated by the Security Console and Scan Engine(s) for
troubleshooting support. By default, the application sends the request to a log
server via HTTPS. Alternatively, you can e-mail the request by specifying a
sender's e-mail address or outbound mail relay server. You also can type a brief
message with the e-mail request. When you execute the command, the Security
Console displays a scrolling list of log data, including scheduled scans, autoupdates, and diagnostics.

[show] threads Display the list of active threads in use.


traceroute
host-address

Determine the IP address route between your local host and the host name or IP
address that you specify in the command. When you execute this command, the
Security Console displays a list of IP addresses for all stops or devices on the
given route.

unlock
account
<name>

Unlock the user account named in the command.

update
engines

Send pending updates to all defined Scan Engines.

update now

Check for and apply updates manually and immediately, instead of waiting for the
Security Console to automatically retrieve the next update.

[ver] version

Display the current software version, serial number, most recent update, and other
information about the Security Console and local Scan Engine. Add console to
the command to display information about the Security Console only. Add
engines to the command to display information about the local Scan Engine and
all remote Scan Engines paired with the Security Console.

Display all available commands.

Available commands

147

Troubleshooting
This section provides descriptions of problems commonly encountered when using the
application and guidance for dealing with them. If you do need to contact Technical Support, this
section will help you gather the information that Support needs to assist you.

Working with log files


If you are encountering problems with the Security Console or Scan Engine, you may find it
helpful to consult log files for troubleshooting. Log files can also be useful for routine maintenance
and debugging purposes.
The section does not cover the scan log, which is related to scan events. See Viewing the scan
log on page 158.
Locating each log file and understanding its purpose
Log files are located in [installation_directory]/nsc/logs directory on the Security Console and
[installation_directory]/nse/logs on Scan Engines. The following log files are available:
l

access.log (on the Security Console only): This file captures information about resources that
are being accessed, such as pages in the Web interface. At the INFO level, access.log
captures useful information about API events, such as APIs that are being called, the API
version, and the IP address of the API client. This is useful for monitoring API use and
troubleshooting API issues. The file was called access_log in earlier product versions.
auth.log (on the Security Console only): This file captures each logon or logoff as well as
authentication events, such as authentication failures and lockouts. It is useful for tracking
user sessions. This file was called um_login earlier product versions.
nsc.log (on the Security Console only): This file captures system- and application-level events
in the Security Console. It is useful for tracking and troubleshooting various issues associated
with updates, scheduling of operations, or communication issues with distributed Scan
Engines. Also, if the Security Console goes into Maintenance Mode, you can log on as a
global administrator and use the file to monitor Maintenance Mode activity.
nse.log (on the Security Console and distributed Scan Engines): This file is useful for
troubleshooting certain issues related to vulnerability checks. For example, if a check
produces an unexpected result, you can look at the nse.log file to determine how the scan
target was fingerprinted. On distributed Scan Engines only, this file also captures system- and
application-level events not recorded in any of the other log files.
mem.log (on the Security Console and distributed Scan Engines): This file captures events
related to memory use. It is useful for troubleshooting problems with memory-intensive
operations, such as scanning and reporting.

Troubleshooting

148

In earlier product versions, API information was stored in nsc.log.


Structure and contents of log files
Log files have the following format:
[yyyy-mm-ddThh:mm:ss GMT] [LEVEL] [Thread: NAME] [MESSAGE]

Example:
2011-12-20T16:54:48 [INFO] [Thread: Security Console] Security Console
started in 12 minutes 54 seconds

The date and time correspond to the occurrence of the event that generates the message.
Every log message has a severity level:
Level

Meaning

Example

ERROR

an abnormal event that prevents successful


execution of system processes and can prevent
user operations, such as scanning

the Security Consoles failure


to connect to the database

WARN

an abnormal event that prevents successful


execution of system processes but does not
completely prevent a user operation, such as
scanning

disruption in communication
between the Security Console
and a remote Scan Engine

INFO

a normal, expected event that is noteworthy for


providing useful information about system activity

the Security Consoles


attempts to establish a
connection with a remote Scan
Engine

DEBUG

a normal, expected event that need not be viewed


except for debugging purposes

the execution of operations


within the Security
Console/Scan Engine protocol

When reading through a log file to troubleshoot major issues, you may find it useful look for
ERROR- and WARN-level messages initially.

Thread identifies the process that generated the message.


Configuring which log severity levels are displayed
By default, all log files display messages with severity levels of INFO and higher. This means that
they display INFO, WARN, ERROR messages and do not display DEBUG messages. You can
change which severity levels are displayed in the log files. For example, you might want to filter

Working with log files

149

out all messages except for those with WARN and ERROR severity levels. Or, you may want to
include DEBUG messages for maintenance and debugging purposes.
Configuration steps are identical for the Security Console and distributed Scan Engines. To
configure which log severity levels are displayed, take the following steps:
Note: In the user-log-settings.xml file, defaultrefers to the nsc.log file or nse.log file, depending
on whether the installed component is the Security Console or a distributed Scan Engine.
1. In a text editor, open the user-log-settings.xml file, which is located in the [installation_
directory]/nsc/conf directory.
2. Un-comment the following line by removing the opening and closing comment tags: <!-- and
-->:
<!-- <property name="default-level" value="INFO"/> -->

3. If you want to change the logging level for the nsc.log (for Security Console installations) or
nse.log file (for Scan Engine installations), leave the value defaultunchanged. Otherwise,
change the value to one of the following to specify a different log file:
l

auth

access

mem

4. Change the value in the line to your preferred severity level: DEBUG, INFO, WARN, or
ERROR. Example: <property name="default-level" value="DEBUG"/>
5. To change log levels for additional log files, simply copy and paste the un-commented line,
changing the values accordingly. Examples:
<property name="default-level" value="DEBUG"/>
<property name="auth-level" value="DEBUG"/>
<property name="access-level" value="DEBUG"/>
<property name="mem-level" value="DEBUG"/>

6. Save and close the file.


The change is applied after approximately 30 seconds.

Working with log files

150

Sending logs to Technical Support


You can transmit logs generated by Scan Engines to Technical Support by clicking Send Logson
the Troubleshooting page.
Note: An optional SMTP (e-mail) transport mechanism is also supported when a direct link is
unavailable. Contact Technical Support for more information.
To send logs:
1. Click Send Logson the Troubleshooting page.
The Security Console displays a box for uploading the logs.
2. Select an upload method from the drop-down list.
l HTTPS upload. The application encrypts the logs using PGP before sending them
directly over an SSL connection to the Rapid7DMZ, and subsequently to the Support
database. This method bypasses third-party servers.
l

SMTP. You can e-mail the reports. Contact Technical Support to inquire about this
option before attempting to use it.

3. Type a message to send with the logs.


The message may refer to scan errors, a support case, or a report of aberrant system
behavior.
4. Click Send Logs.

Using a proxy server for sending logs


If the Security Console does not have direct Internet access, you can use a proxy server for
sending logs to Technical Support.
To configure proxy settings for updates:
1. Click the Administration tab.
The Administration page appears.
2. On the Administration page, click the Manage link for the Security Console.
The Security Console Configuration panel appears.

Sending logs to Technical Support

151

3. Go to the Proxy Settings page and find the Support Proxy section of the page.
4. Enter the information for the proxy server in the appropriate fields:
l The Name or addressfield refers to the fully qualified domain name or IP address of
the proxy server.
l

The Portfield is for the number of the port on the proxy server that the Security Console
contacts when sending log files.
The Security Console uses the information in the Domain, User ID, and Password
fields to be authenticated on the proxy server.

5. After you enter the information, click Save.

Security Console Configuration panel - Proxy Settings for sending logs to Technical Support

Troubleshooting scan accuracy issues with logs


If your scans are producing inaccurate results, such as false positives, false negatives, or
incorrect fingerprints, you can use a scan logging feature to collect data that could help the
Technical Support team troubleshoot the cause. Enhanced logging is a feature that collects

Troubleshooting scan accuracy issues with logs

152

information useful for troubleshooting, such as Windows registry keys, SSH command
executions, and file versions, during a scan.
Following is a sample from an Enhanced logging file:
<ace:collected_object>
<ace:source-id>0</ace:source-id>
<ace:thread-activity>do-unix-create-systemfingerprint@example.com:22</ace:thread-activity>
<ace:remote_execution_item id="42">
<ace:command>freebsd-version</ace:command>
<ace:rc datatype="int">0</ace:rc>
<ace:stdin status="does not exist"/>
<ace:stdout>10.0-RELEASE
</ace:stdout>
<ace:stderr status="does not exist"/>
<ace:start_time datatype="int">1443208125966</ace:start_time>
<ace:end_time datatype="int">1443208125982</ace:end_time>
</ace:remote_execution_item>
</ace:collected_object>

Using this feature involves two major steps:


1. Run a scan with a template that has Enhanced logging fully enabled on assets where
inaccurate results are occurring.
2. Send a file containing Enhanced logging data to Technical Support.
Note: It is recommended that you scan individual assets or small sites with Enhanced
Logging enabled.
Enable Enhanced logging in a custom scan template

Enhanced Logging is enabled by default on the Asset Configuration Export scan template. You
may, however, want to scan with a custom template which has been tuned to perform better in
your specific environment. To enable Enhanced logging on a custom scan template:
1. Click the Administration icon.
2. In the Scan Options area, click the Create link to create a new template or click the Manage
link to create a custom template based on an existing template.
3. If you clicked the Manage link, select a template that you want to base the new template on
click the Copy icon.
4. In the configuration of the new template, click the Logging tab.
5. Select the Enhanced logging check box to enable Enhanced logging.
6. Configure the rest of the template as desired and save it.

Troubleshooting scan accuracy issues with logs

153

Run an authenticated scan with the Enhanced logging-enabled template

If you want to scan an entire site with the template, add it to a site configuration and then scan the
site. See Selecting a scan template on page 1.
Note: Enhanced logging gathers a significant amount of data, which may impact disk space,
depending on the number off assets you scan.
If you want to manually scan a specific asset with the template, add the template in the scan
dialog. See Running a manual scan on page 1 .
Retrieve the collected Enhanced logging data and send it to Technical Support

Each scan with Enhanced logging enabled stores a Zip archive of Enhanced logging data in your
scan directory. You can find it at:
[installation_directory]/nse/scans/[silo_ID]/[scan_ID]/ACES.zip.
Example:
/opt/rapid7/nexpose/nexpose/nse/scans/00000000/0000000000000001$/ACES.zip
To determine the specific scan ID, take the following steps:
1. In the Security Console Web interface, click the link for the scan with ACES logging enabled.
2. View the scan ID in the URLfor the scan page.

Troubleshooting scan accuracy issues with logs

154

Determining your scan ID

3. Consult Technical Support on the appropriate method for sending the data, and then send the
.zip file, along with the scan log to Technical Support.

Running diagnostics
You can run several diagnostic functions to catch issues that may be affecting system
performance.
Selecting diagnostic routines
To run diagnostics for internal application issues:
1. Click the Administration tab.
2. The Security Console displays the Administration page.
3. Click Diagnosenext to Troubleshooting.
The Security Console displays the Troubleshootingpage.
4. Click the check box for each diagnostics routine you want to perform.
After performing the requested diagnostics, the Security Console displays a table of results. Each
item includes a red or green icon, indicating whether or not an issue exists with the respective
system component.

Addressing a failure during startup


If a subsystem critical error occurs during startup, then the application will attempt to queue an
appropriate maintenance task to respond to that failure. Afterward, it restarts in maintenance
mode.

Running diagnostics

155

If you are an administrator, you can log on and examine the cause of failure. If required, you can
take certain steps to troubleshoot the issue.
Two types of recovery tasks are available:
l

DBConfigtask is triggered when the application is unable to connect to the configured


database. It allows you to test the database configuration settings and save it upon success.
Recovery task is a general recovery task that is triggered when an unknown failure occurs
during startup. This is very rare and happens only when one or more of the configuration files
is not found or is invalid. This task allows you to view the cause of the failure and upload
support logs to a secure log server, where they can be used for troubleshooting.

The application may fail to restart in maintenance mode in case of extremely critical failures if the
maintenance Web server does not have the default port 3780 available. This may happen if there
is already an instance of it running, or if one or more of the key configuration files is invalid or
missing. These files have extensions such as .nsc, .xml, and .userdb.

Addressing failure to refresh a session


When the Web interface session times out in an idle session, the Security Console displays the
logon window so that the user can refresh the session. If a communication issue between the
Web browser and the Security Console Web server prevents the session from refreshing, a user
will see an error message. If the user has unsaved work, he or she should not leave the page or
close the browser because the work may not be lost after the communication issue is resolved.
A communication failure may occur for one of the following reasons. If any of these is the cause,
take the appropriate action:
l

The Security Console is offline. Restart the Security Console.


The Security Console has been disconnected from the Internet. Reconnect the Security
Console to the Internet.
The users browser has been disconnected from the Internet. Reconnect the browser to the
Internet.
The Security Console address has changed. Clear the address resolution protocol (ARP)
table on the computer hosting the browser.

An extreme delay in the Security Consoles response to the users request to refresh the session
also may cause the failure message to appear.

Addressing failure to refresh a session

156

Resetting account lockout


When a user attempts to log on too many times with an incorrect password, the application locks
out the user until the lockout is reset for that user.
The default lockout threshold is 4 attempts. A global administrator can change this parameter on
the Security Console ConfigurationWeb Serverpage. See Changing the Security Console
Web server default settings on page 81.
You can reset the lockout using one of the following three methods:
l

If youre a global administrator, go to the Userspage, and click the padlock icon that appears
next to the locked out user's name.
Run the console command unlock account. " Using the command console" on page 144.
Restart the Security Console. This is the only method that will work if the locked out user is the
only global administrator in your organization.

Long or hanging scans


Occasionally, a scan will take an unusually long time, or appear to have completely stopped.
It is not possible to predict exactly how long a scan should take. Scan times vary depending on
factors such as the number of target assets and the thoroughness or complexity of the scan
template. However, you can observe whether a scan is taking an exceptionally long time to
complete by comparing the scan time to that of previous scans.
In general, if a scan runs longer than eight hours on a single host, or 48 hours on a given site, it is
advisable to check for certain problems.
Tip for addressing delayed scan operations
If you attempt to start, pause, resume, or stop a scan, and a message appears for a long time
indicating that the operation is in progress, this may be due to a network-related delay in the
Security Console's communication with the Scan Engine. In networks with low bandwidth or high
latency, delayed scan operations may result in frequent time-outs in Security Console/Scan
Engine communication, which may cause lags in the Security Console receiving scan status
information. To reduce time-outs, you can increase the Scan Engine response time out setting.
See Configuring Security Console connections with distributed Scan Engines on page 84.
Scan memory issues
Scans can be slow, or can fail, due to memory issues. See Out-of-memory issues on page 159.

Resetting account lockout

157

Scan complexity
For every target host that it discovers, the application scans its ports before running any
vulnerability checks. The range of target ports is a configurable scan template setting. Scan times
increase in proportion to the number of ports scanned.
In particular, scans of UDP ports can be slow, since the application, by default, sends no more
than two UDP packets per second in order to avoid triggering the ICMP rate-limiting mechanisms
that are built into TCP/IP stacks for most network devices.
To increase scan speed, consider configuring the scan to only examine well-known ports, or
specific ports that are known to host relevant services. See Working with scan templates and
tuning scan performance in the User Guide.
Scan Engine offline
If the Scan Engine goes off line during the scan, the scan will appear to hang. When a Scan
Engine goes off line during the scan, the database will need to remove data from the incomplete
scan. This process leaves messages similar to the following the scan log:
DBConsistenc3/10/09 12:05 PM: Inconsistency discovered for dispatched scan
ID 410, removing partially imported scan results...

If a Scan Engine goes offline, restart it. Then, go the Scan Engine Configuration panel to confirm
that the Scan Engine is active. See Configuring distributed Scan Engines in the User Guide.
Viewing the scan log
You can view an activity log for a scan that is in progress or complete.
To view the scan log:
1. Click View scan log.
The console displays the scan log.
2. Click your browsers Backbutton to return to the Scan Progress page.
Scan stopped by a user
If another user stops a scan, the scan will appear to have hung. To determine if this is the case,
examine the log for a message similar to the following:
Nexpose3/16/09 7:22 PM: Scan [] stopped: "maylor" <>

See Viewing the scan log on page 158.

Long or hanging scans

158

Long or hanging reports


Occasionally, report generation will take an unusually long time, or appear to have completely
stopped. You can find reporting errors in the Security Console logs.
Reporting memory issues
Report generation can be slow, or can fail, due to memory issues. See Out-of-memory issues on
page 159.
Stale scan data
Database speed affects reporting speed. Over time, data from old scans will accumulate in the
database. This causes the database to slow down.
If you find that reporting has become slow, look in the Security Console logs for reporting tasks
whose durations are inconsistent with other reporting tasks, as in the following example:
nsc.log.0:Reportmanage1/5/09 3:00 AM: Report task serviceVulnStatistics
finished in 2 hours 1 minute 23 seconds

You can often increase report generation speed by cleaning up the database. Regular database
maintenance removes leftover scan data and host information. See Viewing the scan log on
page 158and Database backup/restore and data retention on page 116.

Out-of-memory issues
Scanning and reporting are memory-intensive tasks, so errors related to these activities may
often be memory issues. You can control memory use by changing settings. Some memory
issues are related how system resources are controlled.
java.lang.OutofMemoryError
If the application has crashed, you can verify that the crash was due to lack of memory by
checking the log files for the following message:
java.lang.OutOfMemoryError: Java heap space

If you see this message, contact Technical Support. Do not restart the application unless directed
to do so.
Fixing memory problems
Since scanning is memory-intensive and occurs frequently, it is important to control how much
memory scans use so that memory issues do not, in turn, affect scan performance. There are a

Long or hanging reports

159

number of strategies for ensuring that memory limits do not affect scans.
Reduce scan complexity
As the number of target hosts increases, so does the amount of memory needed to store scan
information. If the hosts being scanned have an excessive number of vulnerabilities, scans could
hang due to memory shortages.
To reduce the complexity of a given scan, try a couple of approaches:
l

Reduce the number of target hosts by excluding IP addresses in your site configuration.
Reduce the number of target vulnerabilities by excluding lower-priority checks from your scan
template.

After patching any vulnerabilities uncovered by one scan, add the excluded IP addresses or
vulnerabilities to the site configuration, and run the scan again.
For more information, see Configuring distributed Scan Engines and Working with scan
templates and tuning scan performance in the User Guide.
Reduce Scan Count
Running several simultaneous scans can cause the Security Console to run out of memory.
Reduce the number of simultaneous scans to conserve memory.
Upgrade Hosts
If scans are consistently running out of memory, consider adding more memory to the servers. To
add memory, it might be necessary to upgrade the server operating system as well. On a 64-bit
operating system, the application can address more memory than when it runs on a 32-bit
operating system. However, it requires 8 Gb of memory to run on a 64-bit operating system.
More information on managing scan-related resources
See the following chapters for more detailed information on making scans more memory-friendly:
l

Planning a deployment on page 22.

Working with scan templates and tuning scan performancein the Help.

Update failures
Occasionally, system updates will be unsuccessful. You can find out why by examining the
system logs.

Update failures

160

Corrupt update table


The application keeps track of previously-applied updates in an update table. If the update table
becomes corrupt, the application will not know which updates need to be downloaded and
applied.
If it cannot install updates due to a corrupt update table, the Scan Console log will contain
messages similar to the following:
AutoUpdateJo3/12/09 5:17 AM: NSC update failed:
com.rapid7.updater.UpdateException: java.io.EOFException
at com.rapid7.updater.UpdatePackageProcessor.getUpdateTable(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)

If this occurs, contact Technical Support. See Viewing the scan log on page 158.

Interrupted update
By default, the application automatically downloads and installs updates. The application may
download an update, but its installation attempt may be unsuccessful.
You can find out if this happened by looking at the scan log.
Check for update time stamps that demonstrate long periods of inactivity.
AU-BE37EE72A11/3/08 5:56 PM: updating file: nsc/htroot/help/html/757.htm
NSC 11/3/08 9:57 PM: Logging initialized (system time zone is
SystemV/PST8PDT)

You can use the update now command prompt to re-attempt the update manually:
1. Click the Administrationtab to go to the Administration page.
2. Click Run console commands in the Troubleshooting section.
The Command Console page appears.
3. Enter the command update nowin the text box and click Execute.

Interrupted update

161

The Security Console displays a message to indicate whether the update attempt was
successful. See Viewing the scan log on page 158.
Corrupt File
If the application cannot perform an update due to a corrupt file, the Scan Console log will contain
messages similar to the following:
AU-892F7C6793/7/09 1:19 AM: Applying update id 919518342
AU-892F7C6793/7/09 1:19 AM: error in opening zip file
AutoUpdateJo3/7/09 1:19 AM: NSC update failed:
com.rapid7.updater.UpdateException:
java.util.zip.ZipException: error in opening zip file
at com.rapid7.updater.UpdatePackageProcessor.B(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.updater.UpdatePackageProcessor.getUpdates(Unknown Source)
at com.rapid7.nexpose.nsc.U.execute(Unknown Source)
at com.rapid7.scheduler.Scheduler$_A.run(Unknown Source)

If the update fails due to a corrupt file, it means that the update file was successfully downloaded,
but was invalid. If this occurs, contact Technical Support. See Viewing the scan log on page 158.
Interrupted connection to the update server
If a connection between the Security Console and the update server cannot be made, it will
appear in the logs with a message similar to the following.
AU-A7F0FF3623/10/09 4:53 PM: downloading update: 919518342
AutoUpdateJo3/10/09 4:54 PM: NSC update failed:
java.net.SocketTimeoutException

The java.net.SocketTimeoutException is a sign that a connection cannot be made to the update


server. If the connection has been interrupted, other updates prior to the failure will have been
successful.
You can use theupdate now command prompt to re-attempt the update manually. See
Interrupted update on page 161and Viewing the scan log on page 158.

Interrupted update

162

SCAP compliance
Nexpose complies with Security Content Automation Protocol (SCAP) criteria for an
Unauthenticated Scanner product. SCAP is a collection of standards for expressing and
manipulating security data in standardized ways. It is mandated by the US government and
maintained by the National Institute of Standards and Technology (NIST).
This appendix provides information about how the SCAP standards are implemented for an
Unauthenticated Scanner:
l

The Common Platform Enumeration (CPE) naming scheme, based on the generic syntax
for Uniform Resource Identifiers (URI), is a method for identifying operating systems and
software applications.
The Common Vulnerabilities and Exposures (CVE)standard prescribes how the product
should identify vulnerabilities, making it easier for security products to exchange vulnerability
data.
The Common Vulnerability Scoring System (CVSS)is an open frame work for calculating
vulnerability risk scores.
Common Configuration Enumeration (CCE)is a standard for assigning unique identifiers
known as CCEs to configuration controls to allow consistent identification of these controls in
different environments.

How CPE is implemented


During scans, Nexpose utilizes its fingerprinting technology to recognize target platforms and
applications. After completing scans and populating its scan database with newly acquired data,
it applies CPE names to fingerprinted platforms and applications whenever corresponding CPE
names are available.
Within the database, CPE names are continually kept up to date with changes to the National
Institute of Standards (NIST) CPE dictionary. With every revision to the dictionary, the
application maps newly available CPE names to application descriptions that previously did not
have CPE names.
The Security Console Web interface displays CPE names in scan data tables. You can view
these names in listings of assets, software, and operating systems, as well as on pages for
specific assets. CPE names also appear in reports in the XML Export format.

SCAP compliance

163

How CVE is implemented


When Nexpose populates its scan database with discovered vulnerabilities, it applies Common
Vulnerabilities and Exposures (CVE) identifiers to these vulnerabilities whenever these
identifiers are available.
You can view CVE identifiers on vulnerability detail pages in the Security Console Web interface.
Each listed identifier is a hypertext link to the CVE online database at nvd.nist.gov, where you can
find additional relevant information and links.
You can search for vulnerabilities in the application interface by using CVE identifiers as search
criteria.
CVE identifiers also appear in the Discovered Vulnerabilities sections of reports.
The application uses the most up-to-date CVE listing from the CVE mailing list and changelog.
Since the application always uses the most up-to-date CVE listing, it does not have to list CVE
version numbers. The application updates its vulnerability definitions every six hours through a
subscription service that maintains existing definitions and links and adds new ones continuously.

How CVSS is implemented


For every vulnerability that it discovers, Nexposecomputes a Common Vulnerability Scoring
System (CVSS) Version 2 score. In the Security Console Web interface, each vulnerability is
listed with its CVSS score. You can use this score, severity rankings, and risk scores based on
either temporal or weighted scoring modelsdepending on your configuration preferenceto
prioritize vulnerability remediation tasks.
The application incorporates the CVSS score in the PCI Executive Summary and PCI
Vulnerability Details reports, which provide detailed Payment Card Industry (PCI) compliance
results. Each discovered vulnerability is ranked according to its CVSS score. Rapid7is an
Approved Scanning Vendor (ASV); and Nexposeis a Payment Card Industry (PCI)-sanctioned
tool for conducting compliance audits. CVSS scores correspond to severity rankings, which
ASVs use to determine which determine whether a given asset is compliant with PCI standards.
The application also includes the CVSS score in report sections that appear in various report
templates. The Highest Risk Vulnerability Detailssection lists highest risk vulnerabilities and
includes their categories, risk scores, and their CVSS scores. The Index of Vulnerabilitiessection
includes the severity level and CVSS rating for each vulnerability.
The PCI Vulnerability Details section contains in-depth information about each vulnerability
included in a PCI Audit (legacy) report. It quantifies the vulnerability according to its severity level
and its CVSS rating.

How CVE is implemented

164

How CCE is implemented


Nexposetests assets for compliance with configuration policies. It displays the results of
compliance tests on the scan results page of every tested asset. The Policy Listingtable on this
page displays every policy against which the asset was tested.
Every listed policy is a hyperlink to a page about that policy, which includes a table of its
constituent rules. Each listed rule is a hyperlink to a page about that rule. The rule page includes
detailed technical information about the rule and lists its CCE identifier.
CCE entries can be found via the search feature. See Using the Search featurein the users
guide.

Where to find SCAP update information and OVAL files


Nexposeautomatically includes any new SCAP content with each content update. You can view
SCAP update information on the SCAP page, which you can access from the Administration
page in Security Console Web interface.
Four tables appear on the SCAP page:
l

CPE Data

CVE Data

CVSS Data

CCE Data

Each table lists the most recent content update that included new SCAP data and the most
recent date that NIST generated new data.
On the SCAP page you also can view a list of Open Vulnerability and Assessment Language
(OVAL) files that it has imported during configuration policy checks. In compliance with an FDCC
requirement, each listed file name is a hyperlink that you can click to download the XMLstructured check content.

How CCE is implemented

165

Glossary
API (application programming interface)
An API is a function that a developer can integrate with another software application by using
program calls. The term API also refers to one of two sets of XML APIs, each with its own
included operations: API v1.1 and Extended API v1.2. To learn about each API, see the API
documentation, which you can download from the Support page in Help.
Appliance
An Appliance is a set of Nexpose components shipped as a dedicated hardware/software unit.
Appliance configurations include a Security Console/Scan Engine combination and an Scan
Engine-only version.
Asset
An asset is a single device on a network that the application discovers during a scan. In the Web
interface and API, an asset may also be referred to as a device. See Managed asset on page
172 and Unmanaged asset on page 180. An assets data has been integrated into the scan
database, so it can be listed in sites and asset groups. In this regard, it differs from a node. See
Node on page 173.
Asset group
An asset group is a logical collection of managed assets to which specific members have access
for creating or viewing reports or tracking remediation tickets. An asset group may contain assets
that belong to multiple sites or other asset groups. An asset group is either static or dynamic. An
asset group is not a site. See Site on page 178, Dynamic asset group on page 170, and Static
asset group on page 178.
Asset Owner
Asset Owner is one of the preset roles. A user with this role can view data about discovered
assets, run manual scans, and create and run reports in accessible sites and asset groups.
Asset Report Format (ARF)
The Asset Report Format is an XML-based report template that provides asset information
based on connection type, host name, and IP address. This template is required for submitting
reports of policy scan results to the U.S. government for SCAP certification.

Glossary

166

Asset search filter


An asset search filter is a set of criteria with which a user can refine a search for assets to include
in a dynamic asset group. An asset search filter is different from a Dynamic Discovery filter on
page 170.
Authentication
Authentication is the process of a security application verifying the logon credentials of a client or
user that is attempting to gain access. By default the application authenticates users with an
internal process, but you can configure it to authenticate users with an external LDAP or
Kerberos source.
Average risk
Average risk is a setting in risk trend report configuration. It is based on a calculation of your risk
scores on assets over a report date range. For example, average risk gives you an overview of
how vulnerable your assets might be to exploits whether its high or low or unchanged. Some
assets have higher risk scores than others. Calculating the average score provides a high-level
view of how vulnerable your assets might be to exploits.
Benchmark
In the context of scanning for FDCC policy compliance, a benchmark is a combination of policies
that share the same source data. Each policy in the Policy Manager contains some or all of the
rules that are contained within its respective benchmark. See Federal Desktop Core
Configuration (FDCC) on page 171 and United States Government Configuration Baseline
(USGCB) on page 179.
Breadth
Breadth refers to the total number of assets within the scope of a scan.
Category
In the context of scanning for FDCC policy compliance, a category is a grouping of policies in the
Policy Manager configuration for a scan template. A policys category is based on its source,
purpose, and other criteria. SeePolicy Manager on page 174, Federal Desktop Core
Configuration (FDCC) on page 171, and United States Government Configuration Baseline
(USGCB) on page 179.
Check type
A check type is a specific kind of check to be run during a scan. Examples: The Unsafe check type
includes aggressive vulnerability testing methods that could result in Denial of Service on target

Glossary

167

assets; the Policy check type is used for verifying compliance with policies. The check type setting
is used in scan template configurations to refine the scope of a scan.
Center for Internet Security (CIS)
Center for Internet Security (CIS) is a not-for-profit organization that improves global security
posture by providing a valued and trusted environment for bridging the public and private sectors.
CIS serves a leadership role in the shaping of key security policies and decisions at the national
and international levels. The Policy Manager provides checks for compliance with CIS
benchmarks including technical control rules and values for hardening network devices,
operating systems, and middleware and software applications. Performing these checks requires
a license that enables the Policy Manager feature and CIS scanning. See Policy Manager on
page 174.
Command console
The command console is a page in the Security Console Web interface for entering commands to
run certain operations. When you use this tool, you can see real-time diagnostics and a behindthe-scenes view of Security Console activity. To access the command console page, click the
Run Security Console commands link next to the Troubleshooting item on the Administration
page.
Common Configuration Enumeration (CCE)
Common Configuration Enumeration (CCE) is a standard for assigning unique identifiers known
as CCEs to configuration controls to allow consistent identification of these controls in different
environments. CCE is implemented as part of its compliance with SCAP criteria for an
Unauthenticated Scanner product.
Common Platform Enumeration (CPE)
Common Platform Enumeration (CPE) is a method for identifying operating systems and
software applications. Its naming scheme is based on the generic syntax for Uniform Resource
Identifiers (URI). CCE is implemented as part of its compliance with SCAP criteria for an
Unauthenticated Scanner product.
Common Vulnerabilities and Exposures (CVE)
The Common Vulnerabilities and Exposures (CVE) standard prescribes how the application
should identify vulnerabilities, making it easier for security products to exchange vulnerability
data. CVE is implemented as part of its compliance with SCAP criteria for an Unauthenticated
Scanner product.

Glossary

168

Common Vulnerability Scoring System (CVSS)


Common Vulnerability Scoring System (CVSS) is an open framework for calculating vulnerability
risk scores. CVSS is implemented as part of its compliance with SCAP criteria for an
Unauthenticated Scanner product.
Compliance
Compliance is the condition of meeting standards specified by a government or respected
industry entity. The application tests assets for compliance with a number of different security
standards, such as those mandated by the Payment Card Industry (PCI) and those defined by
the National Institute of Standards and Technology (NIST) for Federal Desktop Core
Configuration (FDCC).
Continuous scan
A continuous scan starts over from the beginning if it completes its coverage of site assets within
its scheduled window. This is a site configuration setting.
Coverage
Coverage indicates the scope of vulnerability checks. A coverage improvement listed on the
News page for a release indicates that vulnerability checks have been added or existing checks
have been improved for accuracy or other criteria.
Criticality
Criticality is a value that you can apply to an asset with a RealContext tag to indicate its
importance to your business. Criticality levels range from Very Low to Very High. You can use
applied criticality levels to alter asset risk scores. See Criticality-adjusted risk.
Criticality-adjusted risk
or
Context-driven risk
Criticality-adjusted risk is a process for assigning numbers to criticality levels and using those
numbers to multiply risk scores.
Custom tag
With a custom tag you can identify assets by according to any criteria that might be meaningful to
your business.

Glossary

169

Depth
Depth indicates how thorough or comprehensive a scan will be. Depth refers to level to which the
application will probe an individual asset for system information and vulnerabilities.
Discovery (scan phase)
Discovery is the first phase of a scan, in which the application finds potential scan targets on a
network. Discovery as a scan phase is different from Dynamic Discovery on page 170.
Document report template
Document templates are designed for human-readable reports that contain asset and
vulnerability information. Some of the formats available for this template typeText, PDF, RTF,
and HTMLare convenient for sharing information to be read by stakeholders in your
organization, such as executives or security team members tasked with performing remediation.
Dynamic asset group
A dynamic asset group contains scanned assets that meet a specific set of search criteria. You
define these criteria with asset search filters, such as IP address range or operating systems. The
list of assets in a dynamic group is subject to change with every scan or when vulnerability
exceptions are created. In this regard, a dynamic asset group differs from a static asset group.
See Asset group on page 166 and Static asset group on page 178.
Dynamic Discovery
Dynamic Discovery is a process by which the application automatically discovers assets through
a connection with a server that manages these assets. You can refine or limit asset discovery
with criteria filters. Dynamic discovery is different from Discovery (scan phase) on page 170.
Dynamic Discovery filter
A Dynamic Discovery filter is a set of criteria refining or limiting Dynamic Discovery results. This
type of filter is different from an Asset search filter on page 167.
Dynamic Scan Pool
The Dynamic Scan Pool feature allows you to use Scan Engine pools to enhance the consistency
of your scan coverage. A Scan Engine pool is a group of shared Scan Engines that can be bound
to a site so that the load is distributed evenly across the shared Scan Engines. You can configure
scan pools using the Extended API v1.2.

Glossary

170

Dynamic site
A dynamic site is a collection of assets that are targeted for scanning and that have been
discovered through vAsset discovery. Asset membership in a dynamic site is subject to change if
the discovery connection changes or if filter criteria for asset discovery change. See Static site on
page 179, Site on page 178, and Dynamic Discovery on page 170.
Exploit
An exploit is an attempt to penetrate a network or gain access to a computer through a security
flaw, or vulnerability. Malicious exploits can result in system disruptions or theft of data.
Penetration testers use benign exploits only to verify that vulnerabilities exist. The Metasploit
product is a tool for performing benign exploits. See Metasploit on page 173 and Published
exploit on page 175.
Export report template
Export templates are designed for integrating scan information into external systems. The
formats available for this type include various XML formats, Database Export, and CSV.
Exposure
An exposure is a vulnerability, especially one that makes an asset susceptible to attack via
malware or a known exploit.
Extensible Configuration Checklist Description Format (XCCDF)
As defined by the National Institute of Standards and Technology (NIST), Extensible
Configuration Checklist Description Format (XCCDF) is a specification language for writing
security checklists, benchmarks, and related documents. An XCCDF document represents a
structured collection of security configuration rules for some set of target systems. The
specification is designed to support information interchange, document generation,
organizational and situational tailoring, automated compliance testing, and compliance scoring.
Policy Manager checks for FDCC policy compliance are written in this format.
False positive
A false positive is an instance in which the application flags a vulnerability that doesnt exist. A
false negative is an instance in which the application fails to flag a vulnerability that does exist.
Federal Desktop Core Configuration (FDCC)
The Federal Desktop Core Configuration (FDCC) is a grouping of configuration security settings
recommended by the National Institute of Standards and Technology (NIST) for computers that
are connected directly to the network of a United States government agency. The Policy

Glossary

171

Manager provides checks for compliance with these policies in scan templates. Performing these
checks requires a license that enables the Policy Manager feature and FDCC scanning.
Fingerprinting
Fingerprinting is a method of identifying the operating system of a scan target or detecting a
specific version of an application.
Global Administrator
Global Administrator is one of the preset roles. A user with this role can perform all operations
that are available in the application and they have access to all sites and asset groups.
Host
A host is a physical or virtual server that provides computing resources to a guest virtual machine.
In a high-availability virtual environment, a host may also be referred to as a node. The term node
has a different context in the application. See Node on page 173.
Latency
Latency is the delay interval between the time when a computer sends data over a network and
another computer receives it. Low latency means short delays.
Locations tag
With a Locations tag you can identify assets by their physical or geographic locations.
Malware
Malware is software designed to disrupt or deny a target systemss operation, steal or
compromise data, gain unauthorized access to resources, or perform other similar types of
abuse. The application can determine if a vulnerability renders an asset susceptible to malware
attacks.
Malware kit
Also known as an exploit kit, a malware kit is a software bundle that makes it easy for malicious
parties to write and deploy code for attacking target systems through vulnerabilities.
Managed asset
A managed asset is a network device that has been discovered during a scan and added to a
sites target list, either automatically or manually. Only managed assets can be checked for
vulnerabilities and tracked over time. Once an asset becomes a managed asset, it counts against
the maximum number of assets that can be scanned, according to your license.

Glossary

172

Manual scan
A manual scan is one that you start at any time, even if it is scheduled to run automatically at other
times. Synonyms include ad-hoc scan and unscheduled scan.
Metasploit
Metasploit is a product that performs benign exploits to verify vulnerabilities. See Exploit on page
171.
MITRE
The MITRE Corporation is a body that defines standards for enumerating security-related
concepts and languages for security development initiatives. Examples of MITRE-defined
enumerations include Common Configuration Enumeration (CCE) and Common Vulnerability
Enumeration (CVE). Examples of MITRE-defined languages include Open Vulnerability and
Assessment Language (OVAL). A number of MITRE standards are implemented, especially in
verification of FDCC compliance.
National Institute of Standards and Technology (NIST)
National Institute of Standards and Technology (NIST) is a non-regulatory federal agency within
the U.S. Department of Commerce. The agency mandates and manages a number of security
initiatives, including Security Content Automation Protocol (SCAP). See Security Content
Automation Protocol (SCAP) on page 177.
Node
A node is a device on a network that the application discovers during a scan. After the application
integrates its data into the scan database, the device is regarded as an asset that can be listed in
sites and asset groups. See Asset on page 166.
Open Vulnerability and Assessment Language (OVAL)
Open Vulnerability and Assessment Language (OVAL) is a development standard for gathering
and sharing security-related data, such as FDCC policy checks. In compliance with an FDCC
requirement, each OVAL file that the application imports during configuration policy checks is
available for download from the SCAP page in the Security Console Web interface.
Override
An override is a change made by a user to the result of a check for compliance with a
configuration policy rule. For example, a user may override a Fail result with a Pass result.

Glossary

173

Payment Card Industry (PCI)


The Payment Card Industry (PCI) is a council that manages and enforces the PCI Data Security
Standard for all merchants who perform credit card transactions. The application includes a scan
template and report templates that are used by Approved Scanning Vendors (ASVs) in official
merchant audits for PCI compliance.
Permission
A permission is the ability to perform one or more specific operations. Some permissions only
apply to sites or asset groups to which an assigned user has access. Others are not subject to this
kind of access.
Policy
A policy is a set of primarily security-related configuration guidelines for a computer, operating
system, software application, or database. Two general types of polices are identified in the
application for scanning purposes: Policy Manager policies and standard policies. The
application's Policy Manager (a license-enabled feature) scans assets to verify compliance with
policies encompassed in the United States Government Configuration Baseline (USGCB), the
Federal Desktop Core Configuration (FDCC), Center for Internet Security (CIS), and Defense
Information Systems Agency (DISA) standards and benchmarks, as well as user-configured
custom policies based on these policies. See Policy Manager on page 174, Federal Desktop
Core Configuration (FDCC) on page 171, United States Government Configuration Baseline
(USGCB) on page 179, and Scan on page 176. The application also scans assets to verify
compliance with standard policies. See Scan on page 176 and Standard policy on page 178.
Policy Manager
Policy Manager is a license-enabled scanning feature that performs checks for compliance with
Federal Desktop Core Configuration (FDCC), United States Government Configuration
Baseline (USGCB), and other configuration policies. Policy Manager results appear on the
Policies page, which you can access by clicking the Policies icon in the Web interface. They also
appear in the Policy Listing table for any asset that was scanned with Policy Manager checks.
Policy Manager policies are different from standard policies, which can be scanned with a basic
license. See Policy on page 174 and Standard policy on page 178.
Policy Result
In the context of FDCC policy scanning, a result is a state of compliance or non-compliance with a
rule or policy. Possible results include Pass, Fail, or Not Applicable.

Glossary

174

Policy Rule
A rule is one of a set of specific guidelines that make up an FDCC configuration policy. See
Federal Desktop Core Configuration (FDCC) on page 171, United States Government
Configuration Baseline (USGCB) on page 179, and Policy on page 174.
Potential vulnerability
A potential vulnerability is one of three positive vulnerability check result types. The application
reports a potential vulnerability during a scan under two conditions: First, potential vulnerability
checks are enabled in the template for the scan. Second, the application determines that a target
is running a vulnerable software version but it is unable to verify that a patch or other type of
remediation has been applied. For example, an asset is running version 1.1.1 of a database. The
vendor publishes a security advisory indicating that version 1.1.1 is vulnerable. Although a patch
is installed on the asset, the version remains 1.1.1. In this case, if the application is running
checks for potential vulnerabilities, it can only flag the host asset as being potentially vulnerable.
The code for a potential vulnerability in XML and CSV reports is vp (vulnerable, potential). For
other positive result types, see Vulnerability check on page 181.
Published exploit
In the context of the application, a published exploit is one that has been developed in Metasploit
or listed in the Exploit Database. See Exploit on page 171.
RealContext
RealContext is a feature that enables you to tag assets according to how they affect your
business. You can use tags to specify the criticality, location, or ownership. You can also use
custom tags to identify assets according any criteria that is meaningful to your organization.
Real Risk strategy
Real Risk is one of the built-in strategies for assessing and analyzing risk. It is also the
recommended strategy because it applies unique exploit and malware exposure metrics for each
vulnerability to Common Vulnerability Scoring System (CVSS) base metrics for likelihood
(access vector, access complexity, and authentication requirements) and impact to affected
assets (confidentiality, integrity, and availability). See Risk strategy on page 176.
Report template
Each report is based on a template, whether it is one of the templates that is included with the
product or a customized template created for your organization. See Document report template
on page 170 and Export report template on page 171.

Glossary

175

Risk
In the context of vulnerability assessment, risk reflects the likelihood that a network or computer
environment will be compromised, and it characterizes the anticipated consequences of the
compromise, including theft or corruption of data and disruption to service. Implicitly, risk also
reflects the potential damage to a compromised entitys financial well-being and reputation.
Risk score
A risk score is a rating that the application calculates for every asset and vulnerability. The score
indicates the potential danger posed to network and business security in the event of a malicious
exploit. You can configure the application to rate risk according to one of several built-in risk
strategies, or you can create custom risk strategies.
Risk strategy
A risk strategy is a method for calculating vulnerability risk scores. Each strategy emphasizes
certain risk factors and perspectives. Four built-in strategies are available: Real Risk strategy on
page 175, TemporalPlus risk strategy on page 179, Temporal risk strategy on page 179, and
Weighted risk strategy on page 181. You can also create custom risk strategies.
Risk trend
A risk trend graph illustrates a long-term view of your assets probability and potential impact of
compromise that may change over time. Risk trends can be based on average or total risk
scores. The highest-risk graphs in your report demonstrate the biggest contributors to your risk
on the site, group, or asset level. Tracking risk trends helps you assess threats to your
organizations standings in these areas and determine if your vulnerability management efforts
are satisfactorily maintaining risk at acceptable levels or reducing risk over time. See Average risk
on page 167 and Total risk on page 179.
Role
A role is a set of permissions. Five preset roles are available. You also can create custom roles by
manually selecting permissions. See Asset Owner on page 166, Security Manager on page 178,
Global Administrator on page 172, Site Owner on page 178, and User on page 180.
Scan
A scan is a process by which the application discovers network assets and checks them for
vulnerabilities. See Exploit on page 171 and Vulnerability check on page 181.

Glossary

176

Scan credentials
Scan credentials are the user name and password that the application submits to target assets
for authentication to gain access and perform deep checks. Many different authentication
mechanisms are supported for a wide variety of platforms. See Shared scan credentials on page
178 and Site-specific scan credentials on page 178.
Scan Engine
The Scan Engine is one of two major application components. It performs asset discovery and
vulnerability detection operations. Scan engines can be distributed within or outside a firewall for
varied coverage. Each installation of the Security Console also includes a local engine, which can
be used for scans within the consoles network perimeter.
Scan template
A scan template is a set of parameters for defining how assets are scanned. Various preset scan
templates are available for different scanning scenarios. You also can create custom scan
templates. Parameters of scan templates include the following:
l

methods for discovering assets and services

types of vulnerability checks, including safe and unsafe

Web application scanning properties

verification of compliance with policies and standards for various platforms

Scheduled scan
A scheduled scan starts automatically at predetermined points in time. The scheduling of a scan
is an optional setting in site configuration. It is also possible to start any scan manually at any time.
Security Console
The Security Console is one of two major application components. It controls Scan Engines and
retrieves scan data from them. It also controls all operations and provides a Web-based user
interface.
Security Content Automation Protocol (SCAP)
Security Content Automation Protocol (SCAP) is a collection of standards for expressing and
manipulating security data. It is mandated by the U.S. government and maintained by the
National Institute of Standards and Technology (NIST). The application complies with SCAP
criteria for an Unauthenticated Scanner product.

Glossary

177

Security Manager
Security Manager is one of the preset roles. A user with this role can configure and run scans,
create reports, and view asset data in accessible sites and asset groups.
Shared scan credentials
One of two types of credentials that can be used for authenticating scans, shared scan
credentials are created by Global Administrators or users with the Manage Site permission.
Shared credentials can be applied to multiple assets in any number of sites. See Site-specific
scan credentials on page 178.
Site
A site is a collection of assets that are targeted for a scan. Each site is associated with a list of
target assets, a scan template, one or more Scan Engines, and other scan-related settings. See
Dynamic site on page 171 and Static site on page 179. A site is not an asset group. See Asset
group on page 166.
Site-specific scan credentials
One of two types of credentials that can be used for authenticating scans, a set of single-instance
credentials is created for an individual site configuration and can only be used in that site. See
Scan credentials on page 177 and Shared scan credentials on page 178.
Site Owner
Site Owner is one of the preset roles. A user with this role can configure and run scans, create
reports, and view asset data in accessible sites.
Standard policy
A standard policy is one of several that the application can scan with a basic license, unlike with a
Policy Manager policy. Standard policy scanning is available to verify certain configuration
settings on Oracle, Lotus Domino, AS/400, Unix, and Windows systems. Standard policies are
displayed in scan templates when you include policies in the scope of a scan. Standard policy
scan results appear in the Advanced Policy Listing table for any asset that was scanned for
compliance with these policies. See Policy on page 174.
Static asset group
A static asset group contains assets that meet a set of criteria that you define according to your
organization's needs. Unlike with a dynamic asset group, the list of assets in a static group does
not change unless you alter it manually. See Dynamic asset group on page 170.

Glossary

178

Static site
A static site is a collection of assets that are targeted for scanning and that have been manually
selected. Asset membership in a static site does not change unless a user changes the asset list
in the site configuration. For more information, see Dynamic site on page 171 and Site on page
178.
Temporal risk strategy
One of the built-in risk strategies, Temporal indicates how time continuously increases likelihood
of compromise. The calculation applies the age of each vulnerability, based on its date of public
disclosure, as a multiplier of CVSS base metrics for likelihood (access vector, access complexity,
and authentication requirements) and asset impact (confidentiality, integrity, and availability).
Temporal risk scores will be lower than TemporalPlus scores because Temporal limits the risk
contribution of partial impact vectors. See Risk strategy on page 176.
TemporalPlus risk strategy
One of the built-in risk strategies, TemporalPlus provides a more granular analysis of vulnerability
impact, while indicating how time continuously increases likelihood of compromise. It applies a
vulnerability's age as a multiplier of CVSS base metrics for likelihood (access vector, access
complexity, and authentication requirements) and asset impact (confidentiality, integrity, and
availability). TemporalPlus risk scores will be higher than Temporal scores because
TemporalPlus expands the risk contribution of partial impact vectors. See Risk strategy on page
176.
Total risk
Total risk is a setting in risk trend report configuration. It is an aggregated score of vulnerabilities
on assets over a specified period.
United States Government Configuration Baseline (USGCB)
The United States Government Configuration Baseline (USGCB) is an initiative to create
security configuration baselines for information technology products deployed across U.S.
government agencies. USGCB evolved from FDCC, which it replaces as the configuration
security mandate in the U.S. government. The Policy Manager provides checks for Microsoft
Windows 7, Windows 7 Firewall, and Internet Explorer for compliance with USGCB baselines.
Performing these checks requires a license that enables the Policy Manager feature and USGCB
scanning. See Policy Manager on page 174 and Federal Desktop Core Configuration (FDCC)
on page 171.

Glossary

179

Unmanaged asset
An unmanaged asset is a device that has been discovered during a scan but not correlated
against a managed asset or added to a sites target list. The application is designed to provide
sufficient information about unmanaged assets so that you can decide whether to manage them.
An unmanaged asset does not count against the maximum number of assets that can be
scanned according to your license.
Unsafe check
An unsafe check is a test for a vulnerability that can cause a denial of service on a target system.
Be aware that the check itself can cause a denial of service, as well. It is recommended that you
only perform unsafe checks on test systems that are not in production.
Update
An update is a released set of changes to the application. By default, two types of updates are
automatically downloaded and applied:

Content updates include new checks for vulnerabilities, patch verification, and security policy
compliance. Content updates always occur automatically when they are available.
Product updates include performance improvements, bug fixes, and new product features.
Unlike content updates, it is possible to disable automatic product updates and update the
product manually.
User
User is one of the preset roles. An individual with this role can view asset data and run reports in
accessible sites and asset groups.
Validated vulnerability
A validated vulnerability is a vulnerability that has had its existence proven by an integrated
Metasploit exploit. See Exploit on page 171.
Vulnerable version
Vulnerable version is one of three positive vulnerability check result types. The application reports
a vulnerable version during a scan if it determines that a target is running a vulnerable software
version and it can verify that a patch or other type of remediation has not been applied. The code
for a vulnerable version in XML and CSV reports is vv (vulnerable, version check). For other
positive result types, see Vulnerability check on page 181.
Vulnerability
A vulnerability is a security flaw in a network or computer.

Glossary

180

Vulnerability category
A vulnerability category is a set of vulnerability checks with shared criteria. For example, the
Adobe category includes checks for vulnerabilities that affect Adobe applications. There are also
categories for specific Adobe products, such as Air, Flash, and Acrobat/Reader. Vulnerability
check categories are used to refine scope in scan templates. Vulnerability check results can also
be filtered according category for refining the scope of reports. Categories that are named for
manufacturers, such as Microsoft, can serve as supersets of categories that are named for their
products. For example, if you filter by the Microsoft category, you inherently include all Microsoft
product categories, such as Microsoft Path and Microsoft Windows. This applies to other
company categories, such as Adobe, Apple, and Mozilla.
Vulnerability check
A vulnerability check is a series of operations that are performed to determine whether a security
flaw exists on a target asset. Check results are either negative (no vulnerability found) or positive.
A positive result is qualified one of three ways: See Vulnerability found on page 181, Vulnerable
version on page 180, and Potential vulnerability on page 175. You can see positive check result
types in XML or CSV export reports. Also, in a site configuration, you can set up alerts for when a
scan reports different positive results types.
Vulnerability exception
A vulnerability exception is the removal of a vulnerability from a report and from any asset listing
table. Excluded vulnerabilities also are not considered in the computation of risk scores.
Vulnerability found
Vulnerability found is one of three positive vulnerability check result types. The application reports
a vulnerability found during a scan if it verified the flaw with asset-specific vulnerability tests, such
as an exploit. The code for a vulnerability found in XML and CSV reports is ve (vulnerable,
exploited). For other positive result types, see Vulnerability check on page 181.
Weighted risk strategy
One of the built-in risk strategies, Weighted is based primarily on asset data and vulnerability
types, and it takes into account the level of importance, or weight, that you assign to a site when
you configure it. See Risk strategy on page 176.

Glossary

181