SecurityCenter 4.4 Administration Guide

(1)

Copyright © 2002-2012 Tenable Network Security, Inc. Tenable Network Security, Nessus and ProfessionalFeed are registered trademarks of Tenable Network Security, Inc. Tenable, the Tenable logo, the Nessus logo, and/or other Tenable products referenced herein are trademarks of Tenable Network Security, Inc.,

SecurityCenter 4.4

Administration Guide

September 18, 2012

(Revision 3)

The newest version of this document is available at the following URL: http://static.tenable.com/prod_docs/SecurityCenter_4.4_Admin_Guide.pdf

(2)

Since many of Tenable’s customers have requirements to maintain separation of duties, the SecurityCenter 4.4 documentation has been separated into the following documents to better organize the material based on the organizational role. Note that there is some overlap in roles as well as content provided with each of the following guides:

>

SecurityCenter 4.4 Architecture – This document describes the SecurityCenter

architecture and provides a high-level view of how the components interact. This document is beneficial for those who are considering purchasing SecurityCenter.

>

SecurityCenter 4.4 Installation Guide – This document provides instructions for the

installation of SecurityCenter 4. The target audience for this document is system administrators who need to install the SecurityCenter application. Included in this

document are quick instructions for the admin user to add a Nessus scanner and create a user account to launch a test scan to ensure SecurityCenter is correctly installed.

>

SecurityCenter 4.4 Upgrade Guide – This document describes the process of

upgrading to the latest version of SecurityCenter 4.

>

SecurityCenter 4.4 Administration Guide – This document provides instructions for

the administration of SecurityCenter by the admin user. The admin user is the first user to log in to the SecurityCenter after the initial installation and is responsible for configuration tasks such as defining organizations, repositories, Nessus scanners, LCE servers, and PVS sensors. The admin user does not have the ability to create and launch Nessus scans.

>

SecurityCenter 4.4 User Guide – This document provides instructions for using

SecurityCenter by an Organization Head user or lesser account. Please email any comments and suggestions to [email protected].

A basic understanding of Linux/Unix, Windows, vulnerability scanning with Nessus, intrusion detection, computer hardware, and log analysis is assumed.

STANDARDS AND CONVENTIONS

Throughout the documentation, filenames, daemons, and executables are indicated with a courier bold font such as gunzip, httpd, and /etc/passwd.

Command line options and keywords are also indicated with the courier bold font.

Command line examples may or may not include the command line prompt and output text from the results of the command. Command line examples will display the command being run in courier bold to indicate what the user typed while the sample output generated by the system will be indicated in courier (not bold). Following is an example running of the Unix pwd command:

# pwd

/opt/sc4/daemons #

(7)

Important notes and considerations are highlighted with this symbol and grey text boxes.

Tips, examples, and best practices are highlighted with this symbol and white on blue text.

ABBREVIATIONS

The following abbreviations are used throughout this documentation: LCE Log Correlation Engine

PVS Passive Vulnerability Scanner

SC SecurityCenter

SSH Secure Shell

IDS Intrusion Detection System

S

ECURITY

C

ENTER

A

DMINISTRATOR

F

UNCTIONS

SecurityCenter administrators have the following responsibilities:

>

Manage the configuration of each SecurityCenter organization and which networks they

are allowed to scan

>

Manage scan policies, custom audit files, and credentials for all organizations

>

Manage the network of active Nessus scanners, the network “zones” they belong to and

the networks they are allowed to scan

>

Manage the network of Passive Vulnerability Scanners and what organizations have

access to their detected real-time vulnerabilities

>

Manage which Log Correlation Engines each organization has access to and what

repositories the LCE will correlate against

>

Delete accept and recast risk rules created by organizational users

>

Manage what external data feeds (ICAT, Snort, Nessus plugins, etc.) SecurityCenter is

subscribed to

>

Manage the SecurityCenter services

>

Add and manage other SecurityCenter administration users

>

Add and manage custom roles that are available to all organizations

>

Review SecurityCenter log files and job queues

Starting/Halting SecurityCenter

When SecurityCenter is installed and licensed, the required services are started by default. To display the status of SecurityCenter services, enter the following command as the root user on the SecurityCenter server:

# service SecurityCenter status

If SecurityCenter services are running, the following message will be displayed: SecurityCenter (httpd Jobd.php) is running...

(8)

Otherwise, the message will state “SecurityCenter is stopped”.

To start SecurityCenter, enter the following command: # service SecurityCenter start

To halt SecurityCenter, enter the following command: # service SecurityCenter stop

To restart SecurityCenter, enter the following command: # service SecurityCenter restart

SecurityCenter services can also be started and stopped from the admin web management interface. Simply click the status circle (the green circle in the lower right of the image below) in the lower right-hand corner of the web page. A pop-up similar to the one below is displayed:

If the system status is normal, the circle is green and the “Job Scheduler” indicator shows “Running”. Click “Stop” and then “Start” to restart the Job Scheduler process manually. If any problems exist with the SecurityCenter status, they will be displayed on this pop-up and in the logs described in the “Logs” section of this document.

SECURITYCENTER HOME PAGE/DASHBOARD

To navigate within the SecurityCenter user interface, use the menu on the web interface screen, not the browser’s back and forward arrow buttons.

Adobe Flash Player must be installed to use the SecurityCenter 4 web interface. It can be obtained at http://get.adobe.com/flashplayer/.

(9)

The minimum recommended browser window size is 1024x580. Resizing the browser window below this size when viewing the SecurityCenter web interface causes some items to display incorrectly.

To launch SecurityCenter, bring up a web browser on a system that has access to the SecurityCenter’s network address space and enter the URL in the following format: https://<SERVER ADDRESS OR NAME>/

The SecurityCenter web interface is available using a secure web connection (https). SecurityCenter 4 does not listen on port 80. TLS 1.0 must be enabled by the browser in order to complete the secure connection to SecurityCenter.

The dashboard is the first screen displayed when you log into the SecurityCenter user interface. It displays scanner, LCE, and plugin data through predefined components. The Dashboard can also be displayed by selecting “Dashboard” from the “Home” tab. There are two tabs: “Overview” and “LCE Overview”. The Overview tab contains a Scanner Status table, a Repository Statistics table and a table containing the latest plugin feed updates. The LCE Overview tab lists the current LCE server and client status (up to 1,000 clients displayed).

(10)

Sample SecurityCenter Administrator Dashboard – LCE Overview

SYSTEM CONFIGURATION

The “System” link at the top right of the SecurityCenter web interface contains a number of options to configure the desired SecurityCenter system behavior. When logged in as the admin user, additional options are available that are not available for non-admin users. Among the available admin options are “Basic” (licensing and activation), “Mail”, “LDAP”, “Expiration”, “Update”, and “Miscellaneous”. The sections below provide details about each of the categories and their configuration items.

C

ONFIGURATION

Basic

The “Basic” options allow the admin user to configure the licensing and activation code settings for SecurityCenter. The screen capture below shows a sample SecurityCenter Basic option configuration page:

For most installations, this page will not be modified by the administrator, except when a new or upgraded IP Count license or Nessus Activation Code has been purchased by the organization and needs to be added.

(11)

To view currently used IPs in your license, log into SecurityCenter as the “admin” user and go to “Repositories” -> “Repositories”. Hover the cursor over the “Total Active IPs” graphic at the bottom of the screen to view currently used IPs, total IP license count, and IPs remaining.

Offline repositories are not counted against your IP license count. Also, the following plugins are not counted against your license IP count:

Nessus IDs: 10180, 10287, 19506, 12053, 11933 PVS IDs: 00003, 00012

To add a new license, use the “Browse” button next to the “License” field to locate the license key file received in your email and then click “Submit”. Enter the Activation Code string in the Maintenance section and click the “Register” button. If an Activation Code already exists on SecurityCenter, click “Reset” to allow the new Activation Code to be entered.

The current license status is displayed in the “License Status” field and indicates the current license state, maximum IP count allowed by the current license, the hostname that the license applies to and the expiration date, if any.

Mail

The “Mail” option designates SMTP settings for all email related functions of SecurityCenter. Available options include SMTP host, port, authentication method, secure connection and return address. In addition, a “Test SMTP Settings” link is displayed in the upper right-hand corner of the page to confirm the validity of the settings.

The “Return Address” defaults to “noreply@localhost”. Use a valid return email address for this field. If this field is cleared or the email server requires emails from valid accounts, the email will not be sent by the email server.

(12)

LDAP

If LDAP authentication is to be used, it is recommended to leave at least one SecurityCenter administrator account and one manager account for each

organization in SecurityCenter set to use TNS authentication in the event that the LDAP services becomes unreachable.

LDAP configuration settings enable SecurityCenter to utilize any LDAP server for

authentication purposes. This enhances the security of SecurityCenter by facilitating “single sign-on” and password complexity requirements in environments where mandated by security policy. After clicking the “LDAP” tab, a page similar to the one below is displayed.

Fill out the LDAP configuration settings as provided by the LDAP server administrator and click “Test LDAP Settings”. If the settings are correct, a dialog will be displayed similar to the screen capture below indicating that the LDAP settings are valid.

If the LDAP settings are incorrect, the dialog box will indicate failure and provide details on why it failed (e.g., incorrect “Search Base” or “server could not be contacted”).

This table provides a detailed breakdown of the available LDAP parameters: Table 1 – LDAP Directory Information

(13)

Authentication

Use TLS This selection indicates if Transport Layer Security (TLS) is

enabled in the LDAP server.

Username If the LDAP server requires credentials to search for user

data, then the “Username” and “Password” fields are

required. By default, if an Active Directory server is used for LDAP queries, it requires an authenticated search. Enter the username within this field in the “email” style format

([email protected]).

Password (optional) If the LDAP server requires credentials to search for user data, then the “Username” and “Password” fields are required. By default, many LDAP servers require an authenticated search.

It is recommended to use passwords that meet stringent length and complexity requirements.

Server

Directory Server Enter the IP address or DNS name of the LDAP server in this field.

Port Specify the remote LDAP port here. When TLS is set to “no”,

the port will default to 389, and when TLS is set to “yes”, port 636 is automatically selected as these are the default ports used with LDAP.

Search Base This is the LDAP search base used as the starting point to

search for the user information.

Search String This string may be modified to create a search based on a

location or filter other than the default search base or attribute.

Attributes

Username Attribute This is the attribute name on the LDAP server that contains the username for the account. This is often specified by the string “sAMAccountName” in Active Directory servers that may be used by LDAP. Contact your local LDAP administrator for the correct username attribute to use.

Email Attribute This is the attribute name on the LDAP server that contains the email address for the account. This is often specified by the string “mail” in Active Directory servers that may be used by LDAP. Contact your local LDAP administrator for the correct email attribute to use.

(14)

Phone Attribute This is the attribute name on the LDAP server that contains the telephone number for the account. This is often specified by the string “telephoneNumber” in Active Directory servers that may be used by LDAP. Contact your local LDAP

administrator for the correct telephone attribute to use. Name Attribute This field is the attribute name on the LDAP server that

contains the name associated with the account. This is often specified by the string “CN” in Active Directory servers that may be used by LDAP. Contact your local LDAP administrator for the correct name attribute to use.

Access to Active Directory is performed via AD’s LDAP mode. When using multiple AD domains, LDAP access may be configured to go through the Global Catalog. Port 3268 is the default non-SSL/TLS setting, while port 3269 is used for SSL/TLS connections by default. More general information about LDAP searches via the Global Catalog may be found at:

http://technet.microsoft.com/en-us/library/cc728188(v=ws.10).aspx

Expiration

Data expiration determines how long SecurityCenter retains acquired data.

Use the table below to determine default and minimum values for these settings: Table 2 – Data Expiration

Option Description

Active Data SecurityCenter will automatically remove any vulnerability

data that was discovered via active scanning after the designated number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all active vulnerabilities indefinitely.

Passive Data By default, SecurityCenter will automatically remove any

passive vulnerability data that is older than seven days. If this field is left blank, the value will be set to zero (0). Setting this field to zero will retain all passive vulnerabilities

(15)

indefinitely.

Compliance Data SecurityCenter will automatically remove any compliance

data after the designated number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all compliance vulnerabilities indefinitely.

Mitigated Data Automatically remove any mitigated vulnerability data after

the designated number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all mitigated vulnerability data indefinitely.

Vulnerability Trending

Data Prior to SecurityCenter 4.2 the default was 365

days. Upgraded installations will maintain the 365 day default unless manually changed.

SecurityCenter will automatically remove any vulnerability trending data after the designated number of days. The default value of this field is 90. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all trend snapshots indefinitely.

Closed Tickets Automatically remove any closed tickets after the designated number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all closed tickets indefinitely.

Scan Results Automatically remove any scan results after the designated

number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all scan results indefinitely.

Report Results Automatically remove any report results after the designated number of days. The default value of this field is 365. If this field is left blank, the value is set to zero (0). Setting this field to zero will retain all report results indefinitely.

Update

The SecurityCenter update settings are used to determine the update schedule for the common tasks of Active and Passive plugin updates, IDS signature updates, and IDS correlation updates. All updates are configured daily by default.

(16)

The following settings are available: Table 3 – Update Schedules

Active Plugins Enables regular downloads of the Nessus plugins. These

plugins will be pushed out to every Nessus server that SecurityCenter is managing. Manual update of the Nessus plugins is also supported under the “Plugins” tab.

IDS Signatures Frequency to update SecurityCenter IDS signatures via

third-party sources. IDS Correlation

Databases Frequency to push vulnerability information to the LCE for correlation.

Passive Plugins Enables regular downloads of the PVS signatures. These

plugins will be pushed out to every PVS that SecurityCenter is managing. Manual update of the PVS plugins is also supported under the “Plugins” tab.

Each of the update schedule times may also be configured to occur by time in a particular time zone, which can be selected via the “Time Zone” link next to each hour selection.

Miscellaneous

Miscellaneous settings cover web proxy setup, syslog, and web authentication settings. A sample SecurityCenter screen capture is included below:

(17)

From this configuration page, a web proxy can be configured by entering the host URL (protocol, proxy host name, or IP address), port, username, and password. The host name used must resolve properly from the SecurityCenter host.

The “Syslog” section allows for the configuration and sending of SecurityCenter log events to the local syslog service. When “Enable Forwarding” is checked, the forwarding options are available for selection. The “Facility” drop-down provides the ability to select from the pre-defined facilities that will receive the log messages. The “Severities” section determines which level(s) of syslog messages will be sent: “Informational”, “Warning”, or “Critical”

The “Authentication Settings” apply to the SecurityCenter web interface login parameters. Use the table below to determine correct values for your environment:

Table 4 – SecurityCenter Authentication Settings

Session Timeout The web session timeout in minutes (default: 60 minutes).

Maximum Login Attempts

The maximum number of user login attempts allowed by SecurityCenter before the account is locked out (default: 20). Setting this value to zero disables this feature.

SecurityCenter

Location The URL used for emails originating from SecurityCenter with links back to SecurityCenter. This is useful in cases where a web proxy is in use.

(18)

Startup Banner Text Enter the text banner that is displayed prior to the login interface.

Header Text Adds custom text to the top of the SecurityCenter screen.

The text may be used to identify the company, group, clearance, or other organizational information. The field is limited to 128 characters.

DIAGNOSTICS

On the upper right-hand corner of the SecurityCenter web interface, the System option contains a drop-down that includes Diagnostics. This page displays and creates

information that assists in troubleshooting issues that may arise while using SecurityCenter.

In the “System Status” section, the following items are indicated by a green icon for a properly working status. A red icon is displayed when the item is in a critical state. Table 5 – System Status

Correct Java Version The icon is red when a minimal version of Java is not installed as required by certain SecurityCenter features.

(19)

Sufficient Disk Space Once the disk that stores the SecurityCenter data is within 5% of being filled, the icon indicator will turn red.

Correct RPM Package

Installed This indicator is green when the correct RPM is installed for the OS architecture on which it is running.

The “Diagnostics File” section is used primarily when working with the Tenable Support team. In order to troubleshoot issues that may be encountered, the Support team may request that a diagnostics file be generated with one or more of the “Diagnostics File Chapters” selected. If selected, the “Sanitize” option will remove IP addresses from the log files before generating the diagnostics file.

P

REFERENCES

On the upper right-hand of the SecurityCenter web interface, the System option contains a drop-down that includes Preferences. This option includes both location and notification settings.

Basic

The “Basic” option tab allows the admin to configure the local time zone. Important: This affects the date/time displayed on reports and within the user interface and not the actual system time on the server itself.

Notifications

Notifications are a feature of SecurityCenter 4 that allows specified events to display a pop-up in the lower right-hand corner of the SecurityCenter web UI.

(20)

Current notifications can be viewed by clicking on the left-hand circle at the lower right-hand corner of the SecurityCenter web page. Unread notifications will have a blue circle while a black circle indicates no unread notifications. Clicking on “Mark All As Read” removes the blue circle, but leaves the notifications there for later review. To view notification details, click the highlighted title to expand out the notification details.

Notifications can also be deleted by clicking on the “X” to the right of the notification text or clicking on the “Delete All” command button within the Notification box dialog. Admin configurable notifications are displayed in the screen capture below:

KEYS

On the upper right-hand of the SecurityCenter web interface, the System option contains a drop-down that includes a Keys section. Keys allow the administrator to use key-based authentication with a remote SecurityCenter (remote repository) or between a

SecurityCenter and an LCE server. This also removes the need for the SecurityCenter administrator to know the administrator login or password of the remote system.

The public key from the local SecurityCenter must be added to the “Keys” section of the SecurityCenter that you wish to retrieve a repository from. If the keys are not added properly, the remote repository “add” process will prompt for the root username and password of the remote host before the repository add/sync occurs.

Available options include “Download Key”, “Add”, and “Delete”. To download the local SecurityCenter’s key, click “Download Key”. After doing this, the key format dialog is displayed. Choose the type of key being requested and then click “Download”:

(21)

If “DSA Key” was chosen during download, the DSA public key is downloaded. Likewise, choosing “RSA Key” downloads the RSA public key string.

Clicking on “Add” brings up the dialog box below:

In the “Type” drop-down, select DSA or RSA as the key type.

In the “Comment” box, enter a string of text that describes the purpose of the key being added to the system.

In the “Public Key” box, paste the text of the public key from the remote SecurityCenter and click “Submit”. If a valid public key was entered, a “Success” message is displayed and the key will show up in the key list.

Remote LCE Key Exchange

A manual key exchange between the SecurityCenter and the LCE is normally not required; however, in some cases where remote root login is prohibited or key exchange debugging is required, you will need to manually exchange the keys.

For the remote LCE to recognize the SecurityCenter, you need to copy the SSH public key of the SecurityCenter and append it to the “/opt/lce/.ssh/authorized_keys” file. The

“/opt/lce/daemons/lce-install-key.sh” script performs this function. The steps are outlined in Appendix 2 of this document.

SSL CLIENT CERTIFICATE AUTHENTICATION

A new feature in SecurityCenter 4.4 allows users to use SSL client certificate authentication. This allows use of SSL client certificates, smart cards, and CAC authentication when the browser is configured for this method.

(22)

By default, SecurityCenter uses a password to authenticate. To configure SecurityCenter to allow SSL client certificate authentication the web server must be configured to allow such connections. To do this, the /opt/sc4/support/conf/sslverify.conf file must be edited on the SecurityCenter server using any standard text editor. Edit the “SSLVerifyClient” setting to use an option of none, optional, and require as described in the following table.

Table 6 – SSL Client Certificate Configuration Options

none When set to “none”, SSL certificates for SecurityCenter will

not be accepted by the server for user authentication purposes.

optional When set to “optional”, valid SSL certificates for

SecurityCenter may be used for user authentication. If a valid certificate is not presented, the user may log in using only a password.

Depending on how they are configured, some web browsers may not connect to SecurityCenter when the “optional” setting is used.

require When set to “require”, a valid SSL certificate for

SecurityCenter must be presented to gain access to the web interface. If the user has an account that uses a certificate to authenticate, that user will be logged into SecurityCenter. Otherwise the user will be presented with the standard SecurityCenter login page.

When a user is initially created and configured, a password must be created for the user. Users who are configured to use SSL certificates will be prompted to determine if they want to always use the current certificate when they log in to SecurityCenter through a browser. If “Yes” is selected, the certificate will be associated with their account and future access to SecurityCenter will use the client certificate. If “No” is selected, the certificate will be ignored for the current session.

Configure SecurityCenter for Certificates

The first step to allow SSL certificate authentication is to configure the SecurityCenter web server. This process allows the web server to trust certificates created by the Certificate Authority (CA) for authentication.

1. Copy the required PEM-encoded CA certificate (and intermediary CA, if needed) to the SecurityCenter server’s /tmp directory. For this example, the file is named ROOTCA2.cer.

2. Run the installCA.php script to create the required files for each CA in /opt/sc4/data/CA as follows:

(23)

3. Once each of your CAs has been processed, restart the SecurityCenter services with the following command:

# service SecurityCenter restart

After SecurityCenter has been configured with the proper CA certificate(s), users may log in to SecurityCenter using SSL client certificates.

Connect with SSL Certificate Enabled Browser

The following information is provided with the understanding that your browser is configured for SSL certificate authentication. Please refer to your browser’s help files or other documentation to configure this feature.

The process to configure a certificate login begins when a user connects to SecurityCenter for the first time. The process is completed by the user and does not require Administrator intervention.

1. Launch a browser and navigate to SecurityCenter.

2. The browser will present a list of available certificate identities to select from:

3. Once a certificate has been selected, a prompt for the PIN or password for the certificate is presented (if required) to access your certificate. When the PIN or password is successfully entered, the certificate will be available for the current session with SecurityCenter.

(24)

4. Upon the initial connection, log in using the username to be associated with the selected certificate.

Only one SecurityCenter user may be associated with a single certificate. If one user holds multiple user names and roles, a unique certificate must be provided for each login name.

5. Once logged in, a window titled “Certificate Authentication” is presented, asking if the current certificate is to be used to authenticate the current user. If “Yes” is selected, the certificate will be associated with this user. If “No” is selected, the certificate will be ignored for the current session.

If the user’s browser is configured for certificate authentication but is not configured for a SecurityCenter user, the following prompt will be presented for each login.

6. When a user’s account is associated with a certificate, it is displayed on the user’s information page and may be viewed using the “Edit User” page on the “Basic” tab.

The “Certificate Details” section for a user only appears if there is an associated certificate.

(25)

7. If a user’s certificate changes or is required to be revoked, the current certificate may be disassociated from the user by clicking the “Clear Certification Details”

button. The current information will be deleted and replaced with the following until a new certificate is submitted:

8. If a new certificate is available the next time the user logs in, SecurityCenter will again attempt to associate the user with the certificate.

If you log out of the session, you will be presented with the standard

SecurityCenter login screen. If you wish to log in again with the same certificate, refresh your browser. If you need to use a different certificate, you must restart your browser session.

RESOURCE MANAGEMENT

The Resources tab provides the Admin user with the ability to configure supporting

resources such as Log Correlation Engines, Nessus scanners (and scan zones), and Passive Vulnerability Scanners. This section describes the various resources and configuration options.

N

ESSUS

S

CANNERS

In the SecurityCenter framework, the Nessus scanner behaves as a server, while SecurityCenter serves as a client that schedules and initiates scans, retrieves results, reports results, and performs a wide variety of other important functions. Click

“Resources” and then “Nessus Scanners” to retrieve a list of the scanners and their current status, version, host, number of assigned zones, and when they were last modified.

(26)

If the status of a scanner has changed recently (since visiting the page), click the “Update Status” button to see the latest scanner status.

There are three classifications of Nessus scanners that may be added to SecurityCenter: “Managed”, “Unmanaged”, and “Perimeter Service”.

Managed

A “Managed” scanner is one that is managed by SecurityCenter. Managed scanners are logged into using Nessus admin credentials, and SecurityCenter has the ability to send plugin updates to the scanner. SecurityCenter also maintains the Activation Code for Managed scanners.

Unmanaged

An “Unmanaged” scanner is one that has been logged into by a standard Nessus user. This scanner may be used to perform a scan but SecurityCenter cannot send plugin updates to an unmanaged scanner or manage its Activation Code.

Perimeter Service

SecurityCenter may also use a “Perimeter Service” scanner to perform scans using Tenable’s Perimeter Service. This is a vulnerability scanning service that may be used to audit Internet facing IP addresses for both network and web application vulnerabilities “from the cloud”. The Perimeter Service is also considered to be an unmanaged scanner, and SecurityCenter will not push plugin updates to a Perimeter Service scanner. More

information about using the Perimeter Service through SecurityCenter is found later in this document.

In the examples below, the Nessus scanners are installed on remote systems, are of varying types, and are functioning properly.

Adding a Nessus Scanner

To add a scanner, click the “Add” button. A screen capture of the “Add Scanner” dialog is shown below:

(27)

The table below goes into more detail about the available options for adding a Nessus scanner:

Table 7 – Nessus Scanner Options

Name Descriptive name for the Nessus scanner.

Description Scanner description, location, or purpose.

Host Hostname or IP address of the scanner.

Port TCP port that the Nessus scanner listens on for

communications from SecurityCenter. The default is port 8834.

Authentication Type Password Based or SSL Certificate. For detailed SSL

Certificate configuration options, see Appendix 3: Nessus SSL Configuration.

Username Username generated during the Nessus install for daemon to

client communications. This must be an administrator user in order to send plugin updates to the Nessus scanner. If the

(28)

scanner will be updated by a different method, such as through another SecurityCenter, a standard Nessus user account may be used to perform scans.

Password The login password must be entered in this field. This field is

only available if the Authentication Type is set to “Password”. Certificate This field is available if the Authentication Type is “SSL

Certificate”. Select the “Browse” button, choose a SSL Certificate file to upload, and upload to the SecurityCenter. For more information, see Appendix 3: Nessus SSL Configuration.

Verify Hostname Adds a check to verify that the hostname or IP address

entered in the “Host” field matches the CommonName (CN) presented in the SSL certificate from the Nessus server.

State A scanner may be marked as “Enabled” or “Disabled” within

SecurityCenter to allow or prevent access to the scanner.

Zones The zone(s) that will contain this scanner.

Configure SecurityCenter for Custom Certificates to Verify Hostname

The first step to allow the Verify Hostname to work is to ensure the correct Certificate Authority (CA) certificate is configured for use by SecurityCenter. When using the default certificates for Nessus servers, this is not required to be done. Only when a custom CA is in use do these steps need to be performed.

1. Copy the required PEM-encoded CA certificate (and intermediary CA, if needed) to the SecurityCenter server’s /tmp directory. For this example, the file is named ROOTCA2.cer.

2. Run the installCA.php script to create the required files for each CA in /opt/sc4/data/CA as follows:

# /opt/sc4/support/bin/php /opt/sc4/src/tools/installCA.php /tmp/ROOTCA2.cer

3. Once each of your CAs has been processed, restart the SecurityCenter services with the following command:

# service SecurityCenter restart

After SecurityCenter has been configured with the proper CA certificate(s), the Verify Hostname will verify the SSL certificate presented against the proper CA certificate.

Nessus Perimeter Service Scanners

SecurityCenter 4.4 supports the use of the Nessus Perimeter Service as a Nessus scanner within SecurityCenter. The Nessus Perimeter Service is an enterprise-class remote vulnerability scanning service that may be used to audit Internet facing IP addresses for both network and web application vulnerabilities “from the cloud”. While they are not “managed” by a SecurityCenter (e.g., plugins are not pushed from SecurityCenter to the scanner), Nessus Perimeter Service scanners can be added to SecurityCenter in the same manner that internal, local, or remote Nessus scanners are added.

(29)

To add a Nessus Perimeter Service scanner to SecurityCenter, a valid and active Nessus Perimeter Service subscription must be used. In SecurityCenter, select the “Resources” tab, “Nessus Scanners”, and then “Add”:

Enter a name (mandatory) and description (optional) for the Nessus Perimeter Service scanner to be used with SecurityCenter. Enter the web address used for the browser-based version of the Nessus Perimeter Service as “Host”, with the “Port” specified as 443

(HTTPS). Enter a valid Nessus Perimeter Service username and password for authentication and select the zone(s) within SecurityCenter that will use the Nessus Perimeter Service scanner. When finished, click “Submit” to add the authorized Nessus Perimeter Service scanner to SecurityCenter. If successful, the Nessus Perimeter Service scanner will be listed under “Nessus Scanners” with a status of “Working”:

(30)

Note that existing scan reports from the Nessus Perimeter Service are not automatically made available through SecurityCenter, but they can be manually downloaded and imported into SecurityCenter by users with permissions to do so.

When using a Nessus Perimeter Service scanner and the use of SecurityCenter’s configured proxy server is required to connect to the internet, please contact Tenable Support for additional configuration information.

Nessus Scanner Details

When the “Detail” button is clicked, information about the selected scanner is displayed. The information includes the basic information of name, description, IP address, port, username used to connect to the scanner, and when the scanner was created and last modified. The Nessus scanner version, web server version, type, and zones it is a part of are also displayed. The number of active scans (load) the server is performing is displayed and updated every 15 minutes, as well as the current SecurityCenter plugin set, the plugin set the Nessus scanner is currently using for scanning, and which plugin set is currently loaded.

(31)

The Scanner Plugin Set may show a difference between the “Current” set and the “Loaded” set. This occurs when plugins are updated but the Nessus scanning engine has not been restarted to run the newest plugins.

Scan Zones

Scan Zones define the IP ranges associated with the scanner along with organizational access. SecurityCenter allows defined Organizations to be configured with two different scan zone modes: “selectable” and “forced”. If an Organization is in “selectable” mode, any available zones can be associated with the Organization and made available to users for scanning configuration. If an Organization is in “forced” mode, the selected zone will always be used for every scan performed by users in that Organization.

When in “selectable” mode, at scan time, the zones associated with the Organization and “default” are available to the user. When a scan is configured to use a specific zone in either selectable or forced mode, the zone’s ranges are ignored and any IPs in the managed

ranges for that user will be scanned by the Nessus scanners associated with the chosen zone.

When a scan is configured to use the “default” zone, the targets for the scan will be given to scanners in the most appropriate zone available based on the zone’s specified ranges (20K character limit). This facilitates optimal scanning and is very useful if an Organization has devices placed behind a firewall or NAT device and has conflicting RFC 1918 non-internet-routable address space with another Organization. In addition, some Organizations may benefit from the ability to override their default scanner(s) with one(s) from a different zone. This allows an Organization to more easily run internal and external vulnerability scans.

Sometimes forcing a scan to use a “non-ideal” scanner is helpful to analyze the vulnerability stance from a new perspective. For example, setting the default scanner to an external one allows you to see the attack surface from an external attacker’s perspective.

(32)

PASSIVE VULNERABILITY SCANNERS

Tenable’s Passive Vulnerability Scanner (PVS) is a network discovery and vulnerability analysis software solution, delivering real-time network profiling and monitoring for

continuous assessment of an organization’s security posture in a non-intrusive manner. The PVS monitors network traffic at the packet layer to determine topology, services and

vulnerabilities. Where an active scanner takes a snapshot of the network in time, the PVS behaves like a security motion detector on the network.

When deployed as a “stand alone” sensor, the PVS simply records its detected

vulnerabilities to a .nsr, .nessus, .xml, or .html file(s), depending on the configuration of the PVS. When deployed for operation with SecurityCenter, the PVS ships with an agent named the PVS Proxy. This agent is a server that waits for inbound connections from SecurityCenter.

By default, the PVS Proxy listens on port 1243. This is similar to a typical Nessus daemon that listens on port 8834. These ports are not hard-coded, and they can easily be modified for operation on alternate ports.

SecurityCenter will ask the PVS Proxy for the latest (if any) vulnerability report every 15 minutes. If the PVS is configured to record its passive vulnerability data every six hours, then new passive vulnerability data will only be available to SecurityCenter every six hours. By default, SecurityCenter will check every 24 hours to see if any new passive vulnerability plugins have been downloaded from Tenable and will push them out to each PVS scanner. The screen capture below shows a listing of working PVS scanners:

(33)

To configure one or more of Tenable’s PVS servers, under the “Resources” tab select “Passive Scanners”. This will produce a form that lists all configured PVS devices and their current status.

To enable a PVS, add the PVS scanner IP address, the port its proxy is listening on (which defaults to 1243), its username, password, and then click the repository that will be subscribed to the PVS data. Pressing “Ctrl” or “Shift” on the keyboard when clicking will allow for the selection of multiple repositories to be subscribed to the PVS data.

It is recommended to use passwords that are at least eight characters in length and include a combination of lower and upper-case letters along with non-alphabetic characters.

LOG CORRELATION ENGINES

Tenable’s Log Correlation Engine (LCE) is a software module that aggregates, normalizes, correlates, and analyzes event log data from the myriad of devices within the infrastructure. Since the LCE is closely integrated with SecurityCenter, log analysis and vulnerability

management can be centralized for a complete view of an organization’s security posture. SecurityCenter performs vulnerability, compliance, and event management, but does not directly receive logs or IDS/IPS events. The LCE upgrade to SecurityCenter does all of this

(34)

by processing the events and then passing them on to SecurityCenter. Once on SecurityCenter, the logs are aggregated further and made available for analysis and reporting.

LCE 3.6.1 or greater is required for interoperability with SecurityCenter 4.2.x and higher. LCE 3.4.x may be used with the caveat that the Asset Summary tool will not work due to its reliance on enhancements in LCE 3.6.1.

Note that more than one Log Correlation Engine can be configured to work with SecurityCenter.

To configure LCE servers, select “Log Correlation Engines” under the “Resources” tab. A screen will be displayed similar to the following:

Click “Add” to bring up the dialog in the screen capture below. Available fields include Name, Description, Host, and Organizations.

Earlier versions of SecurityCenter had a “Managed Ranges” field that was used for event direction determination. This field was removed in SecurityCenter 4.2 and event direction is now determined by the ranges specified in the lce.conf configuration file’s “include-networks” directive.

During the LCE “Add” process, the remote LCE login prompt will occur so that the

SecurityCenter authenticate with the LCE. If remote credential login is prohibited in your environment, refer to Appendix 2 for instructions on how to authenticate to the LCE server using key authentication.

(35)

If organizational policy prohibits remote root login, a manual key exchange process can be used. See Appendix 2: Manual LCE Key Exchange for detailed

guidance. Table 8 – LCE Options

Name Name used to describe the Log Correlation Engine.

Description Descriptive text for the Log Correlation Engine.

Host IP address of the Log Correlation Engine.

Organizations Determines which Organizations will be able to access data

from the configured Log Correlation Engine.

IDS SOURCES

Starting with SecurityCenter 4, IDS sources are configured solely on the Log Correlation Engine (LCE) instead of through the SecurityCenter interface. This change enhances

SecurityCenter performance and event correlation. For more information on configuring IDS sources, see the LCE documentation located on the Tenable Support Portal.

DATA MANAGEMENT

REPOSITORIES

A repository is essentially a database of vulnerability data defined by one or more ranges of IP addresses. SecurityCenter integrates repositories of vulnerability data that are shared as

(36)

needed among users and organizations based on manager-defined assets. The use of

repositories allows for scalable and configurable data storage for organizations. Repositories can also be shared between multiple SecurityCenters. Repositories are configured by the administrative user and made available to the Organization Head to assign to users as needed.

When creating SecurityCenter 4 repositories, LCE event source IP ranges must be included along with the vulnerability IP ranges or the event data will not be accessible from the SecurityCenter UI.

There are three types of repositories: “Local”, “Remote”, and “Offline”. Local repositories are active repositories of SecurityCenter data collected via scanners attached to the local

SecurityCenter. Remote repositories contain IP address and vulnerability information obtained via network synchronization with a second (remote) SecurityCenter. Offline repositories enable SecurityCenter to obtain repository data via manual export/import from a remote SecurityCenter that is not network-accessible. The screen capture below shows several configured repositories.

As shown in the screen capture above, hover the cursor over the “Total Active IPs” graphic at the bottom of the screen to view currently used IPs, total IP license count, and IPs remaining.

Repository data collected from a remote or offline repository is static and used solely for reporting purposes.

Click the “Add” button to add a new repository. The sections below contain options for adding each of the three types of repositories.

(37)

Local Repository

This is the default repository type. Data stored in local repositories can be shared between Organizations and includes the full range of event and vulnerability metadata. The table below describes configurable fields for a local repository:

Table 9 – Local Repository Options

Name The repository name.

Description Descriptive text for the repository.

Type Local

Trending

If trending is not selected, any query that uses comparisons between repository snapshots (e.g., trending line charts) will not be available.

This option allows for a periodic snapshot of the .nessus data for vulnerability trending purposes. This option is particularly useful in cases where trending is important. In situations where repository datasets do not change

frequently – negating the need for trending – disable this option to minimize disk space usage.

Generate Nessus File Use this option to schedule how frequently the Nessus file snapshot will be taken. Available options include: Never, Daily, Weekly, Monthly (Day), and Monthly (Date).

Download Format Allows for selecting between the Nessus v1 and v2 formats

for the generated Nessus file.

IP Ranges Allowed ranges for importing vulnerability data. Addresses

may be a single IP address, IP range, CIDR block or any comma-delimited combination (20 K character limit). LCE Correlation Log Correlation Engine servers that will receive the

vulnerability correlation information from this repository.

Organizations Organizations that have access to the vulnerability data

within the repository. Within the “Organizations” section, click the green key icon for access control options. Access is available for the “Organization Head” user or for “All Users” within the Organization (affects existing users only). For existing repository edits, an additional option labeled “Existing Users” is available. This option leaves the current user access intact. Click “Submit” to apply the changes.

(38)

Remote Repository

Remote repositories are useful because they allow separate SecurityCenters to share

repository data via a SSH session. The table below describes configurable fields for a remote repository:

Table 10 – Remote Repository Options

Name The repository name.

Description Descriptive text for the repository.

Type Remote

Remote Repository Host to synchronize with to obtain the repository data. After entering the hostname or IP address of the remote

SecurityCenter, click the “Retrieve Repositories” link to enter an admin username and password for the SecurityCenter to exchange the SSH keys. Once completed, a list of available repositories will be populated.

Repository Remote repository to collect IP address(es) and vulnerability

data from. This is a drop-down list of the available repository names available on the remote SecurityCenter.

Trending

This option allows for a periodic snapshot of the .nessus data for vulnerability trending purposes. This option is particularly useful in cases where trending is important. In situations where repository datasets do not change

frequently – negating the need for trending – disable this option to minimize disk space usage.

Generate Nessus File Use this option to schedule how frequently the Nessus file snapshot will be taken. Available options include: Never, Daily, Weekly, Monthly (Day), and Monthly (Date). The .nessus files generated by this process can be imported into Nessus scanners or any third-party tool that accepts the

(39)

.nessus format as required. This option is not related to the “Sync Schedule” below, which relates to automating the synchronization of vulnerability data between

SecurityCenters.

Sync Schedule Frequency with which the local and remote repositories are

synchronized. Synchronization options include: “Never”, “Daily”, “Weekly”, “Monthly (Date)”, and “Monthly (Day)”. Click the “Time Zone” link to ensure the Sync Schedule time is being performed at the correct local time.

may be a single IP address, IP range, CIDR block or any comma-delimited combination (20 K character limit).

To share data, enter the IP address of the remote SecurityCenter in the “Host” field and click “Retrieve Repositories”.

If a key for the current SecurityCenter has not been added to the remote SecurityCenter key list, the retrieve process will prompt for the SecurityCenter admin credentials of the remote host.

If the key authentication is not configured (System -> Keys), you will be prompted for the administrator username and password for the remote host. Repository IP addresses and vulnerability/event data is then retrieved from the remote SecurityCenter for use in the new one.

(40)

Offline Repository

Offline repositories are similar to remote repositories with the exception that data is synchronized manually using an archive file (.tar.gz) and not via network transmission. The table below describes configurable fields for an offline repository:

Table 11 – Offline Repository Options

Name The repository name

Description Descriptive text for the repository

Type Offline

Trending

This option allows for a periodic snapshot of the .nessus data for vulnerability trending purposes. This option is particularly useful in cases where trending is important. In situations where repository datasets do not change frequently – negating the need for trending – disable this option to minimize disk space usage.

Generate Nessus File Use this option to schedule how frequently the Nessus file snapshot will be taken. Available options include: Never, Daily, Weekly, Monthly (Day), and Monthly (Date). The .nessus files generated by this process can be imported into Nessus scanners or any third-party tool that accepts the .nessus format as required.

may be a single IP address, IP range, CIDR block or any comma-delimited combination (20 K character limit).

(41)

To initiate offline repository synchronization, first download the repository archive from an existing repository by clicking on the “Download” link. You may download the archive as a Nessus or Compressed Tar (.tar.gz) formatted file.

Depending on browser choice, the option to open or save the Nessus or Compressed Tar file is presented. It is recommended that the file be saved at this time.

Depending on the size of the repository database, this file can be quite large. It is important to save the file to a location with plenty of free disk space.

When importing the repository archive, the default maximum file import size is 150MB. This is specified by the “post_max_size” directive in

/opt/sc4/support/etc/php.ini. If larger file uploads are required, increase the default value.

To load the repository archive to the offline repository, copy it to a location where the offline repository is accessible via the SecurityCenter GUI, open the “Repositories” page, highlight the offline repository and click “Sync”.

Browse for the repository archive and click “Submit” to load the offline repository archive file.

ACCEPT RISK RULES

Any non-admin user has the ability to accept a vulnerability risk by adding an “Accept Risk Rule”. Adding a rule moves vulnerabilities from the unfiltered cumulative database view. These vulnerabilities are not deleted, but only display in the cumulative database

(42)

vulnerability view if the “Accepted Risk” filter option is checked. Once a risk has been

accepted, the admin user can view the details of and delete the accept rules associated with the risk if they deem that the risk is still valid. This is accomplished by clicking on

“Repositories” and then “Accept Risk Rules”. From there a list of available rules is

displayed for the selected Plugin ID, Repository, and Organization combination. Choose “All” for Repository and “Any” for Organization if plugin IDs are to be accepted across these boundaries. This is especially useful in setups where hundreds of repositories or

organizations have been configured and the same accept risk rule must be applied globally.

Select the rule to be removed and click “Detail” to view the highlighted “Accept Risk Rule”. To remove the rule, click “Delete” and a confirmation dialog is displayed that confirms if you really wish to delete the accepted risk rule:

After clicking “Delete”, click the “Apply Rules” button in the top left for the changes to take effect. Once completed, any vulnerabilities that had been modified by the accept risk rule are displayed unfiltered in the cumulative database.

RECAST RISK RULES

Similar to “Accept Risk Rules”, “Recast Risk Rules” are rules that have been recast to a different risk level by a non-admin user. The admin user can display and delete these rules if desired. As with “Accept Risk Rules”, rules can be applied for a single plugin ID against a single repository/organization combination or globally. A screen capture of example “Recast Risk Rules” is shown below.

(43)

To view the rule details, click “Detail” to view the highlighted “Recast Risk Rule”. To remove the rule, click “Delete”. A confirmation dialog is displayed and confirms that you really wish to delete the recasted risk rule:

After clicking “Delete”, click the “Apply Rules” button in the top left for the changes to take effect. Once completed, any vulnerabilities that had been modified by the recasted risk rule are returned to their original state.

USER MANAGEMENT

ORGANIZATIONS

Many of the concepts in this section such as zones, multiple organizations, and repositories apply to SecurityCenter only.

An Organization is defined as a set of distinct Users. These Users are assigned repositories and “zones” within one or more specified IP networks. “Users” refers to any

non-administrator login account on SecurityCenter. “Zone” means that each Organization is made up of the systems within one or more IP networks.

Multiple Organizations can share the same repository, and the vulnerability data associated with the overlapping ranges will be shared between each Organization. Conversely,

Organizations can be configured with their own discrete repositories to facilitate situations where data must be kept confidential between different business units.

The Organization is managed primarily by the Administrator and Organization Head users. The Administrator is responsible for Organization and Organization Head creation and maintenance. Users within the Organization are created by the Organization Head user or any user with the “Manage Users” permissions. User management is strictly hierarchical. For example, consider the diagram below:

(44)

In Organization A, the Org Head user has control over all Users and Managers in

Organization A. Manager 1 similarly has control over all Users and Managers (except the Org Head user). Manager 2, however, only has control over Users B through G since User A and Manager 1 are not in their hierarchy.

In Organization B, Manager 3 has control over all Organizational Users except for the Org Head user. We have created two users with custom roles. These custom roles have the “Manage Users” role and subsequently were able to create Users H through J. Custom 1 has control over Custom 2 along with all Users; however, Custom 2 only has control over Users I and J.

It is important to consider these concepts when working with the built-in roles and creating custom ones as they relate to your organizational structure.

Creation of an Organization is a two-step process. The screen capture below contains two tabs: one for the actual Organization detail entry and the second for creation of the Organization Head user.

(45)

The table below describes options required during the creation of an Organization: Table 12 – Organization Options

Option Description Basic Information

Name Organization name

Description Descriptive text for the Organization.

Address Organization address

City Organization city

State Organization state

Country Organization country

SecurityCenter 4.4 Administration Guide