You are here: How To > Workflow

Workflow

The Workflow section contains options for alerting and ticketing. These functions allow the user to be notified of and properly handle vulnerabilities and events as they come in.

Alerts

SecurityCenter can be configured to perform actions, such as email alerts, for select vulnerability or alert occurrences to various users regardless of whether the events correlate to a local vulnerability or not. Other alert actions include UI notification, ticket creation/assignment, remediation scans, launching a report, email notification, and syslog alerting. Many actions can be assigned per ticket.

The user is presented with the ability to “Add” from the main Alerts page, and from the gear icon menu “Edit”, “Evaluate”, “View” (view details of), and “Delete” alerts. The “Evaluate” option allows an alert to be tested whether it has met the configured time criteria or not. Clicking on an alert will take the user to the Edit Alert page for the selected alert.

The screen capture below shows a sample add alert configuration page:

Alert Options

Option Description

Name

Alert name

Description

Descriptive text for the alert

Schedule

The setting will determine how often the alert checks for the conditions to be matched. Selections vary in frequency from 15 minutes to monthly. Selecting the option of Never will create the alert to be launched only on demand.

Behavior

If set to alert on the first occurrence, the alert will only trigger when the condition initially changes from false to true. The other option is to trigger on each detection of the true condition.

Type

Vulnerability, Event, or Ticket

Trigger

IP Count – Trigger on vulnerabilities or events whose IP count matches the given parameters.

Unique Vulnerability/Event Count – Trigger an alert when the vulnerability/event count matches the given parameters. This option is set to “Unique Vulnerability Count” for vulnerability alerts and “Event Count” for event alerts.

Port Count – Trigger an alert when the events/vulnerabilities using a certain port number match the given parameters.

Query

The dataset to which the trigger condition will be compared.

Filters

Apply advanced filters to the vulnerability or event data. The complete filter set may be created here, or if a Query was selected those parameters may be edited. See tables 8 and 10 for filter options.

Add Actions

Adding actions will determine what the alert does with triggered events. The options are Assign Ticket, Email, Generate Syslog, Launch Scan, Launch Report, or Notify Users. Multiple actions may be triggered for each alert.

The configuration of each of these actions is described in the next table.

 

Clicking on “Add Actions” will present you with the following options:

Tip: Use email alerts to interface with third-party ticketing systems by adding variables in the message field.

Alert Action Definition Options

Option Description

Email

Subject

Subject line of the alert email.

Message

Message of the alert email. Within the message body, the following variables can be defined for email message customization:

Alert ID – Designated with the variable: %alertID%, this specifies the unique identification number assigned to the alert by SecurityCenter.

Alert name – Designated with the variable: %alertName%, this specifies the name assigned to the alert (e.g., “Test email alert”).

Trigger Name – Designated with the variable: %triggerName%, this specifies if the trigger is IP count, Vulnerability count, or Port count.

Trigger Operator – Designated with the variable: %triggerOperator%, this specifies which operator was used for the count: >=, =, >= or !=

Trigger value – Designated with the variable: %triggerValue%, this specifies the specific threshold value set that will trigger the alert.

Calculated value – Designated with the variable: %calculatedValue%, this specifies the actual value that triggered the alert.

Alert Name – Designated with the variable: %alertName%, this specifies the name given to the alert within SecurityCenter.

Alert owner – Designated with the variable: %owner%, this specifies the user that created the alert.

SC URL – Designated with the variable: %url%, this specifies the URL that the SecurityCenter can be accessed with. This is useful where the URL that users can access SecurityCenter with differs from the URL known by SecurityCenter.

The sample email alert below contains some of these keywords embedded into an HTML email:

 

Alert <strong>%alertName%</strong> (id #%alertID%) has triggered.

 

<strong>Alert Definition:</strong> %triggerName% %triggerOperator% %triggerValue%

<strong>Calculated Value:</strong> %calculatedValue%

 

Please visit your SecurityCenter (<a href="%url%">%url%</a>) for more information.

This e-mail was automatically generated by SecurityCenter as a result of alert <strong>%alertName%</strong> owned by <strong>%owner%</strong>.

 

If you do not wish to receive this email, contact the alert owner.

Include Results

If this check box is checked, the query results (maximum of 500) that triggered the alert are included in the email.

Users

Users who will be emailed. The user email address is used with this function.

Tip: If a user is configured within the email action and that user is deleted, the action field within the alert turns red. In addition, a notification is displayed for the new alert owner with the new alert status. To resolve this, edit the alert action definitions and choose “Edit Action” to apply the correct users(s).

Email Addresses

Additional email addresses to send the alert to. For multiple recipients, add one email address per line or use a comma-separated list.

Notify Users

Message

Custom notification message to generate when the alert triggers.

Users

Users who will receive the notification message.

Generate Syslog

Host

Host that will receive the syslog alert.

Port

UDP port used by the remote syslog server.

Severity

Severity level of the syslog messages (Critical, Warning, or Notice).

Message

Message to include within the syslog alert.

Assign Ticket

Name

Name assigned to the ticket

Description

Ticket description

Assignee

User who will receive the ticket

Scan

Scan

Scan template to be used for the alert scan. Allows the user to select from a list of available scan templates to launch a scan against a triggered host.

Note: The scanned host will be the host that triggered the scan and not the host within the scan template itself. IPs used for the scan targets are limited to the top 100 results of the alert query.

Report

Report Template

Allows the user to select an existing report template and generate the report based on triggered alert data.

 

Tickets

Tickets can be created both manually and automatically by a predefined set of conditions through the alerting functionality described above.

Tickets are created from the Workflow -> Tickets view or when viewing vulnerabilities or events through the analysis tools.

Tickets contain the following fields:

Ticket Options

Option Description
General

Name

Name assigned to the ticket.

Description

Descriptive text for the ticket.

Notes

Notes for the ticket assignee.

Assignee

User that the ticket is assigned to.

Note: If the ticket assignee is deleted, the ticket is automatically reassigned to the assignee’s owner along with a notification message indicating that the ticket has been reassigned.

Status (Available during edit)

The following ticket statuses become available after a ticket has been created and are available from the “Edit” screen:

  • Assigned
  • Resolved
  • More Information
  • Not Applicable
  • Duplicate
  • Closed

Classification

Ticket classification can be selected from a drop-down list containing such items as Information, Configuration, Patch, Disable, False Positive, and many others.

Type

Vulnerability, Event, or Ticket

Select a Query

List of queries to choose from for the ticket assignee to help provide context for coming up with a resolution.

 

In addition to adding and editing tickets, a “Browse” command button is available. This option enables the user to view the vulnerability snapshot added during ticket creation. The displayed view matches the query that was used by the ticket.

To view details about an existing ticket, click the ticket to bring up the edit ticket screen, use the “Edit” option from the gear icon menu to view options that were set during the “Add Ticket” process or use the “View” option from the gear icon menu to view a Ticket Detail summary with the name, status, creator, assignee, history, queries, description, and ticket notes.

Once a ticket has been mitigated, click on the “Resolve” option from the gear icon menu to provide ticket resolution.

Once the ticket is resolved it may be closed from the “Close” option from the gear icon menu.

Within the “Status” drop-down, the user can select from one of these status options: Assigned, Resolved, More Information, Duplicate, or Not Applicable. Choose the correct status and add notes relevant to the ticket resolution. Resolved tickets still show up in the user’s ticket queue with an “Active” status. Closing a ticket removes the ticket from the “Active” status filter view, but does not provide the ability to add notes similar to the “Update Ticket” function. Tickets in the “Resolved” or “Closed” state can always be reopened as needed.

Accept Risk Rules

The Accept Risk Rules section lists the currently created rules of accepted risks. This enables users to obtain information on what particular vulnerabilities or hosts have been declared to be accepted and, if noted in the comments, the reason. Rules may be searched by Plugin ID or Repository. If a vulnerability is determined to be unaccepted, the rule may selected and deleted.

Recast Risk Rules

The Recast Risk Rules section lists the currently created rules of recast risks. This enables users to obtain information on what particular vulnerabilities or hosts have had risk levels recast, their new severity level and, if noted in the comments, the reason for the severity change. Rules may be searched by Plugin ID or Repository. If a vulnerability is to be reset to its original severity level, the rule may be deleted.

Copyright © 2016. Tenable Network Security, Inc. All rights reserved. Tenable Network Security and Nessus are registered trademarks of Tenable Network Security, Inc. SecurityCenter Continuous View, Passive Vulnerability Scanner, and Log Correlation Engine are trademarks of Tenable Network Security, Inc. All other products or services are trademarks of their respective owners.