Nexpose Admin Guide PDF

Nexpose
Administrator's Guide
Product version: 6.3
Contents
Contents 2
Revision history 6
About this guide 9
A note about documented features 9
Other documents and Help 9
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 I want 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 2
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 3
Connecting to Project Sonar 108
Setting up a Sonar query 109
Filtering data from Project 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 4
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 5
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.
Corrected a step in FIPS configuration instructions; added information
September 13, 2010
about how to configure data warehousing.
Added instructions for verifying that FIPS mode is enabled; added section
September 22, 2010
on managing updates
October 25, 2010 Updated instructions for activating, modifying, or renewing licenses.
December 13, 2010 Added instructions for SSH public key authentication.
Added instructions for using Asset Filter search and creating dynamic asset
December 20, 2010 groups. Also added instructions for using new asset search features when
creating static asset groups and reports.
Added instructions for migrating the database, enabling check correlation,
March 16, 2011 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.
Updated instructions for configuring Web spidering and migrating the
April 18, 2011
database.
Added information about Scan Engine pooling, expanded permissions, and
July 11, 2011
using the command console.
Corrected directory information for pairing the Security Console with Scan
July 25, 2011
Engines.
Updated information about Dynamic Scan Pooling and FIPS mode
September 19, 2011
configuration.
Added information about vAsset discovery, dynamic site management, new
November 15, 2011 Real Risk and TemporalPlus risk strategies, and the Advanced Policy
Engine.
Added note about how vAsset discovery currently finds assets in vSphere
December 5, 2011
deployments only. Corrected some formatting issues.
January 23, 2012 Added information about the platform-independent backup option.
Revision history 6
Added information about search filters for virtual assets, logging changes,
March 21, 2012
and configuration options for Kerberos encryption.
Nexpose 5.3: Removed information about deprecated logging configuration
June 6, 2012
page.
Nexpose 5.4: Added information about PostgreSQL database tuning;
August 8, 2012 updated required JAR files for offline updates; added troubleshooting
guidance for session time-out issues.
Nexpose 5.5: Added information about using the show host command and
December 10, 2012
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.
Added information on new processes for activating and updating in private
September 18, 2013
networks. Updated information on console commands.
November 13, 2013 Nexpose 5.8: Updated page layout and version number.
Nexpose 5.9: Added information about the Manage Tags permission and
March 26, 2014
data retention.
August 6, 2014 Updated document look and feel.
October 10, 2014 Made minor formatting changes.
Added information about Scan Engine pooling, cumulative scan results, and
October 23, 2014
update scheduling.
Corrected issue that prevented equations from appearing in capacity
March 11, 2015
planning section.
Nexpose 5.13: Added information about linking matching assets across
April 8, 2015
sites.
Nexpose 5.14: Added information about password policy configuration;
May 27, 2015
Scan Engine communication direction; database updates.
Nexpose 5.15: Added note that the option for linking assets across sites is
June 24, 2015 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 7
Nexpose 6.0: Updated screen shots to reflect new look and feel of Web
October 8, 2015 interface. Added instructions on Troubleshooting scan accuracy issues with
logs on page 152.
Removed reference to Ubuntu 8.04, which is no longer supported. Added
October 28, 2015 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 ACES logging to new enhanced logging.
Nexpose 6.3: Updated to reflect the opt-in feature to access newly added
June 7, 2016
dashboards and cards enabled with advanced exposure analytics.
Revision history 8
About this guide
This guide helps you to ensure that Nexpose works effectively and consistently in support of your
organization’s security objectives. It provides instruction for doing key administrative tasks:
l configuring host systems for maximum performance

l database tuning
l planning a deployment, including determining how to distribute Scan Engines
l capacity planning
l managing user accounts, roles, and permissions
l administering the Security Console and Scan Engines
l working with the database, backups, and restores
l using the command console
l 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 organization’s Nexpose deployment.

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

User’s guide
The user’s 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
l managing dynamic discovery
l setting up sites and scans
l running scans manually
l viewing asset and vulnerability data
l creating remediation tickets
l using preset and custom report templates
l using report formats
l reading and interpreting report data
l configuring scan templates
l 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).

l Click the Support link on the Security Console Web interface.
l 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 Console’s 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.
l The frequency with which it will scan those assets: Scanning daily produces seven times more
data than scanning weekly.
l The depth of scanning. A Web scan typically requires more time and resources than a
network scan.
l 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 organization’s 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)
l processor: 2x Intel quad-core Xeon 55xx “Nehalem” CPUs (2 sockets, 8 cores, and 16
threads total)
l RAM: 48-96 GB with error-correction code (ECC) memory; some 2-socket LGA1366
motherboards can support up to 144GB, with 8GB DDR3 modules
l 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
l 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
l 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

l Red Hat Enterprise Linux 6 64-bit
l Ubuntu 10.04 LTS 64-bit
l 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
l configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)
l licenses
l keystores
l report images
l custom report templates
l custom scan templates
l generated reports
l 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.
l Compress database tables to free up unused table space.
l 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

Recommended Recommended
Default
Parameter Description midrange enterprise
value
settings settings
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 This value is
benefit from a much larger set on
setting for shared_buffers. PostgreSQL
shared_ Midrange configurations should startup
24 MB 1950 MB
buffers retain the default that based on
PostgreSQL allocates on first operating
system
installation.
settings.
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
This is the maximum number of

concurrent connections to the
database server. Increase this
value if you anticipate a significant
max_
rise in the number of users and 100 200 300
connections
concurrent scans. Note that
increasing this value requires
approximately 400 bytes of shared
memory per connection slot.
This is the amount of memory that
internal sort operations and hash
work_mem 1 MB 32 MB 32 MB
tables use before switching to
temporary disk files.

Default
value
settings settings
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
checkpoint_ content of the log. The checkpoint_
3 3 32
segments 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.
This setting reflects assumptions
4 GB (For
about the effective portion of disk
configurations
cache that is available for a single
with more than
effective_ query. It is factored into estimates
128 MB 16 GB of RAM, 32 GB
cache_size of the cost of using an index. A
use half of the
higher value makes an index scan
available RAM
more likely. A lower value makes
as the setting.)
sequential scans more likely.

Default
value
settings settings
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
logging: log_ ascending order: DEBUG5,
min_error_ DEBUG4, DEBUG3, DEBUG2, ERROR ERROR ERROR
statement 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.
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 -1 (Set -1 (Set
logging: log_
of -1 means logging is disabled. To recommended recommended
min_
enable logging, change the value -1 value to 0 only if value to 0 only if
duration_
to 0. This will increase page required for required for
statement
response time by approximately 5 debugging) debugging)
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.

Default
value
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
wal_buffers performance in any way. So, for an 64 KB 64 KB 8 MB
application in which the
select/update ratio is very high,
wal_buffers is almost an irrelevant
optimization.
This setting specifies the maximum
amount of memory to be used by
maintenance_ maintenance operations, such as
16 MB 16 MB 512 MB
work_mem VACUUM, CREATE INDEX, and
ALTER TABLE ADD FOREIGN
KEY.
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.

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
organization’s 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 scans—for example, on a weekly basis instead of daily—until 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.
l 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 organization’s 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

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

l Security Manager and Site Owner on page 68
l Asset Owner on page 68 Asset Owner
l Managing users and authentication on page 61

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

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.

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.”
Address Number of Asset

Network segment Location
space assets function
Building 1:
New York Sales 10.1.0.0/22 254 Work stations
Floors 1-3
New York Building 2: Work stations
10.1.10.0/23 50
IT/Administration Floor 2 Servers
New York printers 10.1.20.0/24 56 Buildings 1 & 2 Printers
Co-location Web server
New York DMZ 172.16.0.0/22 30
facility Mail server
Building 3:
Madrid sales 10.2.0.0/22 65 Work stations
Floor 1
Building 3: Work stations
Madrid development 10.2.10.0/23 130
Floors 2 & 3 Servers
Building 3:
Madrid printers 10.2.20.0/24 35 Printers
Floors 1-3
Building 3:
Madrid DMZ 172.16.10.0/24 15 File server
dark room
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 user’s guide for information on
setting up sites and scans.

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 company’s 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
organization’s 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 user’s 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).

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 user’s guide.)
l 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 user’s guide.)
l 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
user’s guide.)
l Web interface tools for tracking and overriding policy test results (see the chapter Working
with data from scans in the user’s guide.)
l XML and CSV reports for disseminating policy test result data. (See Creating a basic report in
the user’s guide.)
l 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.

What are your goals beyond compliance?
Compliance goals may help you to define your deployment strategy, but it’s 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 secure—not 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? Who’s 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.

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 IP address
l host name
l MAC address
l vulnerabilities
l risk score
l user-applied tags
l site membership
l 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 IP address 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, IP address, 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 I want 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

l Link matching assets across sites. Assets are considered matching if they have certain
characteristics in common, such as host name, IP address, 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.
l 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.
l 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 asset’s 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.
l 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 I want 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
IP address 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.
l 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 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.
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.

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-to-
date 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
hacker’s 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 available—hosted 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 don’t 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.

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, it’s 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.

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

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 ACL-
protected 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 user’s 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-party-
hosted 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.

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

Setting up the application and getting started
Once you’ve mapped out your Scan Engine deployment, you’re more than halfway to planning
your installation. The next step is to decide how you want to install the main components—the
Security Console and Scan Engines.
Understanding deployment options
Nexpose components are available in two versions. The hardware/software Appliance is a plug-
and-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 Appliance—include running
the application as a just a Scan Engine or as a Security Console and Scan Engine.
Installation scenarios—which 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

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
Console’s 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 user’s guide.
A deployment plan for Example, Inc.
Let’s return to the environment table for Example, Inc.
No. of
Network segment Address space Location Asset function
assets
Building 1:
New York Sales 10.1.0.0/22 254 Work stations
Floors 1-3
New York IT/Administration 10.1.10.0/23 50
Floor 2 Servers
New York printers 10.1.20.0/24 56 Buildings 1 & 2 Printers
Web server
New York DMZ 172.16.0.0/22 30 Co-location facility
Mail server
Building 3:
Madrid sales 10.2.0.0/22 65 Work stations
Floor 1
Madrid development 10.2.10.0/23 130
Floors 2 & 3 Servers
Building 3:
Madrid printers 10.2.20.0/24 35 Printers
Floors 1-3
Building 3:
Madrid DMZ 172.16.10.0/24 15 File server
dark room

A best-practices deployment plan might look like this:
The eight groups collectively contain a total of 635 assets. Example, Inc., could purchase a fixed-
number 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
l Building 2
l Building 3
l 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, it’s 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

Your deployment checklist
When you are ready to install, configure, and run Nexpose, it’s 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
l log onto the Security Console Web interface
l configure Scan Engines, and pair them with the Security Console
l perform vAsset discovery, if your license enables it
l create one or more sites
l assign each site to a Scan Engine
l select a scan template for each site
l schedule scans
l create user accounts, and assign site-related roles and permissions to these accounts
l run scans
l configure and run reports
l create asset groups to view reports and asset data
l create user accounts, and assign asset-group-related roles and permissions to these
accounts
l assign remediation tickets to users
l re-run scans to verify remediation
l perform maintenance tasks
Planning for capacity requirements
If you’re 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.

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.

Typical scan duration and disk usage for unauthenticated scanning
Open Disk
Open UDP Discovered Scan duration
Asset Type TCP usage
ports vulnerabilities (mins)
ports (KB)
Windows XP Pro SP3 3 2 4 32 1
Windows 7 Pro SP1 10 1 6 28 1
Windows 2008 R2
48 3 8 100 10
w/Exchange
Mac OSX 10.6 7 2 28 516 1
RedHat Enterprise
1 0 3 24 1
Linux 6 WS
ESXi 5 Hypervisor 8 0 4 108 6
Cisco IOS 12.3 1 2 25 64 6
Average 125 4
Typical scan duration and disk usage for authenticated scanning
Disk Scan
Total open Total open Discovered
Asset Type usage duration
TCP ports UDP ports vulnerabilities
(KB) (mins)
Windows XP Pro
3 2 18 296 4
SP3
Windows 7 Pro
10 1 256 332 3
SP1
Windows 2008 R2
48 3 177 628 14
w/Exchange
Mac OSX 10.6 7 2 456 1052 5
RedHat Enterprise
1 0 123 320 2
Linux 6 WS
ESXi 5 Hypervisor 8 0 6 136 8
Cisco IOS 12.3 1 2 25 64 6
Average 404 6
Typical scan duration and disk usage for unauthenticated scanning 48

Disk usage for reporting on unauthenticated scans
Disk Usage Disk Usage for

Disk Usage for
for PCI Disk Usage for
CSV Export
Asset Type Remediation Vulnerability XML Export 2.0
Report of all
Plan PDF Details PDF Report (KB)
fields (KB)
Report (KB) Report (KB)
Windows XP Pro SP3 10 73 31 25
Windows 7 Pro SP1 8 73 28 20
Windows 2008 R2
14 129 64 32
w/Exchange
Mac OSX 10.6 15 189 89 63
RedHat Enterprise Linux 6
9 72 28 21
WS
ESXi 5 Hypervisor 12 95 49 37
Cisco IOS 12.3 13 190 104 75
Average 12 117 56 39
Disk usage for reporting on authenticated scans
Disk Usage Disk Usage for

Disk Usage for
for PCI Disk Usage for
CSV Export
Asset Type Remediation Vulnerability XML Export 2.0
Report of all
Plan PDF Details PDF Report (KB)
fields (KB)
Report (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
165 4,462 4,104 3,054
w/Exchange
Mac OSX 10.6 38 1,821 901 642
RedHat Enterprise Linux 6
115 1,726 2,314 1,708
WS
ESXi 5 Hypervisor 13 101 51 38
Cisco IOS 12.3 13 190 104 75
Average 66 1,493 1,288 951
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.
Vulnerabilities
Scan settings Disk usage (KB) Scan duration (mins)
discovered
Full Audit, Web Spider off,
41 224 13
unauthenticated scan
66 3128 13
authenticated scan
Full Audit, Web Spider on,
112 3596 19
authenticated scan
41 224 13
unauthenticated scan

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

l Include query strings when spidering = NO
l Check use of common user names and passwords = NO
l Maximum number of foreign hosts to resolve = 100
l Spider request delay (ms) = 20
l Maximum directory levels to spider = 6
l No spidering time limit
l Spider threads per Web server = 3
l 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
l 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.

Single-asset policy scan duration and disk usage
By incorporating Policy Manager checks into your scans, you can verify compliance with industry-
standard 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.
Disk space consumed

Asset type and benchmark tested Scan time
(KB)
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

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
K Disk usage by one scan of one asset
L Disk usage of one report for one scan of one asset
M 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
Disk usage for scanning –
Asset type Percentage scanning –
authenticated (KB)
unauthenticated (KB)
RedHat Enterprise Linux
10% 24 320
6 WS
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
Value of K (average disk usage
83 421
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:
Disk usage for

Disk usage for scanning –
Asset type Percentage scanning –
authenticated (KB)
unauthenticated (KB)
RedHat Enterprise Linux
10% 30 1,823
6 WS
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
Value of K (average disk usage
36 KB 1,311 KB
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)

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)

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?

l How long will it take me to scan X assets with N engines?
l 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 

 
=
1.2 x Avg .ScanTime (in minutes )x No.OfAssets
No .OfScanThreads {For 1 Scan Engine }
=
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

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:
1.2 x Avg .ScanTimePerAsset (in minutes ) x No .OfAssets

Total Engines =
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.

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

l Scenario 2: Two sites, unauthenticated scan, 20 threads configured for each site, 20 ports
scanned for each site
l 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:

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 user’s 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

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.

Managing users and authentication
Effective use of scan information depends on how your organization analyzes and distributes it,
who gets to see it, and for what reason. Managing access to information in the application
involves creating asset groups and assigning roles and permissions to users. This chapter
provides best practices and instructions for managing users, roles, and permissions.
Mapping roles to your organization
It is helpful to study how roles and permissions map to your organizational structure.
Note: A user authentication system is included. However, if your organization already uses an
authentication service that incorporates Microsoft Active Directory or Kerberos, it is a best
practice to integrate the application with this service. Using one service prevents having to
manage two sets of user information.
In a smaller company, one person may handle all security tasks. He or she will be a Global
Administrator, initiating scans, reviewing reports, and performing remediation. Or there may be a
small team of people sharing access privileges for the entire system. In either of these cases, it is
unnecessary to create multiple roles, because all network assets can be included in one site,
requiring a single Scan Engine.
Example, Inc. is a larger company. It has a wider, more complex network, spanning multiple
physical locations and IP address segments. Each segment has its own dedicated support team
managing security for that segment alone.
One or two global administrators are in charge of creating user accounts, maintaining the
system, and generating high-level, executive reports on all company assets. They create sites for
different segments of the network. They assign security managers, site administrators, and
system administrators to run scans and distribute reports for these sites.
The Global Administrators also create various asset groups. Some will be focused on small
subsets of assets. Non-administrative users in these groups will be in charge of remediating
vulnerabilities and then generating reports after follow-up scans are run to verify that remediation
was successful. Other asset groups will be more global, but less granular, in scope. The non-
administrative users in these groups will be senior managers who view the executive reports to
track progress in the company's vulnerability management program.
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.

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

Create, delete, and configure all attributes of sites, except
for user access. Implicitly have access to all sites. Manage
Global
Manage Sites shared scan credentials. Other affected permissions:
Administrator
When you select this permission, all site permissions
automatically become selected. See Site permissions.
Manage Scan Create, delete, and configure all attributes of scan Global
Templates templates. Administrator
Global
Administrator,
Manage Report Create, delete, and configure all attributes of report Security Manager
Templates templates. and Site Owner,
Asset Owner,
User
Manage Scan Create, delete, and configure all attributes of Scan Global
Engines Engines; pair Scan Engines with the Security Console. Administrator
Global
Manage Policies Copy existing policies; edit and delete custom policies.
Administrator
Appear on user lists in order to be assigned remediation Global
tickets and view reports. Administrator,
Appear on Ticket Security Manager
and Report Lists Prerequisite: A user with this permission must also have and Site Owner,
asset viewing permission in any relevant site or asset Asset Owner,
group: View Site Asset Data; View Group Asset Data User
Configure settings that are applied throughout the entire
Configure Global Global
environment, such as risk scoring and exclusion of assets
Settings Administrator
from all scans.
Create tags and configure their attributes. Delete tags
Global
Manage Tags except for built-in criticality tags. Implicitly have access to
Administrator
all sites.

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

Global Administrator,
View discovered information about all
Security Manager and Site
View Site Asset assets in accessible sites, including IP
Owner,
Data addresses, installed software, and
Asset Owner,
vulnerabilities.
User
Enter site descriptions, importance Global Administrator,
Specify Site
ratings, and organization data. Security Manager and Site
Metadata
Owner
Specify Scan Add or remove IP addresses, address Global Administrator
Targets ranges, and host names for site scans.
Assign Scan Engine Assign a Scan Engine to sites. Global Administrator
Assign a scan template to sites. Global Administrator,

Assign Scan
Template
Owner
Create, delete, and configure all Global Administrator,
Manage Scan Alerts attributes of alerts to notify users about Security Manager and Site
scan-related events. Owner
Provide logon credentials for deeper Global Administrator,

Manage Site
scanning capability on password- Security Manager and Site
Credentials
protected assets. Owner
Global Administrator,
Schedule Automatic Create and edit site scan schedules.
Scans
Owner
Manually start one-off scans of Global Administrator, Security
Start Unscheduled
accessible sites (does not include ability Manager and Site Owner, Asset
Scans
to configure scan settings). Owner
Manually remove asset data from

accessible sites.
Purge Site Asset
Prerequisites: A user with this Global Administrator
Data
permission must also have one of the
following permissions: View Site Asset
Data; View Group Asset Data
Manage Site Access Grant and remove user access to sites. Global Administrator

Asset Group permissions
These permissions only apply to asset groups to which a user has been granted access.
Manage Create dynamic asset groups. Delete and configure all attributes
Dynamic of accessible dynamic asset groups except for user access.
Asset Implicitly have access to all sites. Global
Groups Administrator
Note: A user with this permission has the ability to view all asset
data in your organization.
Manage Create static asset groups. Delete and configure all attributes of
Static accessible static asset groups except for user access.
Asset Global
Groups 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
View View discovered information about all assets in accessible asset Global
Group groups, including IP addresses, installed software, and Administrator ,
Asset vulnerabilities. Security
Data Manager and
Site Owner,
Asset Owner,
User
Manage Add and remove assets in static asset groups.
Group
Assets Note: This permission does not include ability to delete Global
underlying asset definitions or discovered asset data. Administrator
Prerequisite: A user with this permission must also have of the
following permission: View Group Asset Data
Manage Grant and remove user access to asset groups.

Asset Global
Group Administrator
Access

Report permissions
The Create Reports permission only applies to assets to which a user has been granted access.
Other report permissions are not subject to any kind of access.
Create Create and own reports for accessible assets; configure Global Administrator ,
Reports all attributes of owned reports, except for user access. 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
Use Create report templates with restricted sections;
Restricted configure reports to use templates with restricted
Report sections.
Sections Global Administrator
Prerequisites: A user with this permission must also have
one of the following permissions: Manage Report
Templates
Manage Grant and remove user access to owned reports.
Report Global Administrator
Access
Ticket permissions
These permissions only apply to assets to which a user has been granted access.
Create Create tickets for vulnerability remediation tasks. Global Administrator ,

Tickets Security Manager and
Prerequisites: A user with this permission must also have Site Owner,
one of the following permissions: View Site Asset Asset Owner,
Data; View Group Asset Data User
Close Close or delete tickets for vulnerability remediation tasks. Global Administrator ,
Tickets Security Manager and
Prerequisites: A user with this permission must also have Site Owner,
one of the following permissions:View Site Asset Asset Owner,
Vulnerability exception permissions
These permissions only apply to sites or asset groups to which a user has been granted access.

Submit Submit requests to exclude vulnerabilities from reports. Global Administrator ,

Vulnerability Security Manager and
Exceptions Prerequisites: A user with this permission must also Site Owner,
have one of the following permissions: View Site Asset Asset Owner,
Review Approve or reject requests to exclude vulnerabilities

Vulnerability from reports.
Exceptions Global Administrator
Prerequisites: A user with this permission must also
have one of the following permissions: View Site Asset
Delete Delete vulnerability exceptions and exception requests.
Vulnerability
Exceptions Prerequisites: A user with this permission must also Global Administrator
have one of the following permissions: View Site Asset
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.

l Manage vConnections and vAsset discovery.
l Manage configuration, maintenance, and diagnostic routines for the Security Console.
l Manage shared scan credentials.

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

l Appear on Ticket and Report Lists
l View Site Asset Data
l Specify Site Metadata
l Assign Scan Template
l Manage Scan Alerts
l Manage Site Credentials
l Schedule Automatic Scans
l Start Unscheduled Scans
l View Group Asset Data (Security Manager only)
l Create Reports
l Create Tickets
The only distinction between these two roles is the Security Manager’s ability to work in
accessible sites and assets groups. The Site Owner role, on the other hand, is confined to sites.
Asset Owner
The Asset Owner role includes the following permissions in accessible sites and asset groups:

l Appear on Ticket and Report Lists
l Start Unscheduled Scans
l View Group Asset Data
l Create Reports

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

l Manage Policies
l View Group Asset Data (Security Manager only)
l Create Reports
l Create Tickets
ControlsInsight User
This role provides complete access to ControlsInsight with no access to Nexpose.
Managing and creating user accounts
The Users links on the Administration page provide access to pages for creating and managing
user accounts. Click manage next to Users to view the Users page. On this page, you can view a
list of all accounts within your organization. The last logon date and time is displayed for each
account, giving you the ability to monitor usage and delete accounts that are no longer in use.
To edit a user account:
1. Click Edit for any listed account, and change its attributes.
The application displays the User Configuration panel. The process for editing an account is
the same as the process for creating a new user account. See Configure general user
account attributes on page 70.

To delete an account and reassign tickets or reports:
1. Click Delete for the account you want to remove.
A dialog box appears asking you to confirm that you want to delete the account.
2. Click Yes to delete the account.
If that account has been used to create a report, or if that account has been assigned a
ticket, the application displays a dialog box prompting you to reassign or delete the report
or ticket in question. You can choose delete a report or a ticket that concerns a closed issue
or an old report that contains out-of-date information.
3. Select an account from the drop-down list to reassign tickets and reports to.
4. (Optional) Click Delete tickets and reports to remove these items from the database.
5. Click OK to complete the reassignment or deletion.
Configure general user account attributes
You can specify attributes for general user accounts on the User Configuration panel.
To configure user account attributes:
1. Click New User on the Users page.

2. (Optional) Click Create next to Users on the Administration page. The Security Console
displays the General page of the User Configuration panel.
3. Enter all requested user information in the text fields.
4. (Optional) Select the appropriate source from the drop-down list to authenticate the user with
external sources.
Before you can create externally authenticated user accounts you must define external
authentication sources. See Using external sources for user authentication on page 72.
5. Check the Account enabled check box.
You can later disable the account without deleting it by clicking the check box again to
remove the check mark.
6. Click Save to save the new user information.

Assign a role and permissions to a user
Assigning a role and permissions to a new user allows you to control that user’s access to
Security Console functions.
To assign a role and permissions to a new user:
1. Go to the Roles page.

2. Choose a role from the drop-down list.
When you select a role, the Security Console displays a brief description of that role.
If you choose one of the five default roles, the Security Console automatically selects the
appropriate check boxes for that role.
If you choose Custom Role, select the check box for each permission that you wish to
grant the user.
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.

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.
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.
l 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:
l 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.
l Datastore lists standard user accounts, which are created by a global administrator.

Before you can create externally authenticated user accounts you must define external
authentication sources.
To define external authentication sources:
1. Go to the Authentication page in the Security Console Configuration panel.

2. Click Add... in the area labelled LDAP/AD authentication sources to add an LDAP/Active
Directory authentication source
The Security Console displays a box labeled LDAP/AD Configuration.
3. Click the check box labeled Enable authentication source.

4. Enter the name, address or fully qualified domain name, and port of the LDAP server that you
wish to use for authentication.
Note: It is recommended that you enter a fully qualified domain name in all capital
letters for the LDAP server configuration. Example: SERVER.DOMAIN.EXAMPLE.COM
Default LDAP port numbers are 389 or 636, the latter being for SSL. Default port numbers
for Microsoft AD with Global Catalog are 3268 or 3269, the latter being for SSL.
5. (Optional) Select the appropriate check box to require secure connections over SSL.
6. (Optional) Specify permitted authentication methods, enter them in the appropriate text field.
Separate multiple methods with commas (,), semicolons (;), or spaces.
Note: It is not recommended that you use PLAIN for non-SSL LDAP connections.
Simple Authentication and Security Layer (SASL) authentication methods for permitting
LDAP user authentication are defined by the Internet Engineering Task Force in document
RFC 2222 (http://www.ietf.org/rfc/rfc2222.txt). The application supports the use of GSSAPI,
CRAM-MD5, DIGEST-MD5, SIMPLE, and PLAIN methods.
7. Click the checkbox labeled Follow LDAP referrals if desired.
As the application attempts to authenticate a user, it queries the target LDAP server. The
LDAP and AD directories on this server may contain information about other directory
servers capable of handling requests for contexts that are not defined in the target directory.
If so, the target server will return a referral message to the application, which can then
contact these additional LDAP servers. For information on LDAP referrals, see the
document LDAPv3 RFC 2251 (http://www.ietf.org/rfc/rfc2251.txt).
8. Enter the base context for performing an LDAP search if desired. You can initiate LDAP
searches at many different levels within the directory.

To force the application to search within a specific part of the tree, specify a search base,
such as CN=sales,DC=acme,DC=com.
9. Click one of the three buttons for LDAP attributes mappings, which control how LDAP
attribute names equate, or map, to attribute names.
Your attribute mapping selection will affect which default values appear in the three fields
below. For example, the LDAP attribute Login ID maps to the user’s login ID. If you select
AD mappings, the default value is sAMAccountName. If you select AD Global Catalog
mappings, the default value is userPrincipalName. If you select Common LDAP mappings,
the default value is uid.
10. Click Save.
The Security Console displays the Authentication page with the LDAP/AD authentication
source listed.
To add a Kerberos authentication source:
1. Click Add... in the area of the Authentication page labeled Kerberos Authentication sources.
The Security Console displays a box labeled Kerberos Realm Configuration.
2. Click the checkbox labeled Enable authentication source.

3. Click the appropriate checkbox to set the new realm that you are defining as the default
Kerberos realm.
The Security Console displays a warning that the default realm cannot be disabled.
4. Enter the name of the realm in the appropriate text field.

5. Enter the name of the key distribution center in the appropriate field.
6. Select the check box for every encryption type that your authentication source supports.
During authentication, the source runs through each type, attempting to decrypt the client’s
credentials, until it uses a type that is identical to the type used by the client.
7. Click Save.
The Security Console displays the Authentication page with the new Kerberos distribution
center listed.
Once you have defined external authentication sources, you can create accounts for users
who are authenticated through these sources.
8. Click the Administration tab on the Home page.

9. Click Create next to Users on the Administration page,
The Security Console displays the User Configuration panel.

On the General page, the Authentication method drop-down list contains the
authentication sources that you defined in the Security Console configuration file.
10. Select an authentication source.
Note: If you log on to the interface as a user with external authentication, and then click
your user name link at the top right corner of any page, the Security Console displays your
account information, including your password; however, if you change the password on
this page, the application will not implement the change.
The built-in user store authentication is represented by the Nexpose user option.
The Active Directory option indicates the LDAP authentication source that you specified in
the Security Console configuration file.
If you select an external authentication source, the application disables the password fields.
It does not support the ability to change the passwords of users authenticated by external
sources.
11. Fill in all other fields on the General page.

12. Click Save.
Manually setting Kerberos encryption types
If you are authenticating users with Kerberos, you can increase security for connections to the
Kerberos source, by specifying the types of ticket encryptions that can be used in these
connections. To do so, take the following steps:
1. Using a text editor, create a new text file named kerberos.properties.

2. Add a line that specifies one or more acceptable encryption types. For multiple types,
separate each types with a character space:
default_tkt_enctypes=<encryption_type encryption_type>

You can specify any of the following ticket encryption types:
l des-cbc-md5
l des-cbc-crc
l des3-cbc-sha1
l rc4-hmac
l arcfour-hmac
l arcfour-hmac-md5
l aes128-cts-hmac-sha1-96
l aes256-cts-hmac-sha1-96
Example:
default_tkt_enctypes= aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
3. Save the file in the installation_directory/nsc/conf directory.
The changes are applied at the next startup.
Setting a password policy
Global Administrators can customize the password policy in your Nexpose installation. One
reason to do so is to configure it to correspond with your organization's particular password
standards.
Note: When you update a password policy, it will take effect for new users and when existing
users change their passwords. Existing users will not be forced to change their passwords.
To customize a password policy:
1. In the Security Console, go to the Administration page.

2. Select password policy.

Navigating to the password policy configuration
3. Change the policy name.

4. Select the desired parameters for the password requirements.
Note: If you do not want to enforce a maximum length, set the maximum length to 0.

Example: This policy is named Test Policy and enforces a minimum length of 8 characters, maximum length of 24 characters,
at least one capital leter, at least one numeric value, and at least one special character.
5. Click Save.
Once the password policy is set, it will be enforced on the User Configuration page.
As a new password is typed in, the items on the list of requirements turn from red to green as the
password requirements are met.
As a user types a new password, the requirements on the list change from red to green as they are fulfilled.

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

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

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

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

5. Click Create New Certificate.
The Security Console displays a box for new certificate information.
6. Enter the information and click Create.
Manage Certificate–Create New Certificate
A dialog box appears indicating that a new self-signed certificate was created.
7. Click Create CSR now.
You can click Later to 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 Certificate on the Manage Certificate dialog after it is signed by your CA.
10. Paste it in the text box and click Import.

Manage Certificate–Import 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
Configuration panel. See the following sections:
l Configuring Security Console connections with distributed Scan Engines on page 84

l Managing the Security Console on page 81
l 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

l The Connection timeout setting controls how long the Security Console waits for the creation
of a connection with a distributed Scan Engine.
l The Response timeout setting 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 Engines page in the Security Console Configuration panel.

3. On the Administration page, click manage for the Security Console.
4. Click Scan Engines in 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:

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.

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:

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.

You can also hover the cursor over the arrow to view the current status of the communication.
The possible options are:
l Green – Active
l 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.
l 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.
l 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

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 Engines page in the Security Console Configuration panel.

3. Click manage for 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.

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 application’s 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

l Starting and monitoring the migration on page 93
l Verifying the success of the migration on page 95
l 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

prevent the need to restore an earlier version of the database. See Backing up the post-
migration database on page 96.
This document also provides instructions for optional post-migration tasks:
l restoring backups
l 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.

l 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.
l 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 won’t 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:
l 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.
l 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 Migration button is disabled if you do not have enough disk space to
perform the migration. However, in some environments, the Start Migration button may be
enabled but disk space issues may still occur during migration. For example, see the section

about Linux file systems. To free up disk space, try the solutions listed in the following sequence.
Check if the Start Migration button 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

l cleaning up the database
l 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

l reports directory—[installation_directory]/nsc/htroot/reports
l access log directory, including the Tomcat log subdirectory—[installation_directory]/nsc/logs
l scan event data files directory—[installation_directory]/nse/scans
l Security Console logs—[installation_directory]/nsc/*.log and /nsc/*.log*
l PostgreSQL log—[installation_directory]/nsc/nxpsql/nxpgsql.log
l 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.

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 don’t 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:

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 Migration if 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 you’re 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.

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

Verifying the success of the migration
To verify migration success, take the following steps:

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.

To verify database consistency and respond appropriately:

2. Click Diagnose.
The Security Console displays the Troubleshooting page.
3. Select only the Database Diagnostics check box.

4. Click Perform Diagnostics.
A table appears on the page, listing the results of all diagnostic tests. Red circles containing
the letter X indicate consistency issues.

6. Click Maintenance.
The Security Console displays the Database Maintenance page.
7. (Optional) Select the Clean up Database task 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 post-
migration 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

l verifying the success of the migration
l ensuring database consistency

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.

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.
l (Optional) In Windows, right-click the icon for the disk and then click Properties from the pop-
up menu. Read the amount of available disk space.
l (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.
l 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.
l 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.

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.html upon 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:

2. On the Administration page, 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
l s3.amazonaws.com
l s3-external-1.amazonaws.com
l 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.

l To learn more about this feature and activation, please visit http://www.rapid7.com/nexpose-
now.
If the above conditions are met, and you are a Global Administrator, you will have the option to
enable dashboard functionality. To do so:

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.

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.

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.

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.

l You must be a Global Administrator for your Nexpose installation.
l To learn more about this feature and activation, please visit http://www.rapid7.com/nexpose-
now.
To enable 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 Use Exposure Analytics.

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.

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.

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.

l Find assets that belong to your organization that you may not have been tracking.
l Get a snapshot of your public facing assets.
l 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 by Connection table on the Assets page.

To set up a Sonar query:

3. Click on the Sonar connection.
4. On the Sonar Queries page, click the New Sonar Query button.

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 from Project 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'

l 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 from Project Sonar 112

l 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.
l 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 by Connection 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:
4. Click the Clear All Sonar Assets button.
When you go to the Discovered by Connection 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:
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 application’s file system.

l Restore an installation from a prior backup already on the application’s file system.
l 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
l configuration files (nsc.xml, nse.xml, userdb.xml, and consoles.xml)
l licenses
l keystores
l report images
l custom report templates
l custom scan templates
l generated reports
l custom risk strategies
l custom SCAP data
l scan logs
Database backup/restore and data retention 116

Performing a backup
To perform a backup, take the following steps:
1. Go to the Maintenance—Backup/Restore page, which you can access from the

Maintenance link on the Administration page.
The Backup/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 you’re 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 Maintenance—Backup/Restore page, 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:

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.

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:

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.

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 Maintenance—Backup/Restore page, which you can access from the

Maintenance link 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 File in 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 organization’s 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 re-
apply 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:

2. Click Maintenance.
3. Go to the Database Maintenance page and select any of the following options:
Performing database maintenance 124

l Clean up Database removes leftover data that is associated with deleted objects such as
sites, assets, or users.
l Compress Database tables frees up unused table space.
l Reindex Database rebuilds 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 Console’s 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:

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 a data retention policy

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 Manage settings 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 General page 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 Activation area displays general information about your license.
l If your license is active, you will see a link for contacting Rapid7 to modify your license, which
is optional.
l 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.

The Licensing page 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.

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

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 license details
In the License Details area of the Licensing page, you can see more information about your
license:
l The value for License Status is one of four different modes, depending on the status of your
license.
l The value for Expiration is the date that your current license expires.
l The value for Max. Scan Engines is the total number of internal Scan Engines that you can
use. These Scan Engines can be installed on any host computers on your network.
l The value for Max. Assets to Scan is the total number of assets that you can scan with your
internal Scan Engines.
l The value for Max. Assets to Scan w/ Hosted Engine is the total number of assets that you can
scan with a Hosted Scan Engine.
l If the value for SCADA Scanning is 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.
l If the value for Discovery Scanning is Enabled, you can run discovery scans to determine
what assets are available on your network without performing vulnerability checks on those
assets.
l If the value for PCI Reporting is 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.
l If the value for Web Application Scanning is 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.
l If the value for Policy Scanning is 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.

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 as-
needed 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:

2. Click managenext to Security Console.

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 updates to 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.
3. Select Updates from the left navigation pane.

4. Select the Enable automatic product updates check 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.

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.
The Security Console Configuration screen appears.
3. Select Updatesfrom the left navigation pane.
Current available updates appear on the Updatespage.
4. Click Manual Update to 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.
The Security Console Configuration screen appears.
3. Select Updatesfrom the left navigation pane.
The Updatespage appears.

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:
The Administration page appears.
2. On the Administration page, click the Manage link for Security Console.

3. Go to the Proxy Settings page.
4. Enter the information for the proxy server in the appropriate fields:
l The Name or address field is set to updates.rapid.7.com by 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 Port field is set to 80 by 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.
l The Response timeout field 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.
l 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.

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.

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
l Windows 64 installer

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.

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

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 system’s 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

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

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 help to 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.
2. Click the link to Run console commands, which is displayed with the Troubleshooting item.
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
Appliance’s 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.

Command Action
activate Activate the application with a product key.
Check the database for inconsistencies, such as partially deleted sites or missing
database
synopsis data, which can affect counts of assets, sites, asset groups, scans, or
diagnostics
nodes as displayed in the Web interface.
[show] diag
Display diagnostic information about the Security Console.
[nostics]
exit Stop the Security Console service.
Start the garbage collector, a Java application that frees up drive space no longer
garbagecollect
used to store data objects.
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 property without a parameter name, the
get property
Security Console will list all properties and associated values. You can view and set
[<name>]
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.
“Dump” or list all the data and memory addresses “piled up” by the Java garbage
heap dump
collector. The dump file is saved as heap.hprof in the nsc directory.
help Display all available commands.
E-mail a request for a new license. The email-address parameter is your address
license as the requestor. The optional mail-relay-server parameter designates an
request from- internally accessible mail server to which the license server should connect to send
email-address the e-mail. After you execute this command, the application displays a message
[mail-relay- that the e-mail has been sent. When you receive the license file, store it in the
server] nsc/licenses directory 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
Ping the specified host using an ICNMP ECHO request, ICP ACK packet, and
host-address
TCP SYN packet. The default TCP port is 80.
[tcp-port]
quit Stop the Security Console service.
restart Stop the Security Console service and then start it again.
[show] Display the currently scheduled jobs for scans, auto-update retriever, temporal risk
schedule score updater, and log rotation.
Display information about the Security Console host, including its name, address,
hardware configuration, and Java Virtual Machine (JVM) version. The command
show host
also returns a summary of disk space used by the installation with respect to the
database, scans, reports, and backups.

Command Action
Display information about all licenses currently in use. Multiple licenses may
show licenses
operate at once.
show locked List all user accounts locked out by the Security Console. The application can lock
accounts out a user who attempts too many logons with an incorrect password.
show mem List statistics about memory use.
Send logs generated by the Security Console and Scan Engine(s) for
[send] support
troubleshooting support. By default, the application sends the request to a log
[from-email-
server via HTTPS. Alternatively, you can e-mail the request by specifying a
address] [mail-
sender's e-mail address or outbound mail relay server. You also can type a brief
relay-server]
message with the e-mail request. When you execute the command, the Security
[message-
Console displays a scrolling list of log data, including scheduled scans, auto-
body]
updates, and diagnostics.
[show] threads Display the list of active threads in use.
Determine the IP address route between your local host and the host name or IP
traceroute address that you specify in the command. When you execute this command, the
host-address Security Console displays a list of IP addresses for all “stops” or devices on the
given route.
unlock
account Unlock the user account named in the command.
<name>
update
Send pending updates to all defined Scan Engines.
engines
Check for and apply updates manually and immediately, instead of waiting for the
update now
Security Console to automatically retrieve the next update.
Display the current software version, serial number, most recent update, and other
information about the Security Console and local Scan Engine. Add “console” to
[ver] version 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.

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.
l 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_log in earlier product versions.
l 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.
l 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.
l 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 the Security Console’s failure
execution of system processes and can prevent to connect to the database
user operations, such as scanning
WARN an abnormal event that prevents successful disruption in communication
execution of system processes but does not between the Security Console
completely prevent a user operation, such as and a remote Scan Engine
scanning
INFO a normal, expected event that is noteworthy for the Security Console’s
providing useful information about system activity attempts to establish a
connection with a remote Scan
Engine
DEBUG a normal, expected event that need not be viewed the execution of operations
except for debugging purposes 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

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, default refers 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: :

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 default unchanged. Otherwise,
change the value to one of the following to specify a different log file:
l auth
l access
l 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.

Sending logs to Technical Support
You can transmit logs generated by Scan Engines to Technical Support by clicking Send Logs on
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 Logs on 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 Rapid7 DMZ, 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:
The Administration page appears.
2. On the Administration page, click the Manage link for the Security Console.
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 address field refers to the fully qualified domain name or IP address of
the proxy server.

l The Port field is for the number of the port on the proxy server that the Security Console
contacts when sending log files.
l 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

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-system-
fingerprint@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.

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 URL for the scan page.

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:

2. The Security Console displays the Administration page.
3. Click Diagnose next to Troubleshooting.
The Security Console displays the Troubleshooting page.
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 DBConfig task 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.
l 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.

l The Security Console has been disconnected from the Internet. Reconnect the Security
Console to the Internet.
l The user’s browser has been disconnected from the Internet. Reconnect the browser to the
Internet.
l 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 Console’s response to the user’s 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 Configuration—Web Server page. 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 you’re a global administrator, go to the Users page, and click the padlock icon that appears
next to the locked out user's name.
l Run the console command unlock account. " Using the command console" on page 144.
l 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 browser’s Back button 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 158 and 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.
l 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.

l 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.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 Administration tab 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 now in the text box and click Execute.

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.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 the update now command prompt to re-attempt the update manually. See
Interrupted update on page 161 and Viewing the scan log on page 158.

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.
l The Common Vulnerabilities and Exposures (CVE) standard prescribes how the product
should identify vulnerabilities, making it easier for security products to exchange vulnerability
data.
l The Common Vulnerability Scoring System (CVSS) is an open frame work for calculating
vulnerability risk scores.
l 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, Nexpose computes 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 models—depending on your configuration preference—to
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. Rapid7 is an
Approved Scanning Vendor (ASV); and Nexpose is 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 Details section lists highest risk vulnerabilities and
includes their categories, risk scores, and their CVSS scores. The Index of Vulnerabilities section
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
Nexpose tests assets for compliance with configuration policies. It displays the results of
compliance tests on the scan results page of every tested asset. The Policy Listing table 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 feature in the user’s
guide.
Where to find SCAP update information and OVAL files
Nexpose automatically 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
l CVE Data
l CVSS Data
l 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 XML-
structured 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 asset’s 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 it’s 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 policy’s 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 behind-
the-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
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
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 type—Text, PDF, RTF,
and HTML—are 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 doesn’t 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 systems’s 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
site’s 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 entity’s 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
organization’s 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 console’s 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

l types of vulnerability checks, including safe and unsafe
l Web application scanning properties
l 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 site’s 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

Nexpose Admin Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nexpose Admin Guide PDF

Uploaded by

Copyright:

Available Formats

Nexpose

About this guide 9

A note about documented features 9

Other documents and Help 9

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

Understanding key concepts 22

Define your goals 25

Linking assets across sites 31

What exactly is an "asset"? 32

Do I want to link assets across sites? 32

Enabling or disabling asset linking across sites 34

Ensuring complete coverage 36

Planning your Scan Engine deployment 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

Setting up a Sonar query 109

Filtering data from Project 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