Table of Contents

FireSIGHT-System-UserGuide-v540TOC

Introduction Preface

Logging into the FireSIGHT System

Using Objects and Security Zones

Managing Devices

Setting Up an IPS Device

Setting Up Virtual Switches

Setting Up Virtual Routers

Setting Up Aggregate Interfaces

Setting Up Hybrid Interfaces

Using Gateway VPNs

Using NAT Policies

Getting Started with Access Control Policies

Blacklisting Using Security Intelligence IP Address Reputation

Tuning Traffic Flow Using Access Control Rules

Controlling Traffic with Network-Based Rules

Controlling Traffic with Reputation-Based Rules

Controlling Traffic Based on Users

Controlling Traffic Using Intrusion and File Policies

Understanding Traffic Decryption

Getting Started with SSL Policies

Getting Started with SSL Rules

Tuning Traffic Decryption Using SSL Rules

Understanding Intrusion and Network Analysis Policies

Using Layers in Intrusion and Network Analysis Policies

Customizing Traffic Preprocessing

Getting Started with Network Analysis Policies

Using Application Layer Preprocessors

Configuring SCADA Preprocessing

Configuring Transport Network Layer Preprocessing

Tuning Preprocessing in Passive Deployments

Getting Started with Intrusion Policies

Tuning Intrusion Rules

Tailoring Intrusion Protection to Your Network Assets

Detecting Specific Threats

Limiting Intrusion Event Logging

Understanding and Writing Intrusion Rules

Blocking Malware and Prohibited Files

Logging Connections in Network Traffic

Working with Connection Security Intelligence Data

Analyzing Malware and File Activity

Working with Intrusion Events

Handling Incidents

Configuring External Alerting

Configuring External Alerting for Intrusion Rules

Introduction to Network Discovery

Enhancing Network Discovery

Configuring Active Scanning

Using the Network Map

Using Host Profiles

Working with Discovery Events

Configuring Correlation Policies and Rules

Using the FireSIGHT System as a Compliance Tool

Creating Traffic Profiles

Configuring Remediations

Using Dashboards

Using the Context Explorer

Working with Reports

Understanding and Using Workflows

Using Custom Tables

Searching for Events

Managing Users

Scheduling Tasks

Managing System Policies

Configuring Appliance Settings

Licensing the FireSIGHT System

Updating System Software

Monitoring the System

Using Health Monitoring

Auditing the System

Using Backup and Restore

Specifying User Preferences

Importing and Exporting Configurations

Purging Discovery Data from the Database

Viewing the Status of Long-Running Tasks

Command Line Reference

Security, Internet Access, and Communication Ports

Third-Party Products

glossary

Title Page

Introduction to the Cisco FireSIGHT System

The Cisco FireSIGHT® System is an integrated suite of network security and traffic management products, deployed either on purpose-built platforms or as a software solution.

The system is designed to help you handle network traffic in a way that complies with your organization’s security policy—your guidelines for protecting your network. A security policy may also include an acceptable use policy (AUP), which provides employees with guidelines of how they may use your organization’s systems.

In a typical deployment, multiple traffic-sensing managed devices installed on network segments monitor traffic for analysis and report to a managing Defense Center®. Deployed inline, devices can affect the flow of traffic.

Tip There are several models of device and Defense Center. Managed devices include physical and virtual FirePOWER appliances, Cisco NGIPS for Blue Coat X-Series, and Cisco ASA with FirePOWER Services (ASA FirePOWER). Defense Centers can also be deployed as physical or virtual appliances. When necessary, appliance models are further grouped into series and family. System capabilities often depend on model and license.

The Defense Center provides a centralized management console with web interface that you can use to perform administrative, management, analysis, and reporting tasks. Physical managed devices also have a web interface that you can use to perform initial setup and basic analysis and configuration tasks. Virtual managed devices, Cisco NGIPS for Blue Coat X-Series, and ASA FirePOWER devices do not have a FireSIGHT System web interface. For these devices, you must use a CLI to perform any tasks that you cannot complete using the managing Defense Center.

This guide provides information about the features and functionality of the FireSIGHT System. The explanatory text, diagrams, and procedures in each chapter provide detailed information to help you navigate the user interface, maximize the performance of your system, and troubleshoot complications.

The topics that follow introduce you to the FireSIGHT System, describe its key components, and help you understand how to use this guide:

- Introduction to the Defense Center

- Introduction to Managed Devices

- Defense Centers and Devices Delivered with Version 5.4.X

- FireSIGHT System Components

- Documentation Resources

- Documentation Conventions

- IP Address Conventions

Introduction to Managed Devices

Managed devices installed on network segments monitor traffic for analysis. Deployed passively, managed devices gather detailed information about your organization’s assets: hosts, operating systems, applications, users, transmitted files (including malware), vulnerabilities, and so on. The FireSIGHT System correlates this information for your analysis so you can monitor the websites your users visit and the applications they use, assess traffic patterns, and receive notifications of intrusions and other attacks.

Deployed inline, the system can affect the flow of traffic using access control, which allows you to specify, in a granular fashion, how to handle the traffic entering, exiting, and traversing your network. The data that you collect about your network traffic and all the information you glean from it can be used to filter and control that traffic based on:

- simple, easily-determined transport and network layer characteristics: source and destination, port, protocol, and so on

- the latest contextual information on the traffic, including characteristics such as reputation, risk, business relevance, application used, or URL visited

- Microsoft Active Directory LDAP users in your organization; you can grant different levels of access to different users

- characteristics of encrypted traffic; you can also decrypt this traffic for further analysis

- whether unencrypted or decrypted traffic contains a prohibited file, detected malware, or intrusion event

Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility and performance. For example, reputation-based blacklisting, because it uses simple source and destination data, can block prohibited traffic early in the process, while detecting and blocking intrusions and exploits is a last-line defense.

In addition to access control, network management features on Series 3 devices allow them to serve in switched and routed environments, perform network address translation (NAT), and to build secure virtual private network (VPN) tunnels between virtual routers you configure. You can also configure bypass interfaces, aggregated interfaces, fast-path rules, and strict TCP enforcement.

For more information, see:

- Series 2 and Series 3 Managed Devices

- 64-Bit Virtual Managed Devices

- Cisco NGIPS for Blue Coat X-Series

- Cisco ASA with FirePOWER Services

- Configurations that Restart the Snort Process

- How Snort Restarts Affect Traffic

Series 2 and Series 3 Managed Devices

Series 3 devices, which include all Cisco FirePOWER 7000 Series and 8000 Series devices, are the third series of physical devices purpose-built for the FireSIGHT System. Series 3 devices have a range of throughputs, but share most of the same capabilities. In general, 8000 Series devices are more powerful than 7000 Series; they also support additional features such as fast-path rules, link aggregation, and stacking.

Note that both Defense Centers and Series 3 devices are in the midst of a branding transition. The Defense Center is also referred to as the FireSIGHT Management Center, and Series 3 devices are also referred to as FirePOWER devices. Product identification numbers for Defense Centers may begin with FS rather than DC. Similarly, product identification numbers for Series 3 devices may begin with FP rather than 3D. The model numbers otherwise remain unchanged. For example, a DC4000 and an FS4000 refer to the same Defense Center.

Series 2 is the second series of physical managed devices. Series 2 devices automatically have most of the capabilities associated with a Protection license: intrusion detection and prevention, file control, and simple network-based access control.

However, because of resource and architecture limitations, Series 2 devices support a restricted set of features granted by the Protection license. Series 2 devices cannot perform Security Intelligence filtering or file control for nested files inside archive files. Also, Series 2 devices cannot perform geolocation-based access control, even with a FireSIGHT-licensed Defense Center. You cannot enable other licensed capabilities on a Series 2 device.

Although Cisco no longer ships new Series 2 appliances, you can update or reimage Series 2 devices running earlier versions of the system to Version 5.4.1. Note that reimaging results in the loss of almost all configuration and event data on the appliance. For more information, see the FireSIGHT System Installation Guide.

Tip You can migrate specific configuration and event data from a Version 4.10.3 deployment to a Version 5.2 deployment, which you can then update to Version 5.4.1. For more information, see the FireSIGHT System Migration Guide for Version 5.2.

64-Bit Virtual Managed Devices

You can deploy 64-bit virtual devices as ESXi hosts using the VMware vSphere Hypervisor or vCloud Director environment. You can also enable VMware Tools on all supported ESXi versions. For a list of supported versions, see the FireSIGHT System Virtual Installation Guide. For information on the full functionality of VMware Tools, see the VMware website (http://www.vmware.com/).

Virtual appliances use e1000 (1 Gbit/s) interfaces, or you can use the VMware vSphere Client to replace the default sensing and management interfaces with vmxnet3 (10 Gbit/s) interfaces. You can also use the VMware vSphere Client to create additional management interfaces on the virtual Defense Center. For more information, see the FireSIGHT System Virtual Installation Guide.

Regardless of the licenses installed and applied, virtual appliances do not support any of the system’s hardware-based features: redundancy and resource sharing, switching, routing, and so on. Also, virtual devices do not have a FireSIGHT System web interface.

Cisco NGIPS for Blue Coat X-Series

You can install Cisco NGIPS for Blue Coat X-Series on a Blue Coat X-Series platform. This software-based appliance functions similarly to a virtual managed device. Regardless of the licenses installed and applied, Cisco NGIPS for Blue Coat X-Series does not support any of the following FireSIGHT System features:

- Cisco NGIPS for Blue Coat X-Series does not support features granted by the Malware or Control licenses, including advanced malware protection (AMP), application control, user control, and any of the system’s hardware-based features (clustering, stacking, switching, routing, VPN, NAT, and so on).

- You cannot use Cisco NGIPS for Blue Coat X-Series to decrypt or inspect encrypted traffic (SSL inspection).

- You cannot use Cisco NGIPS for Blue Coat X-Series to filter network traffic based on its country or continent of origin or destination (geolocation-based access control).

- You cannot use the Defense Center web interface to configure Cisco NGIPS for Blue Coat X-Series interfaces.

- You cannot use the Defense Center to shut down, restart, or otherwise manage Cisco NGIPS for Blue Coat X-Series processes.

- You cannot use the Defense Center to create backups from or restore backups to Cisco NGIPS for Blue Coat X-Series.

- You cannot apply health or system policies to Cisco NGIPS for Blue Coat X-Series. This includes managing time settings.

Cisco NGIPS for Blue Coat X-Series does not have a web interface. However, it has a command line interface (CLI) unique to the X-Series platform. You use this CLI to install the system and to perform other platform-specific administrative tasks, such as:

- creating Virtual Appliance Processor (VAP) groups, which allow you to take advantage of the X-Series platform’s load balancing and redundancy benefits (comparable to Cisco physical device clustering)

- configuring passive and inline sensing interfaces, including configuring the interface’s maximum transmission unit (MTU)

- managing processes

- managing time settings, including NTP settings

Cisco ASA with FirePOWER Services

Cisco ASA with FirePOWER Services (ASA FirePOWER devices) functions similarly to a managed device. In this deployment, the ASA device provides the first-line system policy and passes traffic to the FireSIGHT System for access control, intrusion detection and prevention, discovery, and advanced malware protection.

Regardless of the licenses installed and applied, ASA FirePOWER devices do not support any of the following FireSIGHT System features:

- ASA FirePOWER devices do not support the FireSIGHT System’s hardware-based features: clustering, stacking, switching, routing, VPN, NAT, and so on. However, the ASA platform does provide these features, which you can configure using the ASA CLI and ASDM. See the ASA documentation for more information.

- ASA FirePOWER devices do not support SSL inspection.

- You cannot use the Defense Center web interface to configure ASA FirePOWER interfaces.

- You cannot use the Defense Center to shut down, restart, or otherwise manage ASA FirePOWER processes.

- You cannot use the Defense Center to create backups from or restore backups to ASA FirePOWER devices.

- You cannot write access control rules to match traffic using VLAN tag conditions.

The ASA FirePOWER device does not have a FireSIGHT web interface. However, it has software and a command line interface (CLI) unique to the ASA platform. You use these ASA-specific tools to install the system and to perform other platform-specific administrative tasks. For more information, see the ASA FirePOWER module documentation.

You can manage ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5516-X, and ISA 3000 devices as standalone devices or managed devices. You manage standalone ASA FirePOWER modules through ASA FirePOWER Configuration in ASDM and managed ASA FirePOWER modules with a Defense Center. You cannot manage an ASA FirePOWER module with ASDM when the device is registered to a Defense Center.

Note that if you edit an ASA FirePOWER device and switch from multiple context mode to single context mode (or visa versa), the device renames all of its interfaces. You must reconfigure all FireSIGHT System security zones, correlation rules, and related configurations to use the updated ASA FirePOWER interface names.

Note The Defense Center does not display ASA interfaces when the ASA FirePOWER device is deployed in SPAN port mode.

Cisco ISA 3000

The Cisco ISA 3000 is a DIN Rail mounted ruggedized industrial security appliance that provides firewall, threat defense, and VPN services. It is low-power, fan-less, with Gigabit Ethernet and a dedicated management port. There are two SKUs:

• Copper SKU with 4x10/100/1000Base-T with a management port

• Fiber SKU with 2x1GbE SFP and 2x10/100/1000Base-T with a management port.

The Cisco ISA 3000 comes with Cisco ASA firewall protection, combined with industry-leading threat and advanced malware protection.The Cisco ISA 3000 runs Cisco ASA with FirePOWER Services. For more information, see Cisco ASA with FirePOWER Services.

Summary of Supported Capabilities by Managed Device Model

When running Version 5.4.1, FireSIGHT System devices have varying throughputs and capabilities, which depend on model and license.

Note that both Defense Centers and Series 3 devices are in the midst of a branding transition. The Defense Center is also referred to as the FireSIGHT Management Center, and Series 3 devices are also referred to as FirePOWER devices. Product identification numbers for Defense Centers may begin with FS rather than DC. Similarly, product identification numbers for Series 3 devices may begin with FP rather than 3D. The model numbers otherwise remain unchanged. For example, a DC4000 and an FS4000 refer to the same Defense Center.

Although you can use any Version 5.4.1 Defense Center to manage any Version 5.4.1 device, the DC500 (and to a lesser extent, the DC750) supports a restricted set of FireSIGHT System features. For more information, see Summary of Supported Capabilities by Defense Center Model.

The following tables match the major access control and network management capabilities of the system with the managed devices that support those capabilities, and the licenses you must enable. For brief descriptions of these capabilities, see FireSIGHT System Components.

Table 1-1 Supported Access Control Capabilities by Device Model

Feature or Capability

Series 2

Device

Series 3

Device

ASA FirePOWER

Device

Virtual

Device

X-Series

Device

License

access control: basic network control

yes

yes

no VLAN control

yes

yes

Any

access control: literal URLs

no

yes

yes

yes

yes

Any

access control: SSL inspection

no

yes

no

no

no

Any

network discovery: host, user, application

yes

yes

yes

yes

yes

FireSIGHT

access control: geolocation-based filtering

no

yes

yes

yes

no

FireSIGHT

Security Intelligence filtering

no

yes

yes

yes

yes

Protection

intrusion detection and prevention (IPS)

yes

yes

yes

yes

yes

Protection

file control: by file type

yes

yes

yes

yes

yes

Protection

file control: archive file inspection

no

yes

yes

yes

yes

Protection

advanced malware protection (AMP)

no

yes

yes

yes

no

Malware

access control: application control

no

yes

yes

yes

no

Control

access control: user control

no

yes

yes

yes

no

Control

access control: URL filtering by category and reputation

no

yes

yes

yes

yes

URL Filtering

Table 1-2 Supported Administrative and Network Management Capabilities by Device Model

Feature or Capability

Series 2

Device

Series 3

Device

ASA FirePOWER

Device

Virtual

Device

X-Series

Device

License

traffic channels

no

yes

no

no

no

Any

multiple management interfaces

no

yes

no

no

no

Any

link aggregation

no

yes

no

no

no

Any

FireSIGHT System web interface

limited

limited

no

no

no

Any

restricted command line interface (CLI)

no

yes

yes

yes

no

Any

external authentication

yes

yes

no

no

no

Any

connect to an eStreamer client

yes

yes

yes

no

no

Any

Automatic Application Bypass

yes

yes

yes

yes

no

Any

tap mode

no

yes

no

no

no

Any

fast-path rules

no

8000 Series

no

no

no

Any

strict TCP enforcement

no

yes

no

no

no

Protection

bypass mode for inline sets

yes

NetMod/SFP dependent

no

no

no

Protection

malware storage pack

no

yes

no

no

no

Malware

switching, routing, switched and routed aggregate interfaces

no

yes

no

no

no

Control

NAT policies

no

yes

no

no

no

Control

device stacking

no

3D8140

82xx Family

83xx Family

no

no

no

Any

device clustering

no

yes

no

no

X-Series based

Control, except X-Series

clustered stacks

no

3D8140

82xx Family

83xx Family

no

no

no

Control

VPN

no

yes

no

no

no

VPN

Configurations that Restart the Snort Process

The Snort® process always restarts when applying any of the configurations listed below.

Caution Applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic.

Access Control Policy

- apply a policy for the first time

- add or remove a URL category and reputation condition on the URLs tab in an access control rule

- associate an intrusion policy or file policy on the Inspection tab in an access control rule, or subsequently remove the policy by selecting None

Access Control Policy Advanced Setting

- disable Inspect Traffic During Policy Apply under General Settings

- change a value under Files and Malware Settings

- associate an SSL policy under SSL Policy Settings, or subsequently remove the policy by selecting None

- enable or disable adaptive profiles under Detection Enhancement Settings

Security Intelligence

- change a Security Intelligence list, except via the Whitelist Now or Blacklist Now option on the right-click menu

SSL Policy

- add or remove a URL category and reputation condition on the Category tab in an SSL rule

File Policy

- enable or disable archive file inspection

- add a file type or file category to a file rule, or subsequently remove it from the rule

- change a file rule action to or from Detect Files or Block Malware

- enable or disable Store Files in a file rule

Network Analysis Policy

– change the value for an IMAP, POP, or SMTP preprocessor Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth

Device Management

- Routing—add a Series 3 routed interface or virtual router

- VPN—add or remove a VPN

- MTU—change the MTU value (Series 2) or the highest MTU value (Series 3) for a non-management interface

- Device high availability—change a high-availability state sharing option

- AAB— activate AAB

Note Automatic Application Bypass (AAB) is activated only when it is enabled and an excessive amount of time is spent processing a single packet. If AAB engages, the Snort process restarts.

Pre-Apply Updates

- apply an access control or intrusion policy after importing an intrusion rule update that includes a new or updated shared object rule

- apply an access control policy after installing a vulnerability database (VDB) update

System Updates

Installing a system update or patch that includes a binary change. Binary changes can include changes to Snort, a preprocessor, the vulnerability database (VDB), or a shared object rule. Note that in the case of a managed device, a patch that does not include a binary change can sometimes require a Snort restart.

How Snort Restarts Affect Traffic

As seen in the following table, the effect of Snort restarts on traffic depends on the model of the managed device and how the device handles traffic.

Table 1-3 Restart Traffic Affects by Managed Device Model

On this model...

Configured as...

Traffic during restart is...

Series 2, Series 3, virtual

inline, Failsafe enabled or disabled

passed without inspection* (a few packets might drop if Failsafe is disabled and Snort is busy but not down)

passive

uninterrupted, not inspected

3D9900, Series 3

inline, tap mode

uninterrupted, not inspected*

Series 3

routed, switched, transparent

dropped

ASA FirePOWER

routed or transparent with fail-open (Permit Traffic)

passed without inspection

routed or transparent with fail-close (Close Traffic)

dropped

*Series 2 drops traffic when you change the MTU on a sensing interface; otherwise, traffic is handeled as shown

Introduction to the Defense Center

A Defense Center provides a centralized management console and database repository for your FireSIGHT System deployment. Defense Centers aggregate and correlate intrusion, file, malware, discovery, connection, and performance data, assessing the impact of events on particular hosts and tagging hosts with indications of compromise. This allows you to monitor the information that your devices report in relation to one another, and to assess and control the overall activity that occurs on your network. Defense Centers also control the network management features on your devices: switching, routing, NAT, VPN, and so on.

Key features of the Defense Center include:

- device, license, and policy management

- event and contextual information displayed in tables, graphs, and charts

- health and performance monitoring

- external notification and alerting

- correlation, indications of compromise, and remediation features for real-time threat response

- custom and template-based reporting

- a high availability (redundancy) feature to ensure continuity of operations

Series 2 and Series 3 Defense Centers are fault-tolerant, purpose-built physical network appliances available from Cisco. You can also deploy 64-bit virtual Defense Centers as ESXi hosts using the VMware vSphere Hypervisor or vCloud Director environment. Any Defense Center can manage any type of device: physical, virtual, Cisco ASA with FirePOWER Services, and Cisco NGIPS for Blue Coat X-Series.

Defense Centers have a range of device management, event storage, host monitoring, and user monitoring capabilities. Note that because of resource and architecture limitations, the DC500 (and to a lesser extent, the DC750) supports a restricted set of FireSIGHT System features.

Note that both Defense Centers and Series 3 devices are in the midst of a branding transition. The Defense Center is also referred to as the FireSIGHT Management Center, and Series 3 devices are also referred to as FirePOWER devices. Product identification numbers for Defense Centers may begin with FS rather than DC. Similarly, product identification numbers for Series 3 devices may begin with FP rather than 3D. The model numbers otherwise remain unchanged. For example, a DC4000 and an FS4000 refer to the same Defense Center.

Note Although Cisco no longer ships new Series 2 Defense Centers, you can update or reimage them to Version 5.4.1. Note that reimaging results in the loss of almost all configuration and event data on the appliance. For more information, see the FireSIGHT System Installation Guide.

Summary of Supported Capabilities by Defense Center Model

When running Version 5.4.1, all Defense Centers have similar capabilities, with the primary differences being capacity and speed. Defense Center models vary in terms of how many devices they can manage, how many events they can store, and how many hosts and users they can monitor. For more information, see:

- Managing Devices

- Configuring Database Event Limits

- Understanding FireSIGHT Host and User License Limits

Although you can use any Version 5.4.1 Defense Center to manage any Version 5.4.1 device, the DC500 (and to a lesser extent, the DC750) supports a restricted set of FireSIGHT System features. Also, many system capabilities are limited by your devices’ license and model; see Summary of Supported Capabilities by Managed Device Model.

Table 1-4 Supported Access Control Capabilities by Defense Center Model

Feature or Capability

Series 2

Defense Center

Series 3

Defense Center

Virtual

Defense Center

License

manage devices performing simple network-based access control

yes

yes

yes

Any

manage devices performing URL control by literal (manually entered) URL

yes

yes

yes

Any

manage devices performing SSL inspection

yes

yes

yes

Any

collect discovery data (host, application, and user) reported by managed devices and build a network map for your organization

yes

yes

yes

FireSIGHT

enhance discovery with geolocation (country and continent) data, and manage devices performing geolocation-based access control

DC1000, DC3000

yes

yes

FireSIGHT

manage devices performing Security Intelligence filtering (blacklisting)

DC1000, DC3000

yes

yes

Protection

manage an intrusion detection and prevention (IPS) deployment

yes

yes

yes

Protection

manage devices performing simple file control by file type

yes

yes

yes

Protection

manage devices performing archive file inspection

DC1000, DC3000

yes

yes

Protection

manage devices performing application control

yes

yes

yes

Control

manage devices performing user control

DC1000, DC3000

yes

yes

Control

manage devices performing URL filtering by category and reputation

DC1000, DC3000

yes

yes

URL Filtering

manage an advanced malware protection (AMP) deployment and install a malware storage pack

DC1000, DC3000

yes

yes

Malware

receive endpoint-based malware (FireAMP) events from your FireAMP deployment

yes

yes

yes

FireAMP subscription

connect to an eStreamer, host input, or database client

yes

yes

yes

Any

Table 1-5 Supported Network Management and Redundancy Capabilities by Defense Center Model

Feature or Capability

Series 2

Defense Center

Series 3

Defense Center

Virtual

Defense Center

License

separate and manage internal and external traffic using traffic channels

no

yes

yes

Any

isolate and manage traffic on different networks using multiple management interfaces

no

yes

yes

Any

establish Defense Center redundancy (high availability)

DC1000, DC3000

DC1500, DC2000, DC3500, DC4000

no

Any

manage device-based redundancy and resource sharing—stacks, clusters, and clustered stacks

yes

yes

yes

Control

manage devices with hardware-dependent network management features: fast-path rules, strict TCP enforcement, bypass mode, tap mode, switching and routing, NAT, VPN

yes

yes

yes

feature dependent

Defense Centers and Devices Delivered with Version 5.4.X

Table 1-6 Version 5.4.1 FireSIGHT System Defense Centers and Devices

Models/Family

Series

Type

Version 5.4.x

70xx Family:

- 3D7010/7020/7030/7050

Series 3 FirePOWER (7000 Series)

device

Version 5.4.0.x

71xx Family:

- 3D7110/7120

- 3D7115/7125

- AMP7150

Series 3 FirePOWER (7000 Series)

device

Version 5.4.0.x

81xx Family:

- 3D8120/8130/8140

- AMP8150

Series 3 FirePOWER (8000 Series)

device

Version 5.4.0.x

82xx Family:

- 3D8250

- 3D8260/8270/8290

Series 3 FirePOWER (8000 Series)

device

Version 5.4.0.x

83xx Family:

- 3D8350

- 3D8360/8370/8390

- AMP8350

- AMP8360/8370/8390

Series 3 FirePOWER (8000 Series)

device

Version 5.4.0.x

64-bit virtual devices

n/a

device

Version 5.4.0.x

Cisco NGIPS for Blue Coat X-Series

n/a

device

Version 5.4.0.x

ASA FirePOWER:

- ASA5512-X

- ASA5515-X

- ASA5525-X

- ASA5545-X

- ASA5555-X

- ASA5585-X-SSP-10

- ASA5585-X-SSP-20

- ASA5585-X-SSP-40

- ASA5585-X-SSP-60

n/a

device

Version 5.4.0.x

ASA FirePOWER:

- ASA5506-X

- ASA5506H-X

- ASA5506W-X

- ASA5508-X

- ASA5516-X

- ISA 3000

n/a

device

Version 5.4.1.x

Series 3 Defense Centers:

- DC750/1500/3500

- DC2000/4000

Series 3

Defense Center

Version 5.4.1.x

64-bit virtual Defense Centers

n/a

Defense Center

Version 5.4.1.x

Note that both Defense Centers and Series 3 devices are in the midst of a branding transition. The Defense Center is also referred to as the FireSIGHT Management Center, and Series 3 devices are also referred to as FirePOWER devices. Product identification numbers for Defense Centers may begin with FS rather than DC. Similarly, product identification numbers for Series 3 devices may begin with FP rather than 3D. The model numbers otherwise remain unchanged. For example, a DC4000 and an FS4000 refer to the same Defense Center.

Although Cisco no longer ships new Series 2 appliances, you can update or reimage Series 2 devices and Defense Centers running earlier versions of the system to Version 5.4.1. Note that reimaging results in the loss of almost all configuration and event data on the appliance. For more information, see the FireSIGHT System Installation Guide.

Tip You can migrate specific configuration and event data from a Version 4.10.3 deployments to a Version 5.2 deployment, which you can then update to Version 5.4.1. For more information, see the FireSIGHT System Migration Guide for Version 5.2.

FireSIGHT System Components

The topics that follow describe some of the key capabilities of the FireSIGHT System that contribute to your organization’s security, acceptable use policy, and traffic management strategy:

- Redundancy and Resource Sharing

- Network Traffic Management

- FireSIGHT

- Access Control

- SSL Inspection

- Intrusion Detection and Prevention

- Advanced Malware Protection and File Control

- Application Programming Interfaces

Tip Many FireSIGHT System features are appliance model, license, and user role dependent. This documentation includes information about which FireSIGHT System licenses and devices are required for each feature, and which user roles have permission to complete each procedure. For more information, see Documentation Conventions.

Redundancy and Resource Sharing

The redundancy and resource-sharing features of the FireSIGHT System allow you to ensure continuity of operations and to combine the processing resources of multiple physical devices.

Defense Center High Availability

To ensure continuity of operations, a Defense Center high availability feature allows you to designate redundant DC1000, DC1500, DC2000, DC3000, DC3500, or DC4000 Defense Centers to manage devices. Event data streams from managed devices to both Defense Centers; certain configuration elements are maintained on both Defense Centers. If one Defense Center fails, you can monitor your network without interruption using the other Defense Center.

Device Stacking

Device stacking allows you to increase the amount of traffic inspected on a network segment by connecting two to four physical devices in a stacked configuration. When you establish a stacked configuration, you combine the resources of each stacked device into a single, shared configuration.

Device Clustering

Device clustering (sometimes called device high availability) allows you to establish redundancy of networking functionality and configuration data between two or more Series 3 devices or stacks. Clustering two or more peer devices or stacks results in a single logical system for policy applies, system updates, and registration. With device clustering, the system can fail over either manually or automatically.

In most cases, you can achieve Layer 3 redundancy without clustering devices by using SFRP. SFRP allows devices to act as redundant gateways for specified IP addresses. With network redundancy, you can configure two or more devices or stacks to provide identical network connections, ensuring connectivity for other hosts on the network.

Load Balancing with Cisco NGIPS for Blue Coat X-Series

You can take advantage of the X-Series platform’s load balancing and redundancy benefits (comparable to Cisco physical device clustering) by deploying Cisco NGIPS for Blue Coat X-Series as individual VAPs in a multi-member VAP group on the X-Series platform. You then manage these VAP groups using the Defense Center. For more information, see the Cisco NGIPS for Blue Coat X-Series Installation and Configuration Guide.

Network Traffic Management

The FireSIGHT System’s network traffic management features allow managed devices to act as part of your organization’s network infrastructure. You can configure Series 3 devices to serve in a switched, routed, or hybrid (switched and routed) environment; to perform network address translation (NAT); and to build secure virtual private network (VPN) tunnels.

Switching

You can configure the FireSIGHT System in a Layer 2 deployment so that it provides packet switching between two or more network segments. In a Layer 2 deployment, you configure switched interfaces and virtual switches on managed devices to operate as standalone broadcast domains. A virtual switch uses the MAC address from a host to determine where to send packets. You can also group multiple physical interfaces into a single logical link that provides packet switching between two endpoints in your network. The endpoints can be two FirePOWER managed devices, or a FirePOWER managed device connected to a third-party access switch.

Routing

You can configure the FireSIGHT System in a Layer 3 deployment so that it routes traffic between two or more interfaces. In a Layer 3 deployment, you configure routed interfaces and virtual routers on managed devices to receive and forward traffic. The system routes packets by making packet forwarding decisions according to the destination IP address. Routers obtain the destination from the outgoing interface based on the forwarding criteria, and access control rules designate the security policies to apply.

When you configure virtual routers, you can define static routes. In addition, you can configure Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) dynamic routing protocols. You can also configure a combination of static routes and RIP or static routes and OSPF. You can set up DHCP relay for each virtual router you configure.

If you use both virtual switches and virtual routers in your Cisco appliance configuration, you can configure associated hybrid interfaces to bridge traffic between them. These utilities analyze traffic to determine its type and the appropriate response (route, switch, or otherwise). You can also group multiple physical interfaces into a single logical link that routes traffic between two endpoints in your network. The endpoints can be two FirePOWER managed devices, or a FirePOWER managed device connected to a third-party router.

NAT

In a Layer 3 deployment, you can configure network address translation (NAT). You can expose an internal server to an external network, or allow an internal host or server to connect to an external application. You can also configure NAT to hide private network addresses from an external network by using a block of IP addresses, or by using a limited block of IP addresses and port translation.

VPN

A virtual private network (VPN) is a network connection that establishes a secure tunnel between endpoints via a public source, such as the Internet or other network. You can configure the FireSIGHT System to build secure VPN tunnels between the virtual routers of Series 3 devices.

FireSIGHT

FireSIGHT™ is Cisco’s discovery and awareness technology that collects information about hosts, operating systems, applications, users, files, networks, geolocation information, and vulnerabilities, in order to provide you with a complete view of your network.

You can use the Defense Center’s web interface to view and analyze data collected by the system. You can also use this data to help you perform access control and modify intrusion rule states. In addition, you can generate and track indications of compromise on hosts on your network based on correlated event data for the hosts.

Access Control

Access control is a policy-based feature that allows you to specify, inspect, and log the traffic that can traverse your network. An access control policy determines how the system handles traffic on your network.

The simplest access control policy directs its target devices to handle all traffic using its default action. You can set this default action to block or trust all traffic without further inspection, or to inspect traffic for intrusions and discovery data.

A more complex access control policy can blacklist traffic based on Security Intelligence data, as well as use access control rules to exert granular control over network traffic logging and handling. These rules can be simple or complex, matching and inspecting traffic using multiple criteria; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, and user. Advanced access control options include decryption, preprocessing, and performance.

Each access control rule also has an action, which determines whether you monitor, trust, block, or allow matching traffic. When you allow traffic, you can specify that the system first inspect it with intrusion or file policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network.

SSL Inspection

SSL inspection is a policy-based feature that allows you to handle encrypted traffic without decryption, or decrypt encrypted traffic for further access control inspection. You can choose to block a source of untrusted encrypted traffic without decrypting or further analyzing the traffic, or you can choose to not decrypt encrypted traffic and inspect it with access control instead.

For further insight into encrypted traffic, you can use public key certificates and paired private keys you upload to the system to decrypt encrypted traffic traversing your network, then inspect the decrypted traffic with access control as if it was never encrypted. If the system does not block the decrypted traffic post-analysis, it reencrypts the traffic before passing it to the destination host. The system can log details about encrypted connections as it acts on them.

Intrusion Detection and Prevention

Intrusion detection and prevention is the system’s last line of defense before traffic is allowed to its destination. Intrusion policies are defined sets of intrusion detection and prevention configurations invoked by your access control policy. Using intrusion rules and other settings, these policies inspect traffic for security violations and, in inline deployments, can block or alter malicious traffic.

Cisco delivers several intrusion policies with the FireSIGHT System. By using system-provided policies you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states (enabled or disabled), as well as provides the initial configurations for other advanced settings. An enabled rule causes the system to generate intrusion events for (and optionally block) traffic matching the rule.

If the system-provided policies do not fully address the security needs of your organization, custom policies can improve the performance of the system in your environment and can provide a focused view of the malicious traffic and policy violations occurring on your network. By creating and tuning custom policies you can configure, at a very granular level, how the system processes and inspects the traffic on your network for intrusions.

Advanced Malware Protection and File Control

To help you identify and mitigate the effects of malware, the FireSIGHT System’s file control, network file trajectory, and advanced malware protection components can detect, track, capture, analyze, and optionally block the transmission of files (including malware files and nested files inside archive files) in network traffic.

File Control

File control allows managed devices to detect and block your users from uploading (sending) or downloading (receiving) files of specific types over specific application protocols. You configure file control as part of your overall access control configuration; file policies associated with access control rules inspect network traffic that meets rule conditions.

Network-Based Advanced Malware Protection (AMP)

Network-based advanced malware protection (AMP) allows the system to inspect network traffic for malware in several types of files. Appliances can store detected files for further analysis, either to their hard drive or (for some models) a malware storage pack.

Regardless of whether you store a detected file, you can submit it to the Collective Security Intelligence Cloud for a simple known-disposition lookup using the file’s SHA-256 hash value. You can also submit files for dynamic analysis, which produces a threat score. Using this contextual information, you can configure the system to block or allow specific files.

You configure malware protection as part of your overall access control configuration; file policies associated with access control rules inspect network traffic that meets rule conditions.

FireAMP Integration

FireAMP is Cisco’s enterprise-class, advanced malware analysis and protection solution that discovers, understands, and blocks advanced malware outbreaks, advanced persistent threats, and targeted attacks.

If your organization has a FireAMP subscription, individual users install FireAMP Connectors on their computers and mobile devices (also called endpoints). These lightweight agents communicate with the Cisco cloud, which in turn communicates with the Defense Center.

If your organization’s security policy does not allow for the use of a traditional cloud server connection, you can acquire and configure Cisco’s private, on-premises cloud solution, the FireAMP Private Cloud, which is a virtual machine that acts as a compressed, local version of the public Cisco cloud.

After you configure the Defense Center to connect to the cloud, you can use the Defense Center web interface to view endpoint-based malware events generated as a result of scans, detections, and quarantines on the endpoints in your organization. The Defense Center also uses FireAMP data to generate and track indications of compromise on hosts, as well as display network file trajectories.

Use the FireAMP portal (http://amp.sourcefire.com/) to configure your FireAMP deployment. The portal helps you quickly identify and quarantine malware. You can identify outbreaks when they occur, track their trajectories, understand their effects, and learn how to successfully recover. You can also use FireAMP to create custom protections, block execution of certain applications based on group policy, and create custom whitelists.

Network File Trajectory

The network file trajectory feature allows you to track a file’s transmission path across a network. The system uses SHA-256 hash values to track files; so, to track a file, the system must either:

- calculate the file’s SHA-256 hash value and perform a malware cloud lookup using that value

- receive endpoint-based threat and quarantine data about that file, using the Defense Center’s integration with your organization’s FireAMP subscription

Each file has an associated trajectory map, which contains a visual display of the file’s transfers over time as well as additional information about the file.

Application Programming Interfaces

There are several ways to interact with the system using application programming interfaces (APIs). For detailed information, you can download additional documentation from either of the following Support Sites:

- Cisco: (http://www.cisco.com/cisco/web/support/index.html )

eStreamer

The Event Streamer (eStreamer) allows you to stream several kinds of event data from a Cisco appliance to a custom-developed client application. After you create a client application, you can connect it to an eStreamer server (Defense Center or physical managed device), start the eStreamer service, and begin exchanging data.

eStreamer integration requires custom programming, but allows you to request specific data from an appliance. If, for example, you display network host data within one of your network management applications, you could write a program to retrieve host criticality or vulnerability data from the Defense Center and add that information to your display.

External Database Access

The database access feature allows you to query several database tables on a Defense Center, using a third-party client that supports JDBC SSL connections.

You can use an industry-standard reporting tool such as Crystal Reports, Actuate BIRT, or JasperSoft iReport to design and submit queries. Or, you can configure your own custom application to query Cisco data. For example, you could build a servlet to report intrusion and discovery event data periodically or refresh an alert dashboard.

Host Input

The host input feature allows you to augment the information in the network map by importing data from third-party sources using scripts or command-line files.

The web interface also provides some host input functionality; you can modify operating system or application protocol identities, validate or invalidate vulnerabilities, and delete various items from the network map, including clients and server ports.

Remediation

The system includes an API that allows you to create remediations that your Defense Center can automatically launch when conditions on your network violate an associated correlation policy or compliance white list. This can not only automatically mitigate attacks when you are not immediately available to address them, but can also ensure that your system remains compliant with your organization’s security policy. In addition to remediations that you create, the Defense Center ships with several predefined remediation modules.

Documentation Resources

The FireSIGHT System documentation set includes online help and PDF files. You can reach the online help from the web interface in the following ways:

- by clicking the context-sensitive help link on each page

- by selecting Help > Online

The online help includes information about the tasks you can complete using a Defense Center or device’s web interface, including system management, policy management, and event analysis.

You can access the most up-to-date versions of the PDF documentation on either of the following Support Sites:

- Cisco: (http://www.cisco.com/cisco/web/support/index.html )

This documentation includes:

- the FireSIGHT System User Guide , which includes the same content as the online help, but in an easy-to-print format

- the FireSIGHT System Installation Guide , which includes information about installing Cisco appliances as well as hardware specifications and safety information

- the FireSIGHT System Virtual Installation Guide , which includes information about installing, managing, and troubleshooting virtual devices and virtual Defense Centers

- the Cisco NGIPS for Blue Coat X-Series Installation and Configuration Guide , which includes information about installing, managing, and troubleshooting Cisco NGIPS for Blue Coat X-Series

- various API guides and supplementary material

Documentation Conventions

This documentation includes information about which FireSIGHT System licenses and appliance models are required for each feature, and which user roles have permission to complete each procedure. For more information, see the following sections:

- License Conventions

- Supported Device and Defense Center Conventions

- Access Conventions

License Conventions

The License statement at the beginning of a section indicates the license required to use the feature described in the section, as follows:

FireSIGHT

A FireSIGHT license is included with your Defense Center and is required to perform host, application, and user discovery. The FireSIGHT license on your Defense Center determines how many individual hosts and users you can monitor with the Defense Center and its managed devices, as well as how many users you can use to perform user control.

Protection

A Protection license allows managed devices to perform intrusion detection and prevention, file control, and Security Intelligence filtering. This license corresponds to the Protection (TA) subscription, which is automatically included in the purchase of any managed device.

Control

A Control license allows managed devices to perform user and application control. It also allows devices to perform switching and routing (including DHCP relay), NAT, and to cluster devices and stacks. A Control license requires a Protection license. This license is included automatically when you purchase any managed device.

URL Filtering

A URL Filtering license allows managed devices to use regularly updated cloud-based category and reputation data to determine which traffic can traverse your network, based on the URLs requested by monitored hosts. A URL Filtering license requires a Protection license. You can purchase this license as a service subscription combined with Protection (TAC or TAMC) or as an add-on subscription (URL) for a device where Protection (TA) is already enabled.

Malware

A Malware license allows managed devices to perform network-based advanced malware protection (AMP), that is, to detect, capture, and block malware in files transmitted over your network and to submit those files for dynamic analysis. It also allows you to view trajectories, which track files transmitted over your network. A Malware license requires a Protection license. You can purchase the Malware license as a service subscription combined with Protection (TAM or TAMC) or as an add-on subscription (AMP) for a device where Protection (TA) is already enabled.

VPN

A VPN license allows you to build secure VPN tunnels between the virtual routers of Cisco managed devices. A VPN license requires Protection and Control licenses. To purchase a VPN license, contact Sales.

Because licensed capabilities are often additive, this documentation only provides the highest required license for each feature. For example, if a feature requires FireSIGHT, Protection, and Control licenses, only Control is listed.

An “or” statement in a License statement indicates that a particular license is required to use the feature described in the section, but an additional license can add functionality. For example, within a file policy, some file rule actions require a Protection license while others require a Malware license. So, the License statement for the documentation on file rules lists “Protection or Malware.”

Note that because of architecture and resource limitations, not all licenses can be applied to all managed devices. In general, you cannot license a capability that a device does not support; see Summary of Supported Capabilities by Managed Device Model. For more information, see Understanding Licensing.

Supported Device and Defense Center Conventions

The Supported Devices statement at the beginning of a section indicates that a feature is supported only on the specified device series, family, or model. For example, stacking is only supported on Series 3 devices. If a section does not have a Supported Devices statement, the feature is supported on all devices, or the section does not apply to managed devices.

For more information on platforms supported by this release, see Introduction to the Defense Center.

Access Conventions

Table 1-7 Access Conventions

Access Term

Indicates

Access Admin

User must have the Access Control Admin role

Admin

User must have the Administrator role

Any

User can have any role

Any/Admin

User can have any role, but only the Administrator role has unrestricted access (such as the ability to view other users’ data saved as private)

Any Security Analyst

User can have either the Security Analyst or Security Analyst (Read Only) role

Database

User must have the External Database role

Discovery Admin

User must have the Discovery Admin role

Intrusion Admin

User must have the Intrusion Admin role

Maint

User must have the Maintenance User role

Network Admin

User must have the Network Admin role

Security Analyst

User must have the Security Analyst role

Security Approver

User must have the Security Approver role

Users with custom roles may have permission sets that differ from those of the predefined roles. When a predefined role is used to indicate access requirements for a procedure, a custom role with similar permissions also has access. Some users with custom roles may use slightly different menu paths to reach configuration pages. For example, users who have a custom role with only intrusion policy privileges access the network analysis policy via the intrusion policy instead of the standard path through the access control policy. For more information on custom user roles, see Managing Custom User Roles.

IP Address Conventions

You can use IPv4 Classless Inter-Domain Routing (CIDR) notation and the similar IPv6 prefix length notation to define address blocks in many places in the FireSIGHT System.

CIDR notation uses a network IP address combined with a bit mask to define the IP addresses in the specified block of addresses. For example, the following table lists the private IPv4 address spaces in CIDR notation.

Table 1-8 CIDR Notation Syntax Examples

CIDR Block

IP Addresses in CIDR Block

Subnet Mask

Number of IP Addresses

10.0.0.0/8

10.0.0.0 - 10.255.255.255

255.0.0.0

16,777,216

172.16.0.0/12

172.16.0.0 - 172.31.255.255

255.240.0.0

1,048,576

192.168.0.0/16

192.168.0.0 - 192.168.255.255

255.255.0.0

65,536

Similarly, IPv6 uses a network IP address combined with a prefix length to define the IP addresses in a specified block. For example, 2001:db8::/32 specifies the IPv6 addresses in the 2001:db8:: network with a prefix length of 32 bits, that is, 2001:db8:: through 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff.

When you use CIDR or prefix length notation to specify a block of IP addresses, the FireSIGHT System uses only the portion of the network IP address specified by the mask or prefix length. For example, if you type 10.1.2.3/8, the FireSIGHT System uses 10.0.0.0/8.

In other words, although Cisco recommends the standard method of using a network IP address on the bit boundary when using CIDR or prefix length notation, the FireSIGHT System does not require it.

Logging into the FireSIGHT System

This chapter details the steps you must take to log into and log out of the FireSIGHT System, using the appliance-based web interface as well as the command line interface (CLI). You can also configure externally authenticated user accounts that use LDAP or RADIUS credentials.

After you have logged into the web interface, the context menu feature provides extra information and helpful navigation links when you hover your pointer over certain areas.

For more information, see the following sections:

- Logging into the Appliance

- Logging Out of the Appliance

- Using the Context Menu

Logging into the Appliance

License: Any

The FireSIGHT System Defense Center has a web interface that you can use to perform administrative, management, and analysis tasks. Physical managed devices also have a web interface that you can use to perform initial setup and basic analysis and configuration tasks. For information on browser requirements, refer to the release notes for this version of the FireSIGHT System.

Virtual managed devices do not have web interfaces. For these devices (and Series 3 devices as well), the FireSIGHT System provides an interactive CLI that you can use to perform any tasks that you cannot complete using the device’s managing Defense Center.

Cisco NGIPS for Blue Coat X-Series also does not have a web interface. However, it has a CLI unique to the X-Series platform. You use this CLI to install the system and to perform other platform-specific administrative tasks. For more information, including how to log in to the X-Series platform CLI, see the Cisco NGIPS for Blue Coat X-Series Installation and Configuration Guide.

ASA FirePOWER devices have their own management applications (ASDM and CSM) and CLI for configuring the ASA device. In addition, the FireSIGHT System provides an interactive CLI that you can use to perform any tasks that you cannot complete using the device’s managing Defense Center. You use the ASA-specific tools to install the system and to perform other platform-specific administrative tasks. See the ASA documentation for more information.

Note Because FirePOWER appliances audit user activity based on user accounts, make sure that users log into the system with the correct account.

You must provide a username and password to obtain access to the web interface, CLI, or shell of an appliance. After you log into an appliance, the features you can access are controlled by the privileges granted to your user account. For more information, see Managing User Accounts.

Optionally, if your organization uses Common Access Cards (CACs) for authentication, you can use your CAC credentials to obtain access to the web interface of an appliance. For more information about CAC authentication and authorization, see Understanding LDAP Authentication With CAC.

Caution If you supply incorrect credentials multiple times, your shell access account may be locked. If you supply correct credentials and the login is refused, contact your system administrator rather than repeatedly attempting to log in.

The first time you visit the appliance home page during a web session, you can view information about your last login session for that appliance. You can see the following information about your last login:

- the day of the week, month, date, and year of the login

- the appliance-local time of the login in 24-hour notation

- the host and domain name last used to access the appliance

By default, your session automatically logs you out after 1 hour of inactivity, unless you are otherwise configured to be exempt from session timeout. Users with the Administrator role can change the session timeout interval in the system policy. For more information, see Managing User Login Settings and Configuring User Interface Settings.

Note that some processes that take a significant amount of time may cause your web browser to display a message that a script has become unresponsive. If this occurs, make sure you allow the script to continue until it finishes.

Note For fresh installations (new or reimaged) of the system on an appliance, you must log in using the administrative (admin) user account to complete the initial setup process, which is described in the FireSIGHT System Installation Guide. After you create other user accounts as described in Adding New User Accounts, you and other users should use those accounts to log in to the web interface.

Tip You must configure CAC authentication and authorization before users on your network can log in to the CAC Login page using their CAC credentials. For more information, see Understanding LDAP Authentication With CAC.

To log into the appliance via the web interface:

Access: Any

Step 1 Direct your browser to https://hostname/, where hostname corresponds to the host name of the appliance.

The Login page appears.

Step 2 In the Username and Password fields, type your user name and password. User names are case sensitive.

If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use that as your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, type 1111222222. You must have already generated your SecurID PIN before you can log into the FireSIGHT System.

Step 3 Click Login.

The default start page appears. If you selected a custom home page for your user account, that page is displayed instead. See Specifying Your Home Page for more information.

Tip If you do not have access to the web interface, contact your system administrator to modify your account privileges, or log in as a user with Administrator access and modify the privileges for the account. For more information, see Modifying User Privileges and Options.

The menus and menu options listed at the top of the page are based on the privileges for your user account. However, the links on the default home page include options that span the range of user account privileges. If you click a link that requires different privileges from those granted to your account, the following warning message is displayed:

You are attempting to view an unauthorized page. This activity has been logged.

You can either select a different option from the available menus or click Back in your browser window to return to the previous page.

To log into the appliance via the web interface using CAC credentials:

Access: Any

Step 1 Insert a CAC as instructed by your organization.

Step 2 Direct your browser to https://hostname/, where hostname corresponds to the host name of the appliance.

Step 3 If prompted, enter the PIN associated with the CAC you inserted in step 1.

Your PIN is accepted.

Step 4 If prompted, select the appropriate certificate from the drop-down list.

The browser accepts your selection and the CAC Login page appears.

Step 5 To authenticate using your CAC credentials, click Continue.

To authenticate using your user name and password, enter them in the Username and Password fields. User names are case sensitive.

The default start page appears. If you selected a custom home page for your user account, that page is displayed instead. See Specifying Your Home Page for more information.

Tip If you do not have access to the web interface, contact your system administrator to modify your account privileges, or log in as a user with Administrator access and modify the privileges for the account. For more information, see Modifying User Privileges and Options.

The menus and menu options listed at the top of the page are based on the privileges for your user account. However, the links on the default home page include options that span the range of user account privileges. If you click a link that requires different privileges from those granted to your account, the following warning message is displayed:

You are attempting to view an unauthorized page. This activity has been logged.

You can either select a different option from the available menus or click Back in your browser window to return to the previous page.

Note Do not remove a CAC during an active browsing session. If you remove or replace a CAC during a session, your web browser terminates the session and the system logs you out of the web interface.

To log into a Series 3, virtual, or ASA FirePOWER device via the command line:

Access: CLI Basic Configuration

Step 1 For Series 3 and virtual devices, open an SSH connection to the appliance at hostname, where hostname corresponds to the host name of the appliance. For ASA FirePOWER devices, open the SSH connection to the ASA FirePOWER module at the management address.

The login as: command prompt appears.

Step 2 Type your user name and press Enter.

The Password: prompt appears.

Step 3 Type your password and press Enter.

If your organization uses SecurID® tokens when logging in, append the token to your SecurID PIN and use that as your password to log in. For example, if your PIN is 1111 and the SecurID token is 222222, type 1111222222. You must have already generated your SecurID PIN before you can log into the FireSIGHT System.

The login banner appears, followed by the > prompt.

You can use any of the commands allowed by your level of command line access. See the Command Line Reference for more information on available CLI commands.

Logging Out of the Appliance

License: Any

When you are no longer actively using the web interface, Cisco recommends that you log out, even if you are only stepping away from your web browser for a short period of time. Logging out ends your web session and ensures that no one can use the appliance with your credentials.

By default, your session automatically logs you out after 1 hour of inactivity, unless you are otherwise configured to be exempt from session timeout. Users with the Administrator role can change the session timeout interval in the system policy. For more information, see Managing User Login Settings and Configuring User Interface Settings.

To log out of the appliance:

Access: Any

Step 1 Click Logout on the toolbar.

Using the Context Menu

License: feature dependent

For your convenience, certain pages in the web interface support a pop-up context menu that you can use as a shortcut for accessing other features in the FireSIGHT System. The contents of the menu depend on the hotspot where you access it—not only the page but also the specific data.

For example, IP address hotspots in event views, intrusion event packet views, the dashboard, and the Context Explorer provide additional options. Use the IP address context menu by right-clicking on the hotspot to learn more about the host associated with that address, including any available whois and host profile information. Except on the DC500 Defense Center, which does not support Security Intelligence filtering, you can also add an individual IP address to the Security Intelligence global whitelist or blacklist.

As another example, SHA-256 value hotspots in event views and the dashboard allow you to add a file’s SHA-256 hash value to the clean list or custom detection list, or view the entire hash value for copying. Note that this functionality is also not supported on the DC500 Defense Center.

The following list describes many of the options available in the context menu on various pages of the web interface. On pages or locations where the Cisco context menu is not supported, the normal context menu for your browser appears.

Access Control, SSL, and NAT Policy Editors

The access control, SSL, and NAT policy editors contain hotspots over each rule. You can use the context menu to insert new rules and categories; cut, copy, and paste rules; set the rule state; and edit the rule.

Intrusion Rule Editor

The intrusion rule editor contains hotspots over each intrusion rule. You can use the context menu to edit the rule, set the rule state (including disabling the rule), configure thresholding and suppression options, and view rule documentation.

Event Viewer

Event pages (drill-down pages and table views) contain hotspots over each event, IP address, and certain detected files’ SHA-256 hash values. For most event types, you can use the context menu to view related information in the Context Explorer, or drill down into event information in a new window. In places where an event field contains text too long to fully display in the event view, such as a file’s SHA-256 hash value, a vulnerability description, or a URL, you can use the context menu to view the full text.

For captured files, file events, and malware events, you can use the context menu to add a file to or remove a file from the clean list or custom detection list, download a copy of the file, view nested files inside an archive file, download the parent archive file for a nested file, or submit the file to the Collective Security Intelligence Cloud for dynamic analysis.

For intrusion events, you can use the context menu to perform similar tasks to those in the intrusion rule editor or an intrusion policy: edit the triggering rule, set the rule state (including disabling the rule), configure thresholding and suppression options, and view rule documentation.

Packet View

Intrusion event packet views contain IP address hotspots. Note that the packet view uses a left-click context menu instead of a right-click menu.

Dashboard

Many dashboard widgets contain hotspots to view related information in the Context Explorer. Dashboard widgets can also contain IP address and SHA-256 value hotspots.

Context Explorer

The Context Explorer contains hotspots over its charts, tables, and graphs. If you want to examine data from graphs or lists in more detail than the Context Explorer allows, you can drill down to the table views of the relevant data. You can also view related host, user, application, file, and intrusion rule information.

Note that the Context Explorer uses a left-click context menu, which also contains filtering and other options unique to the Context Explorer. For detailed information, see Drilling Down on Context Explorer Data.

To access the context menu:

Access: Any

Step 1 On a hotspot-enabled page in the web interface, hover your pointer over a hotspot.

Except in the Context Explorer, a Right-click for menu message appears.

Step 2 Invoke the context menu:

- In the Context Explorer or packet view, left-click your pointing device.

- On all other hotspot-enabled pages, right-click your pointing device.

A pop-up context menu appears with options appropriate for the hotspot.

Step 3 Select one of the options by left-clicking the name of the option.

If you are using the access control policy editor or NAT policy editor, the rule is modified. Otherwise, a new browser window opens based on the option you selected.

Managing Reusable Objects

For increased flexibility and web interface ease-of-use, the FireSIGHT System allows you to create named objects, which are reusable configurations that associate a name with a value so that when you want to use that value, you can use the named object instead.

You can create the following types of objects:

- network-based objects that represent IP addresses and networks, port/protocol pairs, VLAN tags, security zones, and origin/destination country (geolocation)

- reputation-based objects that represent Security intelligence feeds and lists, application filters based on category and reputation, and file lists

- non-reputation-based objects such as URL categories

- intrusion policy variable sets that contain variables you associate with an intrusion policy

- objects that help you handle encrypted traffic, including cipher suites, public key certificates and paired private keys, and certificate distinguished names

You can use these objects in various places in the system’s web interface, including access control policies, network analysis policies, intrusion policies and rules, network discovery rules, event searches, reports, dashboards, and so on.

Grouping objects allows you to reference multiple objects with a single configuration. You can group network, port, VLAN tag, URL, and public key infrastructure (PKI) objects.

Note In most cases, editing an object used in a policy requires a policy reapply for your changes to take effect. Editing a security zone also requires that you reapply the appropriate device configurations.

For more information, see the following sections:

- Using the Object Manager

- Working with Network Objects

- Working with Security Intelligence Lists and Feeds

- Working with Port Objects

- Working with VLAN Tag Objects

- Working with URL Objects

- Working with Application Filters

- Working with Variable Sets

- Working with File Lists

- Working with Security Zones

- Working with Cipher Suite Lists

- Working with Distinguished Name Objects

- Working with PKI Objects

- Working with Geolocation Objects

Using the Object Manager

License: Any

Create and manage objects, including application filters, variable sets, and security zones, using the object manager (Objects > Object Management). You can group network, port, VLAN tag, URL, and PKI objects; you can also sort, filter, and browse the list of objects and object groups.

For more information, see:

- Grouping Objects

- Browsing, Sorting, and Filtering Objects

Grouping Objects

License: Any

You can group network, port, VLAN tag, URL, and PKI objects. The system allows you to use objects and object groups interchangeably in the web interface. For example, anywhere you would use a port object, you can also use a port object group. Objects and object groups of the same type cannot have the same name.

Tip To group cipher suites, configure a cipher suite list. For more information, see Working with Cipher Suite Lists.

When you edit an object group used in a policy (for example, a network object group used in an access control policy), you must reapply the policy for your changes to take effect.

Deleting a group does not delete the objects in the group, just their association with each other. Additionally, you cannot delete a group that is in use. For example, you cannot delete a VLAN tag group that you are using in a VLAN condition in a saved access control policy.

To group reusable objects:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 You have the following options:

- Under the type of Network , Port , VLAN Tag , URL , or Distinguished Name object you want to group, select Object Groups .

- Under PKI , select Internal CA Groups , Trusted CA Groups , Internal Cert Groups , or External Cert Groups for the type of PKI object you want to group.

The page for the type of object you are grouping appears.

Step 3 Click the Add button that corresponds with the object you want to group.

A pop-up window appears where you can create the group.

Step 4 Type a Name for the group. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Select one or more objects and click Add.

- Use Shift and Ctrl to select multiple objects, or right-click and Select All .

- Use the filter field

to search for existing objects to include, which updates as you type to display matching items. Click the reload icon above the search field or click the clear icon ( ) in the search field to clear the search string.

- Click the add icon [

] to create objects on the fly if no existing objects meet your needs.

Step 6 Click Save.

The group is created.

Browsing, Sorting, and Filtering Objects

License: Any

) to refresh your view.

) arrow next to a column heading indicates that the page is sorted by that column in that direction. You can also filter the objects on the page by name. For some object types, the same filter will match on either the name or the value.

To sort objects or groups:

Access: Admin/Access Admin/Network Admin

Step 1 Click a column heading. To sort in the opposite direction, click the heading again.

To filter objects or groups:

Access: Admin/Access Admin/Network Admin

Step 1 Type your filter criteria in the Filter field.

The page updates as you type to display matching items. You can use the following metacharacters:

- The asterisk [ * ] matches zero or more occurrences of a character.

- The caret ( ^ ) matches content at the beginning of a string.

- The dollar sign ( $ ) matches content at the end of a string.

Working with Network Objects

License: Any

A network object represents one or more IP addresses that you can specify either individually or as address blocks. You can use network objects and groups (see Grouping Objects) in various places in the system’s web interface, including access control policies, network variables, intrusion rules, network discovery rules, event searches, reports, and so on.

You also cannot delete a network object that is in use. Additionally, after you edit a network object used in an access control, network discovery, or intrusion policy, you must reapply the policy for your changes to take effect.

To create a network object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under Network, select Individual Objects.

Step 3 Click Add Network.

The Network Objects pop-up window appears.

Step 4 Type a Name for the network object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 For each IP address or address block you want to add to the network object, type its value and click Add.

Step 6 Click Save.

The network object is added.

Working with Security Intelligence Lists and Feeds

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

The Security Intelligence feature allows you to, per access control policy, specify the traffic that can traverse your network based on the source or destination IP address. This is especially useful if you want to blacklist — deny traffic to and from — specific IP addresses, before the traffic is subjected to analysis by access control rules. Similarly, you can add IP addresses to the whitelist to force the system to handle their connections using access control.

If you are not sure whether you want to blacklist a particular IP address, you can use a “monitor-only” setting, which allows the system to handle the connection using access control, but also logs the connection’s match to the blacklist.

A global whitelist and global blacklist are included by default in every access control policy, and apply to any zone. Additionally, within each access control policy, you can build a separate whitelist and blacklist using a combination of network objects and groups as well as Security Intelligence lists and feeds, all of which you can constrain by security zone.

Note Although they have all other Protection capabilities by default, Series 2 devices cannot perform Security Intelligence filtering.

Comparing Feeds and Lists

A Security Intelligence feed is a dynamic collection of IP addresses that the Defense Center downloads from an HTTP or HTTPS server at the interval you configure. Because feeds are regularly updated, the system can use up-to-date information to filter your network traffic. To help you build blacklists, Cisco provides the Intelligence Feed (sometimes called the Sourcefire Intelligence Feed), which represents IP addresses determined by the Cisco VRT to have a poor reputation.

When the Defense Center downloads updated feed information, it automatically updates its managed devices. Although it may take a few minutes for a feed update to take effect throughout your deployment, you do not have to reapply access control policies after you create or modify a feed, or after a scheduled feed update.

Note If you want strict control over when the Defense Center downloads a feed from the Internet, you can disable automatic updates for that feed. However, Cisco recommends that you allow automatic updates. Although you can manually perform on-demand updates, allowing the system to download feeds on a regular basis provides you with the most up-to-date, relevant data.

A Security Intelligence list, contrasted with a feed, is a simple static list of IP addresses that you manually upload to the Defense Center. Use custom lists to augment and fine-tune feeds and the global whitelist and blacklist. Note that editing custom lists (as well as editing network objects and removing IP addresses from the global whitelist or blacklist) require an access control policy apply for your changes to take effect.

Formatting and Corrupt Feed Data

Feed and list source must be a simple text file no larger than 500MB, with one IP address or address block per line. Comment lines must start with the # character. List source files must use the .txt extension.

If the Defense Center downloads a corrupt feed or a feed with no recognizable IP addresses, the system continues using the old feed data (unless it is the first download). However, if the system can recognize even one IP address in the feed, the Defense Center updates its managed devices with the addresses it can recognize.

The default health policy includes the Security Intelligence module, which alerts in a few situations involving Security Intelligence filtering, including if the Defense Center cannot update a feed, or if a feed is corrupt or contains no recognizable IP addresses.

Internet Access and High Availability

The system uses port 443/HTTPS to download the Intelligence Feed, and either 443/HTTP or 80/HTTP to download custom or third-party feeds. To update feeds, you must open the appropriate port, both inbound and outbound, on the Defense Center. If your Defense Center does not have direct access to the feed site, it can use a proxy server (see Configuring Management Interfaces).

Note The Defense Center does not perform peer SSL certificate verification when downloading custom feeds, nor does the system support the use of certificate bundles or self-signed certificates to verify the remote peer.

Although Security Intelligence objects are synchronized between Defense Centers in a high availability deployment, only the primary Defense Center downloads feed updates. If the primary Defense Center fails, you must not only make sure that the secondary Defense Center has access to the feed sites, but also use the web interface on the secondary Defense Center to promote it to Active. For more information, see Monitoring and Changing High Availability Status.

Managing Feeds and Lists

You create and manage Security Intelligence lists and feeds, collectively called Security Intelligence objects, using the object manager’s Security Intelligence page. (For information on creating and managing network objects and groups, see Working with Network Objects.)

Note that you cannot delete a custom list or feed that is currently being used in a saved or applied access control policy. You also cannot delete a global list, although you can remove individual IP addresses. Similarly, although you cannot delete the Intelligence Feed, editing it allows you to disable or change the frequency of its updates.

Security Intelligence Object Quick Reference

Table 3-1 Security Intelligence Object Capabilities

Capability

Global Whitelist or Blacklist

Intelligence Feed

Custom Feed

Custom List

Network Object

method of use

in access control policies by default

in any access control policy as either a whitelist or blacklist object

can be constrained by security zone?

no

yes

yes

yes

yes

can be deleted?

no

no

yes, unless currently being used in a saved or applied access control policy

object manager edit capabilities

delete IP addresses only (add IP addresses using the context menu)

disable or change update frequency

fully modify

upload a modified list only

fully modify

requires access policy control reapply when modified?

yes when deleting (adding IP addresses does not require reapply)

no

no

yes

yes

For more information on creating, managing, and using Security Intelligence lists and feeds, see:

- Working with the Global Whitelist and Blacklist

- Working with the Intelligence Feed

- Working with Custom Security Intelligence Feeds

- Manually Updating Security Intelligence Feeds

- Working with Custom Security Intelligence Lists

- Blacklisting Using Security Intelligence IP Address Reputation

Working with the Global Whitelist and Blacklist

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

In the course of your analysis, you can build a Security Intelligence global blacklist by using the IP address context menu in an event view, the Context Explorer, or a dashboard. For example, if you notice a set of routable IP addresses in intrusion events associated with exploit attempts, you can immediately blacklist those IP addresses. You can also build a global whitelist in a similar fashion.

The system’s global whitelist and blacklist are included by default in every access control policy, and apply to any zone. You can opt not to use these global lists on a per-policy basis.

When you add an IP address to a global list, the Defense Center automatically updates its managed devices. Although it may take a few minutes for your changes to take effect throughout your deployment, you do not have to reapply access control policies after adding an IP address to a global list. Conversely, after you delete IP addresses from the global whitelist or blacklist, you must apply your access control policies for your changes to take effect.

Note that although you can add network objects with a netmask of /0 to the whitelist or blacklist, address blocks using a /0 netmask in those objects will be ignored and whitelist and blacklist filtering will not occur based on those addresses. Address blocks with a /0 netmask from Security Intelligence feeds will also be ignored. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor or Block rule action, respectively, and a default value of any for the Source Networks and Destination Networks, instead of security intelligence filtering.

Because adding an IP address to the global whitelist or blacklist affects access control, you must have one of the following:

- Administrator access

- a combination of default roles: Network Admin or Access Admin, plus Security Analyst and Security Approver

- a custom role with both Modify Access Control Policy and Apply Access Control Policy permissions; see Managing Your Deployment with Custom User Roles

To add an IP address to the global whitelist or blacklist using the context menu:

Access: Admin/Custom

Step 1 In an event view, packet view, the Context Explorer, or a dashboard, hover your pointer over an IP address hotspot.

Step 2 Invoke the context menu:

- In an event view or dashboard, right-click.

- In the Context Explorer or packet view, left-click.

Step 3 From the context menu, select either Whitelist Now or Blacklist Now.

For information on the other options in the context menu, see Using the Context Menu.

Step 4 Confirm that you want to whitelist or blacklist the IP address.

After the Defense Center communicates your addition to its managed devices, your deployment begins filtering traffic according to your change.

To remove IP addresses from the global whitelist or blacklist:

Access: Admin/Network Admin

).

The Global Whitelist or Global Blacklist pop-up window appears.

).

To delete multiple IP addresses at once, use the Shift and Ctrl keys to select them, then right-click and select Delete.

Step 3 Click Save.

Your changes are saved, but you must apply your access control policies for them to take effect

Working with the Intelligence Feed

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

To help you build blacklists, Cisco provides the Intelligence Feed (sometimes called the Sourcefire Intelligence Feed), which is comprised of several regularly updated lists of IP addresses determined by the VRT to have a poor reputation. Each list in the Intelligence Feed represents a specific category: open relays, known attackers, bogus IP addresses (bogon), and so on. In an access control policy, you can blacklist any or all of the categories.

Because the Intelligence Feed is regularly updated, the system can use up-to-date information to filter your network traffic. Malicious IP addresses that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and apply new policies.

Although you cannot delete the Intelligence Feed, editing it allows you to change the frequency of its updates. By default, the feed updates every two hours.

To modify the Intelligence Feed’s update frequency:

Access: Admin/Network Admin

).

The Sourcefire Security Intelligence pop-up window appears.

Step 2 Edit the Update Frequency.

You can select from various intervals from two hours to one week. You can also disable feed updates.

Step 3 Click Save.

Your changes are saved.

Working with Custom Security Intelligence Feeds

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Custom or third-party Security Intelligence feeds allow you to augment the Intelligence Feed with other regularly-updated reputable whitelists and blacklists on the Internet. You can also set up an internal feed, which is useful if you want to update multiple Defense Centers in your deployment using one source list.

When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded. By default, the Defense Center downloads the entire feed source on the interval you configure, then automatically updates its managed devices.

Optionally, you can configure the system to use an md5 checksum to determine whether to download an updated feed. If the checksum has not changed since the last time the Defense Center downloaded the feed, the system does not need to re-download it. You may want to use md5 checksums for internal feeds, especially if they are large. The md5 checksum must be stored in a simple text file with only the checksum. Comments are not supported.

To configure a Security Intelligence feed:

Access: Admin/Intrusion Admin

Step 1 On the object manager’s Security Intelligence page, click Add Security Intelligence.

The Security Intelligence pop-up window appears.

Step 2 Type a Name for the feed. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 3 From the Type drop-down list, specify that you want to configure a Feed.

The pop-up window updates with new options.

Step 4 Specify a Feed URL and optionally, an MD5 URL.

Step 5 Select an Update Frequency.

You can select from various intervals from two hours to one week. You can also disable feed updates.

Step 6 Click Save.

The Security Intelligence feed object is created. Unless you disabled feed updates, the Defense Center attempts to download and verify the feed. You can now use the feed object in access control policies.

Manually Updating Security Intelligence Feeds

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Manually updating Security Intelligence feeds updates all feeds, including the Intelligence Feed.

To update all Security Intelligence feeds:

Access: Admin/Access Admin/Network Admin

Step 1 On the object manager’s Security Intelligence page, click Update Feeds.

Step 2 Confirm that you want to update all feeds.

A confirmation dialog appears, warning you that it can take several minutes for the update to take effect.

Step 3 Click OK.

After the Defense Center downloads and verifies the feed updates, it communicates any changes to its managed devices. Your deployment begins filtering traffic using the updated feeds.

Working with Custom Security Intelligence Lists

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

A Security Intelligence list is a simple static list of IP addresses and address blocks that you manually upload to the Defense Center. Custom lists are useful if you want to augment and fine-tune feeds or one of the global lists, for a single Defense Center’s managed devices.

Note that netmasks for address blocks can be integers from 0 to 32 or 0 to 128, for IPv4 and IPv6, respectively.

For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your organization, you can create a custom whitelist that contains only the improperly classified IP addresses, rather than removing the Security Intelligence feed object from the access control policy’s blacklist.

Note that to modify a Security Intelligence list, you must make your changes to the source file and upload a new copy. For more information, see Updating a Security Intelligence List.

To upload a new Security Intelligence list to the Defense Center:

Access: Admin/Access Admin/Network Admin

Step 1 On the object manager’s Security Intelligence page, click Add Security Intelligence.

The Security Intelligence pop-up window appears.

Step 2 Type a Name for the list. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 3 From the Type drop-down list, specify that you want to upload a List.

The pop-up window updates with new options.

Step 4 Click Browse to browse to the list .txt file, then click Upload.

The list is uploaded. The pop-up window displays the total number of IP addresses and address blocks that the system found in the list.

If the number is not what you expected, check the formatting of the file and try again.

Step 5 Click Save.

The Security Intelligence list object is saved. You can now use it in access control policies.

Updating a Security Intelligence List

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

To edit a Security Intelligence list, you must make your changes to the source file and upload a new copy. You cannot modify the file’s contents using the Defense Center web interface. If you do not have access to the source file, you can download a copy from the Defense Center.

To modify a Security Intelligence list:

Access: Admin/Access Admin/Network Admin

).

The Security Intelligence pop-up window appears.

Step 2 If you need a copy of the list to edit, click Download, then follow your browser’s prompts to save the list as a text file.

Step 3 Make changes to the list as necessary.

Step 4 On the Security Intelligence pop-up window, click Browse to browse to the modified list, then click Upload.

The list is uploaded.

Step 5 Click Save.

Your changes are saved. If the list is being used by an active access control policy, you must apply the policy for your changes to take effect.

Working with Port Objects

License: Any

Port objects represent different protocols in slightly different ways:

- For TCP and UDP, a port object represents the transport layer protocol, with the protocol number in parentheses, plus an optional associated port or port range. For example: TCP(6)/22 .

- For ICMP and ICMPv6 (IPv6-ICMP), the port object represents the Internet layer protocol plus an optional type and code. For example: ICMP(1):3:3 .

- A port object can also represent other protocols that do not use ports.

Note that Cisco provides default port objects for well-known ports. You can modify or delete these objects, but Cisco recommends that you create custom port objects instead.

You can use port objects and groups (see Grouping Objects) in various places in the system’s web interface, including access control policies, network discovery rules, port variables, and event searches. For example, if your organization uses a custom client that uses a specific range of ports and causes the system to generate excessive and misleading events, you can configure your network discovery policy to exclude monitoring those ports.

You cannot delete a port object that is in use. Additionally, after you edit a port object used in an access control or network discovery policy, you must reapply the policy for your changes to take effect.

Note that you cannot add any protocol other than TCP or UDP for source port conditions in access control rules. Also, you cannot mix transport protocols when setting both source and destination port conditions in a rule.

If you add an unsupported protocol to a port object group used in a source port condition, the rule where it is used does not apply to the managed device on policy apply. Additionally, if you create a port object containing both TCP and UDP ports, then add it as a source port condition in a rule, you cannot add a destination port, and vice versa.

To create a port object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under Port, select Individual Objects.

Step 3 Click Add Port.

The Port Objects pop-up window appears.

Step 4 Type a Name for the port object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Select a Protocol.

You can quickly select TCP, UDP, IP, ICMP, or IPv6-ICMP, or you can use the Other drop-down list to select either a different protocol or All protocols.

Step 6 Optionally, restrict a TCP or UDP port object using a Port or port range.

You can specify any port from 1 to 65535 or any to match all ports. Use a hyphen to specify a range of ports.

Step 7 Optionally, restrict an ICMP or IPV6-ICMP port object using a Type and, if appropriate, a related Code.

When you create an ICMP or IPv6-ICMP object, you can specify the type and, if applicable, the code. For more information on ICMP types and codes, see:

- http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

- http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml

You can set the type to any to match any type or set the code to any to match any code for the specified type.

Step 8 Optionally, select Other and a protocol from the drop-down list. If you select All protocols, type a port number in the Port field.

Step 9 Click Save.

The port object is added.

Working with VLAN Tag Objects

License: Any

Each VLAN tag object you configure represents a VLAN tag or range of tags. You can use VLAN tag objects and groups (see Grouping Objects) in various places in the system’s web interface, including access control policies and event searches. For example, you could write an access control rule that applies only to a specific VLAN.

You cannot delete a VLAN tag object that is in use. Additionally, after you edit a VLAN tag object used in an access control policy, you must reapply the policy for your changes to take effect.

To add a VLAN tag object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under VLAN Tag, select Individual Objects.

Step 3 Click Add VLAN Tag.

The VLAN Tag pop-up window appears.

Step 4 Type a Name for the VLAN tag. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 In the VLAN Tag field, type a value for the VLAN tag.

You can specify any VLAN tag from 1 to 4094. Use a hyphen to specify a range of VLAN tags.

Step 6 Click Save.

The VLAN tag object is added.

Working with URL Objects

License: Any

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Each URL object you configure represents a single URL or IP address. You can use URL objects and groups (see Grouping Objects) in various places in the system’s web interface, including access control policies and event searches. For example, you could write an access control rule that blocks a specific website.

When creating URL objects, especially if you do not configure SSL inspection to decrypt or block encrypted traffic, keep the following points in mind:

- If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using the subject common name in the public key certificate used to encrypt the traffic. Also, the system disregards subdomains within the subject common name, so do not include subdomain information. For example, use example.com rather than www.example.com.

- When matching web traffic using access control rules with URL conditions, the system disregards the encryption protocol (HTTP vs HTTPS). In other words, if you block a website, both HTTP and HTTPS traffic to that website is blocked, unless you use an application condition to refine the rule. When creating a URL object, you do not need to specify the protocol when creating an object. For example, use example.com rather than http://example.com/ .

For more information, see Understanding Traffic Decryption and Blocking URLs.

You cannot delete a URL object that is in use. Additionally, after you edit a URL object used in an access control policy, you must reapply the policy for your changes to take effect.

To add a URL object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under URL, select Individual Objects.

Step 3 Click Add URL.

The URL Objects pop-up window appears.

Step 4 Type a Name for the URL object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Type the URL or IP address for the URL object. You cannot use wildcards (*) in this field.

Step 6 Click Save.

The URL object is added.

Working with Application Filters

License: FireSIGHT

Supported Devices: Any except Series 2

When the FireSIGHT System analyzes IP traffic, it attempts to identify the commonly used applications on your network. Application awareness is crucial to performing application-based access control. The system is delivered with detectors for many applications, and Cisco frequently updates and adds additional detectors via system and vulnerability database (VDB) updates. You can also create your own application protocol detectors to enhance the system’s detection capabilities.

Application filters group applications according to criteria associated with the applications’ risk, business relevance, type, categories, and tags; see Table 45-2. When you create an application protocol detector, you must characterize the application using those criteria as well. Using application filters allows you to quickly create application conditions for access control rules because you do not have to search for and add applications individually; for more information, see Matching Traffic with Application Filters.

Another advantage to using application filters is that you do not have to update access control rules that use filters when you modify or add new applications. For example, if you configure your access control policy to block all social networking applications, and a VDB update includes a new social networking application detector, the policy is updated when you update the VDB. Although you must reapply the policy before the system can block the new application, you do not have to update the access control rule that blocks the application.

If the Cisco-provided application filters do not group applications according to your needs, you can create your own filters. User-defined filters can group and combine Cisco-provided filters. For example, you could create a filter that would allow you to block all very high risk, low business relevance applications. You can also create a filter by manually specifying individual applications, although you should keep in mind those filters do not automatically update when you update the system software or the VDB.

As with Cisco-provided application filters, you can use user-defined application filters in access control rules. You can also use user-defined filters in the following additional ways:

- To search for applications using the event viewer; see Using Objects and Application Filters in Searches

- To constrain a table view in a report template; see Working with Searches in Report Template Sections

- To filter application statistics in a Custom Analysis dashboard widget; see Configuring the Custom Analysis Widget

You use the object manager (Objects > Object Management) to create and manage application filters. Note that you can also create an application filter on the fly while adding an application condition to an access control rule.

The Application Filters list contains the Cisco-provided application filters that you can select to build your own filter. You can constrain the filters that appear by using a search string; this is especially useful for categories and tags.

The Available Applications list contains the individual applications in the filters you select. You can also constrain the applications that appear by using a search string.

The system links multiple filters of the same filter type with an OR operation. Consider a scenario where the medium risk filter contains 100 applications and the high risk filter contains 50 applications. If you select both filters, the system would display 150 available applications.

The system links different types of filters with an AND operation. For example, if you select the medium and high risk filters and the medium and high business relevance filters, the system displays the applications that have medium or high risk, and also have medium or high business relevance.

After you determine the applications you want to add to the filter, you can add them either individually, or, if you selected an application filter, All apps matching the filter. You can add multiple filters and multiple applications, in any combination, as long as the total number of items in the Selected Applications and Filters list does not exceed 50.

After you create the application filter, it is listed on the Application Filters page of the object manager. The page displays the total number of conditions that comprise each filter.

For information on sorting and filtering the application filters that appear, see Using the Object Manager. Note that you cannot delete an application filter that is in use. Additionally, after you edit an application filter used in an access control policy, you must reapply the policy for your changes to take effect.

To create an application filter:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Click Application Filters.

The Application Filters section appears.

Step 3 Click Add Application Filter.

The Application Filter pop-up window appears.

Step 4 Give the filter a Name. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Optionally, use Cisco-provided filters in the Application Filters list to narrow the list of applications you want to add to the filter:

- Click the arrow next to each filter type to expand and collapse the list.

- Right-click a filter type and click Check All or Uncheck All . Note that the list indicates how many filters you have selected of each type.

- To narrow the filters that appear, type a search string in the Search by name field; this is especially useful for categories and tags. To clear the search, click the clear icon —

.

- To refresh the filters list and clear any selected filters, click the reload icon (

).

- To clear all filters and search fields, click Clear All Filters .

The applications that match the filters you select appear in the Available Applications list. The list displays 100 applications at a time.

Step 6 Select the applications that you want to add to the filter from the Available Applications list:

- Select All apps matching the filter to add all the applications that meet the constraints you specified in the previous step.

- To narrow the individual applications that appear, type a search string in the Search by name field. To clear the search, click the clear icon (

).

- Use the paging icons at the bottom of the list to browse the list of individual available applications.

- Use Shift and Ctrl keys to select multiple individual applications. Right-click to Select All currently displayed individual applications.

- To refresh the applications list and clear any selected applications, click the reload icon (

).

You cannot select individual applications and All apps matching the filter at the same time.

Step 7 Add the selected applications to the filter. You can click and drag, or you can click Add to Rule.

The result is the combination of:

- the selected Application Filters

- either the selected individual Available Applications, or All apps matching the filter

.

Step 8 Click Save.

The application filter is saved.

Working with Variable Sets

License: Protection

Variables represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions, adaptive profiles, and dynamic rule states.

Tip Preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion rules.

You use variable sets to manage, customize, and group your variables. You can use the default variable set provided by Cisco or create your own custom sets. Within any set you can modify predefined default variables and add and modify user-defined variables.

Most of the shared object rules and standard text rules that the FireSIGHT System provides use predefined default variables to define networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network. In addition, specialized rules often use other predefined variables. For example, rules that detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.

Rules are more effective when variables more accurately reflect your network environment. At a minimum, you should modify default variables in the default set as described in Optimizing Predefined Default Variables. By ensuring that a variable such as $HOME_NET correctly defines your network and $HTTP_SERVERS includes all web servers on your network, processing is optimized and all relevant systems are monitored for suspicious activity.

To use your variables, you link variable sets to intrusion policies associated with access control rules or with the default action of an access control policy. By default, the default variable set is linked to all intrusion policies used by access control policies.

See the following sections for more information:

- Optimizing Predefined Default Variables

- Understanding Variable Sets

- Managing Variable Sets

- Managing Variables

- Adding and Editing Variables

- Resetting Variables

- Nesting Variables

- Linking Variable Sets to Intrusion Policies

- Understanding Advanced Variables

Optimizing Predefined Default Variables

License: Protection

By default, the FireSIGHT System provides a single default variable set, which is comprised of predefined default variables. The Cisco Vulnerability Research Team (VRT) uses rule updates to provide new and updated intrusion rules and other intrusion policy elements, including default variables. See Importing Rule Updates and Local Rule Files for more information.

Because many intrusion rules provided by Cisco use predefined default variables, you should set appropriate values for these variables. Depending on how you use variable sets to identify traffic on your network, you can modify the values for these default variables in any or all variable sets. See Adding and Editing Variables for more information.

Caution Importing an access control or an intrusion policy overwrites existing default variables in the default variable set with the imported default variables. If your existing default variable set contains a custom variable not present in the imported default variable set, the unique variable is preserved. For more information, see Importing Configurations.

Table 3-2 Variables Provided by Cisco

Variable Name

Description

Modify?

$AIM_SERVERS

Defines known AOL Instant Messenger (AIM) servers, and is used in chat-based rules and rules that look for AIM exploits.

Not required.

$DNS_SERVERS

Defines Domain Name Service (DNS) servers. If you create a rule that affects DNS servers specifically, you can use the $DNS_SERVERS variable as a destination or source IP address.

Not required in current rule set.

$EXTERNAL_NET

Defines the network that the FireSIGHT System views as the unprotected network, and is used in many rules to define the external network.

Yes, you should adequately define $HOME_NET and then exclude $HOME_NET as the value for $EXTERNAL_NET.

$FILE_DATA_PORTS

Defines non-encrypted ports used in intrusion rules that detect files in a network stream.

Not required.

$FTP_PORTS

Defines the ports of FTP servers on your network, and is used for FTP server exploit rules.

Yes, if your FTP servers use ports other than the default ports (you can view the default ports in the web interface).

$GTP_PORTS

Defines the data channel ports where the packet decoder extracts the payload inside a GTP (General Packet Radio Service [GPRS] Tunneling Protocol) PDU.

Not required.

$HOME_NET

Defines the network that the associated intrusion policy monitors, and is used in many rules to define the internal network.

Yes, to include the IP addresses for your internal network.

$HTTP_PORTS

Defines the ports of web servers on your network, and is used for web server exploit rules.

Yes, if your web servers use ports other than the default ports (you can view the default ports in the web interface).

$HTTP_SERVERS

Defines the web servers on your network. Used in web server exploit rules.

Yes, if you run HTTP servers.

$ORACLE_PORTS

Defines Oracle database server ports on your network, and is used in rules that scan for attacks on Oracle databases.

Yes, if you run Oracle servers.

$SHELLCODE_PORTS

Defines the ports you want the system to scan for shell code exploits, and is used in rules that detect exploits that use shell code.

Not required.

$SIP_PORTS

Defines the ports of SIP servers on your network, and is used for SIP exploit rules.

Not required.

$SIP_SERVERS

Defines SIP servers on your network, and is used in rules that address SIP-targeted exploits.

Yes, if you run SIP servers, you should adequately define $HOME_NET and then include $HOME_NET as the value for $SIP_SERVERS.

$SMTP_SERVERS

Defines SMTP servers on your network, and is used in rules that address exploits that target mail servers.

Yes, if you run SMTP servers.

$SNMP_SERVERS

Defines SNMP servers on your network, and is used in rules that scan for attacks on SNMP servers.

Yes, if you run SNMP servers.

$SNORT_BPF

Identifies a legacy advanced variable that appears only when it existed on your system in a FireSIGHT System software release before Version 5.3.0 that you subsequently upgraded to Version 5.3.0 or greater. See Understanding Advanced Variables.

No, you can only view or delete this variable. You cannot edit it or recover it after deleting it.

$SQL_SERVERS

Defines database servers on your network, and is used in rules that address database-targeted exploits.

Yes, if you run SQL servers.

$SSH_PORTS

Defines the ports of SSH servers on your network, and is used for SSH server exploit rules.

Yes, if your SSH servers use ports other than the default port (you can view the default ports in the web interface).

$SSH_SERVERS

Defines SSH servers on your network, and is used in rules that address SSH-targeted exploits.

Yes, if you run SSH servers, you should adequately define $HOME_NET and then include $HOME_NET as the value for $SSH_SERVERS.

$TELNET_SERVERS

Defines known Telnet servers on your network, and is used in rules that address Telnet server-targeted exploits.

Yes, if you run Telnet servers.

$USER_CONF

Provides a general tool that allows you to configure one or more features not otherwise available via the web interface. See Understanding Advanced Variables.

Caution Conflicting or duplicate $USER_CONF configurations will halt the system. See Understanding Advanced Variables.

No, only as instructed in a feature description or with the guidance of Support.

Understanding Variable Sets

License: Protection

Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all variables currently configured on your system. Within any variable set, you can add user-defined variables and customize the value of any variable.

Initially, the FireSIGHT System provides a single, default variable set comprised of predefined default values. Each variable in the default set is initially set to its default value, which for a predefined variable is the value set by the VRT and provided in rule updates.

Although you can leave predefined default variables configured to their default values, Cisco recommends that you modify a subset of predefined variables as described in Optimizing Predefined Default Variables.

You could work with variables only in the default set, but in many cases you can benefit most by adding one or more custom sets, configuring different variable values in different sets, and perhaps even adding new variables.

When using multiple sets, it is important to remember that the current value of any variable in the default set determines the default value of the variable in all other sets.

Example: Adding a User-Defined Variable to the Default Set

Optionally, you can customize the value of Var1 in any set. In Custom Set 2 where Var1 has not been customized, its value is 192.168.1.0/24. In Custom Set 1 the customized value 192.168.2.0/24 of Var1 overrides the default value. Resetting a user-defined variable in the default set resets its default value to any in all sets.

It is important to note in this example that, if you do not update Var1 in Custom Set 2, further customizing or resetting Var1 in the default set consequently updates the current, default value of Var1 in Custom Set 2, thereby affecting any intrusion policy linked to the variable set.

Although not shown in the example, note that interactions between sets are the same for user-defined variables and default variables except that resetting a default variable in the default set resets it to the value configured by Cisco in the current rule update.

Examples: Adding a User-Defined Variable to a Custom Set

Note that, except for the origin of Var1 from Custom Set 1, this example is identical to the example above where you added Var1 to the default set. Adding the customized value 192.168.1.0/24 for Var1 to Custom Set 1 copies the value to the default set as a customized value with a default value of any. Thereafter, Var1 values and interactions are the same as if you had added Var1 to the default set. As with the previous example, keep in mind that further customizing or resetting Var1 in the default set consequently updates the current, default value of Var1 in Custom Set 2, thereby affecting any intrusion policy linked to the variable set.

In the next example, you add Var1 with the value 192.168.1.0/24 to Custom Set 1 as in the previous example, but you elect not to use the configured value of Var1 as the default value in other sets.

This approach adds Var1 to all sets with a default value of any. After adding Var1, you can customize its value in any set. An advantage of this approach is that, by not initially customizing Var1 in the default set, you decrease your risk of customizing the value in the default set and thus inadvertently changing the current value in a set such as Custom Set 2 where you have not customized Var1.

Managing Variable Sets

License: Protection

When you select Variable Sets on the Object Manager page (Objects > Object Management), the object manager lists the default variable set and any custom sets you created.

On a freshly installed system, the default variable set is comprised only of the default variables predefined by Cisco.

Each variable set includes the default variables provided by Cisco and all custom variables you have added from any variable set. Note that you can edit the default set, but you cannot rename or delete the default set.

Caution Importing an access control or an intrusion policy overwrites existing default variables in the default variable set with the imported default variables. If your existing default variable set contains a custom variable not present in the imported default variable set, the unique variable is preserved. For more information, see Importing Configurations.

The following table summarizes the actions you can take to manage your variable sets.

Table 3-3 Variable Set Management Actions

To...

You can...

display your variable sets

select Objects > Object Management, then select Variable Set.

filter variable sets by name

begin typing a name; as you type, the page refreshes to display matching names.

clear name filtering

) in the filter field.

add a custom variable set

click Add Variable Set.

For your convenience, new variable sets contain all currently defined default and customized variables.
).

edit a variable set

) next to the variable set you want to edit. .

delete a custom variable set

. You cannot delete the default variable set. Note that variables created in a variable set you delete are not deleted or otherwise affected in other sets. . Use the Ctrl and Shift keys to select multiple sets.

After you configure variable sets, you can link them to intrusion policies.

To create or edit a variable set:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Variable Set.

Step 3 Add a variable set or edit an existing set:

- To add a variable set, click Add Variable Set .

- To edit a variable set, click the edit icon (

) next to the variable set.

The new or edit variable set page appears. When naming a variable set, you can use any printable standard ASCII characters except a pipe (|) or curly braces ({}). See Adding and Editing Variables for information on adding and editing variables within a variable set.

Managing Variables

License: Protection

You manage variables on the new or edit variables page within a variable set. The variables page for all variable sets separates variables into Customized Variables and Default Variables page areas.

A default variable is a variable provided by Cisco. You can customize the value of a default variable. You cannot rename or delete a default variable, and you cannot change its default value.

A customized variable is one of the following:

- customized default variables

When you edit the value for a default variable, the system moves the variable from the Default Variables area to the Customized Variables area. Because variable values in the default set determine the default values of variables in custom sets, customizing a default variable in the default set modifies the default value of the variable in all other sets.

- user-defined variables

You can add and delete your own variables, customize their values within different variable sets, and reset customized variables to their default values. When you reset a user-defined variable, it remains in the Customized Variables area.

See Adding and Editing Variables for more information.

You cannot delete default variables, and you cannot delete user-defined variables that are used by intrusion rules or other variables.

Table 3-4 Variable Management Actions

To...

You can...

display the variables page

) next to the variable set you want to edit.

name and, optionally, describe your variable set

enter an alphanumeric string including spaces and special characters in the Name and Description fields.
).

display the complete value for a variable

hover your pointer over the value in the Value column next to the variable.

Note A variable value can include up to 8192 characters. Keep in mind, however, that this limit applies to the size of the expanded value of the variable. If you use one or more variables to define another variable, the total number of characters and spaces of all the variable values cannot exceed 8192 characters.

add a variable

click Add.

See Adding and Editing Variables for more information.

edit a variable

) next to the variable you want to edit.

reset a modified variable to its default value

) next to a modified variable. A shaded reset icon indicates that the current value is already the default value. Tip Hover your pointer over an active reset icon to display the default value.

delete a user-defined customized variable

to confirm that you want to delete the variable.

save changes to a variable set

click Save, then click Yes if the variable set is in use by an access control policy to confirm that you want to save your changes.

Because the current value in the default set determines the default value in all other sets, modifying or resetting a variable in the default set changes the current value in other sets where you have not customized the default value.

To view the variables in a variable set:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Variable Set.

Step 3 Add a variable set or edit an existing set:

- To add a variable set, click Add Variable Set .

- To edit a variable set, click the edit icon (

) next to the variable set.

The new or edit variable set page appears. When naming a variable set, you can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 4 Add a variable or edit an existing variable:

- To add a variable, click Add .

- To edit a variable, click the edit icon (

) next to the variable.

The new or edit variable page appears.

See Adding and Editing Variables for information on adding and editing variables within a variable set.

Adding and Editing Variables

License: Protection

You can modify variables in any custom set.

If you create custom standard text rules, you might also want to add your own user-defined variables to more accurately reflect your traffic or as shortcuts to simplify the rule creation process. For example, if you create a rule that you want to inspect traffic in the “demilitarized zone” (or DMZ) only, you can create a variable named $DMZ whose value lists the server IP addresses that are exposed. You can then use the $DMZ variable in any rule written for this zone.

Adding a variable to a variable set adds it to all other sets. With one exception as explained below, the variable is added to other sets as the default value, which you can then customize.

When you add a variable from a custom set, you must choose whether to use the configured value as the customized value in the default set.

- If you do use the configured value (for example, 192.168.0.0/16), the variable is added to the default set using the configured value as a customized value with a default value of any . Because the current value in the default set determines the default value in other sets, the initial, default value in other custom sets is the configured value (which in the example is 192.168.0.0/16).

- If you do not use the configured value, the variable is added to the default set using only the default value any and, consequently, the initial, default value in other custom sets is any .

See Understanding Variable Sets for more information.

You add variables within a variable set on the New Variable page and edit existing variables on the Edit Variable page. You use the two pages identically except that when you edit an existing variable you cannot change the variable name or variable type.

Each page consists mainly of three windows:

- available items, including existing network or port variables, objects, and network object groups

- networks or ports to include in the variable definition

- networks or ports to exclude from the variable definition

You can create or edit two types of variables:

- network variables specify the IP addresses of hosts in your network traffic. See Working with Network Variables.

- port variables specify TCP or UDP ports in network traffic, including the value any for either type. See Working with Port Variables.

When you specify whether you want to add a network or port variable type, the page refreshes to list available items. A search field above the list allows you to constrain the list, which updates as you type.

You can select and drag available items the list of items to include or exclude. You can also select items and click the Include or Exclude button. Use the Ctrl and Shift keys to select multiple items. You can use the configuration field below the list of included or excluded items to specify literal IP addresses and address blocks for network variables, and ports and port ranges for port variables.

A list of items to include or exclude can be comprised of any combination of literal strings and existing variables, objects, and network object groups in the case of network variables.

Working with Network Objects

Although you can add any port type, only TCP and UDP ports, including the value any for either type, are valid variable values, and the list of available ports only displays variables that use these value types. See Working with Port Objects for information on adding port objects using the object manager.

Note that only network groups, not port groups, are available.

Table 3-5 Variable Edit Actions

To...

You can...

display the variables page

) next to an existing variable.

name your variable

in the Name field, type a unique, case-sensitive alphanumeric string that includes no special characters other than the underscore character (_).

Note that variable names are case-sensitive; for example, var and Var are each unique.

specify a network or port variable

select Network or Port from the Type drop-down list.

See Working with Network Variables and Working with Port Variables for detailed information on how you can use and configure network and port variables.

add an individual network object so you can then select it from the list of available networks

). See for information on adding network objects using the object manager.

add an individual port object so you can then select it from the list of available ports

).

search for available port or network items by name

begin typing a name in the search field above the list of available items; as you type, the page refreshes to display matching names.

clear name searching

) in the search field.

differentiate between available items

).

select objects to include or exclude in the variable definition

click the object in the list of available networks or ports; use the Ctrl and Shift keys to select multiple objects.

add selected items to the list of included or excluded networks or ports

drag and drop selected items. Alternately, click Include or Exclude.

You can add network and port variables and objects from the list of available items. You can also add network object groups.

add a literal network or port to the list of networks or ports to include or exclude

click to remove the prompt from the literal Network or Port field, type the literal IP address or address block for network variables, or the literal port or port range for port variables, then click Add.

Note that you cannot enter domain names or lists; to add multiple items, add each individually.

add a variable with the value any

name the variable and select the variable type, then click Save without configuring a value.
).

delete a variable or object from the included or excluded list

) next to the variable.

save a new or modified variable

click Save; if you are adding a variable from custom set, then click Yes to use the configured value as the default value in other sets, or No to use a default value of any.

See the following sections for more information:

- Working with Network Variables

- Working with Port Variables

To add or edit a variable:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Variable Set.

Step 3 Add a variable set or edit an existing set:

- To add a variable set, click Add Variable Set .

- To edit an existing variable set, click the edit icon (

) next to the variable set.

The new or edit variable set page appears. When naming a variable set, you can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 4 Add a new variable or edit an existing variable:

- To add a new variable, click Add .

- To edit an existing variable, click the edit icon (

) next to the variable.

The new or edit variable page appears.

Tip On the variable page, you can use the right-click context menu to select or delete items; see Using the Context Menu.

Step 5 If you are adding a new variable:

- Enter a unique variable Name .

You can use alphanumeric characters and the underscore (_) character.

- Select the Network or Port variable Type from the drop-down list.

Step 6 Optionally, move items from the list of available networks or ports to the list of included or excluded items.

You can select one or more items and then drag and drop, or click Include or Exclude. Use the Ctrl and Shift keys to select multiple items.

Tip If addresses or ports in the included and excluded lists for a network or port variable overlap, excluded addresses or ports take precedence.

Step 7 Optionally, enter a single literal value, then click Add.

For network variables, you can enter a single IP address or address block. For port variables you can add a single port or port range, separating the upper and lower values with a hyphen (-).

Repeat this step as needed to enter multiple literal values.

Step 8 Click Save to save the variable. If you are adding a new variable from a custom set, you have the following options:

- Click Yes to add the variable using the configured value as the customized value in the default set and, consequently, the default value in other custom sets.

- Click No to add the variable as the default value of any in the default set and, consequently, in other custom sets.

Step 9 When you have finished making changes, click Save to save the variable set, then click Yes.

Your changes are saved and any access control policy the variable set is linked to displays an out-of-date status. For your changes to take effect, you must apply the access control policy where the variable set is linked to an intrusion policy; see Applying an Access Control Policy.

Working with Network Variables

License: Protection

Network variables represent IP addresses you can use in intrusion rules that you enable in an intrusion policy and in intrusion policy rule suppressions, dynamic rule states, and adaptive profiles. Network variables differ from network objects and network object groups in that network variables are specific to intrusion policies and intrusion rules, whereas you can use network objects and groups to represent IP addresses in various places in the system’s web interface, including access control policies, network variables, intrusion rules, network discovery rules, event searches, reports, and so on. See Working with Network Objects for more information.

You can use network variables in the following configurations to specify the IP addresses of hosts on your network:

- intrusion rules

Intrusion rule Source IPs and Destination IPs header fields allow you to restrict packet inspection to the packets originating from or destined to specific IP addresses. See Specifying IP Addresses In Intrusion Rules.

- suppressions

The Network field in source or destination intrusion rule suppressions allows you to suppress intrusion event notifications when a specific IP address or range of IP addresses triggers an intrusion rule or preprocessor. See Configuring Suppression Per Intrusion Policy.

- dynamic rule states

The Network field in source or destination dynamic rule states allows you to detect when too many matches for an intrusion rule or preprocessor rule occur in a given time period. See Adding Dynamic Rule States.

- adaptive profiles

The adaptive profiles Networks field identifies hosts in the network map where you want to improve reassembly of packet fragments and TCP streams in passive deployments. See Tuning Preprocessing in Passive Deployments.

When you use variables in the fields identified in this section, the variable set you link to an intrusion policy determines the variable values in the network traffic handled by an access control policy that uses the intrusion policy.

You can add any combination of the following network configurations to a variable:

- any combination of network variables, network objects, and network object groups that you select from the list of available networks

See Working with Network Objects for information on creating individual and group network objects using the object manager.

- individual network objects that you add from the New Variable or Edit Variable page, and can then add to your variable and to other existing and future variables

- literal, single IP addresses or address blocks

You can list multiple literal IP addresses and address blocks by adding each individually. You can list IPv4 and IPv6 addresses and address blocks alone or in any combination. When specifying IPv6 addresses, you can use any addressing convention defined in RFC 4291.

The default value for included networks in any variable you add is the word any, which indicates any IPv4 or IPv6 address. The default value for excluded networks is none, which indicates no network. You can also specify the address :: in a literal value to indicate any IPv6 address in the list of included networks, or no IPv6 addresses in the list of exclusions.

Adding networks to the excluded list negates the specified addresses and address blocks. That is, you can match any IP address with the exception of the excluded IP address or address blocks.

For example, excluding the literal address 192.168.1.1 specifies any IP address other than 192.168.1.1, and excluding 2001:db8:ca2e::fa4c specifies any IP address other than 2001:db8:ca2e::fa4c.

You can exclude any combination of networks using literal or available networks. For example, excluding the literal values 192.168.1.1 and 192.168.1.5 includes any IP address other than 192.168.1.1 or 192.168.1.5. That is, the system interprets this as “not 192.168.1.1 and not 192.168.1.5,” which matches any IP address other than those listed between brackets.

Note the following points when adding or editing network variables:

- You cannot logically exclude the value any which, if excluded, would indicate no address. For example, you cannot add a variable with the value any to the list of excluded networks.

- Network variables identify traffic for the specified intrusion rule and intrusion policy features. Note that preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion rules.

- Excluded values must resolve to a subset of included values. For example, you cannot include the address block 192.168.5.0/24 and exclude 192.168.6.0/24. An error message warns you and identifies the offending variable, and you cannot save your variable set when you exclude a value outside the range of included values.

For information on adding and editing network variables, see Adding and Editing Variables.

Working with Port Variables

License: Protection

Port variables represent TCP and UDP ports you can use in the Source Port and Destination Port header fields in intrusion rules that you enable in an intrusion policy. Port variables differ from port objects and port object groups in that port variables are specific to intrusion rules. You can create port objects for protocols other than TCP and UDP, and you can use port objects in various places in the system’s web interface, including port variables, access control policies, network discovery rules, and event searches. See Working with Port Objects for more information.

You can use port variables in the intrusion rule Source Port and Destination Port header fields to restrict packet inspection to packets originating from or destined to specific TCP or UDP ports.

When you use variables in these fields, the variable set you link to the intrusion policy associated with an access control rule or policy determines the values for these variables in the network traffic where you apply the access control policy.

You can add any combination of the following port configurations to a variable:

- any combination of port variables and port objects that you select from the list of available ports

Note that the list of available ports does not display port object groups, and you cannot add these to variables. See Working with Port Objects for information on creating port objects using the object manager.

- individual port objects that you add from the New Variable or Edit Variable page, and can then add to your variable and to other existing and future variables

Only TCP and UDP ports, including the value any for either type, are valid variable values. If you use the new or edit variables page to add a valid port object that is not a valid variable value, the object is added to the system but is not displayed in the list of available objects. When you use the object manager to edit a port object that is used in a variable, you can only change its value to a valid variable value.

- single, literal port values and port ranges

You must separate port ranges with a dash (-). Port ranges indicated with a colon (:) are supported for backward compatibility, but you cannot use a colon in port variables that you create.

You can list multiple literal port values and ranges by adding each individually in any combination.

Note the following points when adding or editing port variables:

- The default value for included ports in any variable you add is the word any , which indicates any port or port range. The default value for excluded ports is none , which indicates no ports.

Tip To create a variable with the value any, name and save the variable without adding a specific value.

- You cannot logically exclude the value any which, if excluded, would indicate no ports. For example, you cannot save a variable set when you add a variable with the value any to the list of excluded ports.

- Adding ports to the excluded list negates the specified ports and port ranges. That is, you can match any port with the exception of the excluded ports or port ranges.

- Excluded values must resolve to a subset of included values. For example, you cannot include the port range 10-50 and exclude port 60. An error message warns you and identifies the offending variable, and you cannot save your variable set when you exclude a value outside the range of included values.

For information on adding and editing port variables, see Adding and Editing Variables.

Resetting Variables

License: Protection

Table 3-6 Variable Reset Values

Resetting this variable type...

In this set type...

Resets it to...

default

default

the rule update value

user-defined

default

any

default or user-defined

custom

the current default set value (modified or unmodified)

Resetting a variable in a custom set simply resets it to the current value for that variable in the default set.

Conversely, resetting or modifying the value of a variable in the default set always updates the default value of that variable in all custom sets. When the reset icon is grayed out, indicating that you cannot reset the variable, this means that the variable has no customized value in that set. Unless you have customized the value for a variable in a custom set, a change to the variable in the default set updates the value used in any intrusion policy where you have linked the variable set.

Note It is good practice when you modify a variable in the default set to assess how the change affects any intrusion policy that uses the variable in a linked custom set, especially when you have not customized the variable value in the custom set.

) in a variable set to see the reset value. When the customized value and the reset value are the same, this indicates one of the following:

- you are in the custom or default set where you added the variable with the value any

- you are in the custom set where you added the variable with an explicit value and elected to use the configured value as the default value

Nesting Variables

You can nest variables so long as the nesting is not circular. Nested, negated variables are not supported.

Example: Valid Nested Variables

Table 3-7 Example: Valid Nested Variables

Variable.

Type

Included Networks

Excluded Networks

SMTP_SERVERS

customized default

10.1.1.1

—

HTTP_SERVERS

customized default

10.1.1.2

—

OTHER_SERVERS

user-defined

10.2.2.0/24

—

HOME_NET

customized default

10.1.1.0/24

OTHER_SERVERS

SMTP_SERVERS

HTTP_SERVERS

In the following example, HOME_NET is an invalid nested variable because the nesting of HOME_NET is circular; that is, the definition of OTHER_SERVERS includes HOME_NET, so you would be nesting HOME_NET in itself.

Table 3-8 Example: An Invalid Nested Variable

Variable.

Type

Included Networks

Excluded Networks

SMTP_SERVERS

customized default

10.1.1.1

—

HTTP_SERVERS

customized default

10.1.1.2

—

OTHER_SERVERS

user-defined

10.2.2.0/24

HOME_NET

—

HOME_NET

customized default

10.1.1.0/24

OTHER_SERVERS

SMTP_SERVERS

HTTP_SERVERS

Because nested, negated variables are not supported, you cannot use the variable NONCORE_NET as shown in the following example to represent IP addresses that are outside of your protected networks.

Variable.

Type

Included Networks

Excluded Networks

HOME_NET

customized default

10.1.0.0/16

10.2.0.0/16

10.3.0.0/16

—

EXTERNAL_NET

customized default

—

HOME_NET

DMZ_NET

user-defined

10.4.0.0/16

—

NOTDMZ_NET

user-defined

—

DMZ_NET

NONCORE_NET

user-defined

EXTERNAL_NET

NOTDMZ_NET

—

Table 3-10 Example: Alternative to an Unsupported Nested, Negated Variable

Variable.

Type

Included Networks

Excluded Networks

HOME_NET

customized default

10.1.0.0/16

10.2.0.0/16

10.3.0.0/16

—

DMZ_NET

user-defined

10.4.0.0/16

—

NONCORE_NET

user-defined

—

HOME_NET

DMZ_NET

Linking Variable Sets to Intrusion Policies

License: Protection

By default, the FireSIGHT System links the default variable set to all intrusion policies used in an access control policy. When you apply an access control policy that uses an intrusion policy, intrusion rules that you have enabled in the intrusion policy use the variable values in the linked variable set.

When you modify a custom variable set used by an intrusion policy in an access control policy, the system reflects the status for that policy as out-of-date on the Access Control Policy page. You must reapply the access control policy to implement changes in your variable set. When you modify the default set, the system reflects the status of all access control policies that use intrusion policies as out-of-date, and you must reapply all access control policies to implement your changes.

See the following sections for information:

- To link a variable set other than the default set to an access control rule, see the procedure in Configuring an Access Control Rule to Perform Intrusion Prevention.

- To link a variable set other than the default set to the default action of an access control policy, see Setting Default Handling and Inspection for Network Traffic.

- To apply access control policies, including policies that link variable sets to intrusion policies, see Applying an Access Control Policy.

Understanding Advanced Variables

License: Protection

Advanced variables allow you to configure features that you cannot otherwise configure via the web interface. The FireSIGHT System currently provides only two advanced variables, and you can only edit the USER_CONF advanced variable.

USER_CONF

USER_CONF provides a general tool that allows you to configure one or more features not otherwise available via the web interface.

Caution Do not use the advanced variable USER_CONF to configure an intrusion policy feature unless you are instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will halt the system.

When editing USER_CONF, you can type up to 4096 total characters on a single line; the line wraps automatically. You can include any number of valid instructions or lines until you reach the 8192 maximum character length for a variable or a physical limit such as disk space. Use the backslash (\) line continuation character after any complete argument in a command directive.

Resetting USER_CONF empties it.

SNORT_BPF

SNORT_BPF is a legacy advanced variable that appears only when it was configured on your system in a FireSIGHT System software release before Version 5.3.0 that you subsequently upgraded to Version 5.3.0 or greater. You can only view or delete this variable. You cannot edit it or recover it after deleting it.

This variable allowed you to apply a Berkeley Packet Filter (BPF) to filter traffic before it reached the system. You should now use access control rules instead of this variable to enforce the filtering once offered by SNORT_BPF. This variable appears only with configurations that existed before system upgrade.

Working with File Lists

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

If you use network-based advanced malware protection (AMP), and the Collective Security Intelligence Cloud incorrectly identifies a file’s disposition, you can add the file to a file list using a SHA-256 hash value to better detect the file in the future. Depending on the type of file list, you can do the following:

- To treat a file as if the cloud assigned a clean disposition, add the file to the clean list .

- To treat a file as if the cloud assigned a malware disposition, add the file to the custom detection list.

Because you manually specify the blocking behavior for these files, the system does not perform malware cloud lookups, even if the files are otherwise identified as malware by the cloud. Note that you must configure a rule in the file policy with either a Malware Cloud Lookup or Block Malware action and a matching file type to calculate a file’s SHA value. For more information, see Working with File Rules.

The system’s clean list and custom detection list are included by default in every file policy. You can opt not to use either or both lists on a per-policy basis.

Caution Do not include files on this list that are actually malware. The system does not block them, even if the cloud assigned the file’s a Malware disposition, or if you added the file to the custom detection list.

Each file list can contain up to 10000 unique SHA-256 values. To add files to the file list, you can:

- use the event viewer context menu to add a SHA-256 value.

- upload a file so the system calculates and adds the file’s SHA-256 value.

- enter a file’s SHA-256 value directly.

- create and upload a comma-separated value (CSV) source file containing multiple SHA-256 values. All non-duplicate SHA-256 values are added to the file list.

When you add a file to a file list, edit a SHA-256 value in the file list, or delete SHA-256 values from the file list, you must reapply any access control policies with file policies that use the list for the changes to take effect.

Because adding a file to a file list affects access control, you must have one of the following to manage all aspects of a file list:

- Administrator access

- a combination of Network Admin or Access Admin access (to edit the file list), Security Approver access (to reapply access control policies), and Security Analyst or Security Analyst (RO) access (to add a file using the SHA-256 value from the event view)

- a custom role with Modify Access Control Policy and Object Manager (to edit the file list), Apply Access Control Policy (to reapply access control policies), and Modify File Events (to add a file using the SHA-256 value from the event view) permissions; see Managing Your Deployment with Custom User Roles

For more information on using file lists, see the following topics:

- Using the Context Menu

- Uploading Multiple SHA-256 Values to a File List

- Uploading an Individual File to a File List

- Adding a SHA-256 Value to the File List

- Modifying Files on a File List

- Downloading a Source File from a File List

Uploading Multiple SHA-256 Values to a File List

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

You can add multiple SHA-256 values to a file list by uploading a comma-separated value (CSV) source file containing a list of SHA-256 values and descriptions. The Defense Center validates the contents and populates the file list with valid SHA-256 values.

The source file must be a simple text file with a .csv file name extension. Any header must start with a pound sign (#); it is treated as a comment and not uploaded. Each entry should contain a single SHA-256 value followed by a description of up to 256 alphanumeric or special characters and end with either the LF or CR+LF Newline character. The system ignores any additional information in the entry.

Note the following:

- Deleting a source file from the file list also removes all associated SHA-256 hashes from the file list.

- You cannot upload multiple files to a file list if the successful source file upload results in the file list containing more than 10000 distinct SHA-256 values.

- The system truncates descriptions exceeding 256 characters to the first 256 characters on upload. If the description contains commas, you must use an escape character ( \, ). If no description is included, the source file name is used instead.

- If a file list contains a SHA-256 value, and you upload a source file containing that value, the newly uploaded value does not modify the existing SHA-256 value. When viewing captured files, file events, or malware events related to the SHA-256 value, any threat name or description is derived from the individual SHA-256 value.

- The system does not upload invalid SHA-256 values in a source file.

- If multiple uploaded source files contain an entry for the same SHA-256 value, the system uses the most recent value.

- If a source file contains multiple entries for the same SHA-256 value, the system uses the last one.

- You cannot directly edit a source file within the object manager. To make changes, you must first modify your source file directly, delete the copy on the system, then upload the modified source file. See Downloading a Source File from a File List for more information.

To upload a source file to a file list:

Access: Admin/Any Security Analyst

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Click File List.

The File List section appears.

) next to the file list where you want to add values from a source file.

The File List pop-up window appears.

Step 4 Select List of SHAs from the Add by field.

The pop-up window updates to include new fields.

Step 5 Optionally, enter a description of the source file in the Description field.

If you do not enter a description, the system uses the file name.

Step 6 Click Browse to browse to the source file, then click Upload and Add List to add the list.

The source file is added to the file list. The SHA-256 column lists how many SHA-256 values the file contains.

Step 7 Click Save.

Step 8 Reapply all access control policies with file policies that use the file list.

After the policies apply, the system no longer performs malware cloud lookups on files in the file list.

Uploading an Individual File to a File List

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

If you have a copy of the file you want to add to a file list, you can upload the file to the Defense Center for analysis; the system calculates the file’s SHA-256 value and adds the file to the list. The system does not enforce a limit on the size of files for SHA-256 calculation.

To add a file by having the Defense Center calculate its SHA-256 value:

Access: Admin/Network Admin

) next to the clean list or custom detection list where you want to add a file.

The File List pop-up window appears.

Step 2 Select Calculate SHA from the Add by field.

The pop-up window updates to include new fields.

Step 3 Optionally, enter a description of the file in the Description field.

If you do not enter a description, the file name is used for the description on upload.

Step 4 Click Browse to browse to the source file, then click Calculate and Add SHA to add the list.

The file is added to the file list.

Step 5 Click Save.

Step 6 Reapply all access control policies with file policies that use the file list.

After the policies apply, the system no longer performs malware cloud lookups on files in the file list.

Adding a SHA-256 Value to the File List

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

You can submit a file’s SHA-256 value to add it to a file list. You cannot add duplicate SHA-256 values.

Tip Right-click a file or malware event from the event view and select Show Full Text in the context menu to view and copy the full SHA-256 value for the file.

To add a file by manually entering the file’s SHA-256 value:

Access: Admin/Network Admin

) next to the clean list or custom detection list where you want to add a file.

The File List pop-up window appears.

Step 2 Select Enter SHA Value from the Add by field.

The pop-up window updates to include new fields.

Step 3 Enter a description of the source file in the Description field.

Step 4 Type or paste the file’s entire SHA-256 value. The system does not support matching partial values.

Step 5 Click Add to add the file.

The file is added to the file list.

Step 6 Click Save.

Step 7 Reapply all access control policies with file policies that use the file list.

After the policies apply, the system no longer performs malware cloud lookups on files in the file list.

Modifying Files on a File List

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

You can edit or delete individual SHA-256 values on a file list. Note that you cannot directly edit a source file within the object manager. To make changes, you must first modify your source file directly, delete the copy on the system, then upload the modified source file. See Downloading a Source File from a File List for more information. To edit a file on a file list:

Access: Admin/Network Admin

) next to the clean list or custom detection list where you want to modify a file.

The File List pop-up window appears.

).

The Edit SHA-256 pop-up window appears.

Step 3 Update the SHA-256 value or Description.

Step 4 Click Save.

The File List pop-up window appears. The system updates the file entry in the list.

Step 5 Click Save.

Step 6 Reapply all access control policies with file policies that use the file list.

After the policies apply, the system no longer performs malware cloud lookups on files in the file list.

Downloading a Source File from a File List

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

You can view, download, or delete existing source file entries on a file list. Note that you cannot edit a source file once uploaded. You must first delete the source file from the file list, then upload an updated file. For more information on uploading a source file, see Uploading Multiple SHA-256 Values to a File List.

The number of entries associated with a source file refers to the number of distinct SHA-256 values. If you delete a source file from a file list, the total number of SHA-256 entries the file list contains decreases by the number of valid entries in the source file.

To download a source file:

Access: Admin/Network Admin

) next to the clean list or custom detection list where you want to download a source file.

The File List pop-up window appears.

).

The View SHA-256’s in list pop-up window appears.

Step 3 Click Download SHA List and follow the prompts to save the source file.

Step 4 Click Close.

The File List pop-up window appears.

Working with Security Zones

License: Any

A security zone is a grouping of one or more inline, passive, switched, routed, or ASA interfaces that you can use to manage and classify traffic flow in various policies and configurations. The interfaces in a single zone may span multiple devices; you can also configure multiple zones on a single device. This allows you to divide the network into segments where you can apply various policies. You must assign at least one interface to a security zone to match traffic against that security zone, and each interface can belong to only one zone.

In addition to using security zones to group interfaces, you can use zones in various places in the system’s web interface, including access control policies, network discovery rules, and event searches. For example, you could write an access control rule that applies only to a specific source or destination zone, or restrict network discovery to traffic to or from a specific zone.

When you update a security zone object, the system saves a new revision of the object. As a result, if you have managed devices in the same security zone that have different revisions of the security zone object, you may log what appear to be duplicate connections. If you notice duplicate connection reporting, you can update all managed devices to use the same revision of the object. In the object manager, edit the security zone, remove all managed devices, save the object, re-add the managed devices, and save the object again. Then, reapply all affected device policies. For more information on applying device policies, see Applying Changes to Devices.

You create security zones in one of the following ways:

- The system creates security zones upon device registration, depending on the detection mode you selected for the device during its initial configuration. For example, the system creates a Passive zone in passive deployments, while in inline deployments the system creates External and Internal zones.

- You can create security zones on the fly while configuring interfaces on a managed device.

- You can create security zones using the object manager ( Objects > Object Management ).

The Security Zones page of the object manager lists the zones configured on your managed devices. The page also displays the type of interfaces in each zone, and you can expand each zone to view which interfaces on which devices belong to each zone.

Note All interfaces in a security zone must be of the same type, that is, all inline, passive, switched, routed, or ASA. Further, after you create a security zone, you cannot change the type of interfaces it contains.

If you modify your ASA security contexts, switching from single context mode to multi-context mode or visa versa, the system removes all interfaces from your security zone configurations.

You cannot delete a security zone that is in use. After you add or remove interfaces from a zone, you must reapply the device configuration to the devices where the interfaces reside. You must also reapply the access control and network discovery policies that use the zone.

To add a security zone:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Security Zones.

Step 3 Click Add Security Zone.

The Security Zones pop-up window appears.

Step 4 Type a Name for the zone. You can use any printable standard ASCII characters except curly braces ({}), a pipe (|), a semicolon (;), or the pound sign (#).

Step 5 Select an interface Type for the zone.

After you create a security zone, you cannot change its type.

Step 6 From the Device > Interfaces drop-down list, select a device that contains interfaces you want to add to the zone.

Step 7 Select one or more interfaces.

Use the Shift and Ctrl keys to select multiple objects. If you have not yet configured interfaces on your managed devices, you can create an empty zone and add interfaces to it later; skip to step 10.

Step 8 Click Add.

The interfaces you selected are added to the zone, grouped by device.

Step 9 Repeat steps 6 through 8 to add interfaces on other devices to the zone.

Step 10 Click Save.

The security zone is added.

Working with Cipher Suite Lists

License: Any

Supported Devices: Series 3

A cipher suite list is an object comprised of several cipher suites. Each pre-defined cipher suite value represents a cipher suite used to negotiate an SSL- or TLS-encrypted session. You can use cipher suites and cipher suite lists in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session using that cipher suite. If you add a cipher suite list to an SSL rule, SSL sessions negotiated with any of the cipher suites in the list match the rule.

Note Although you can use cipher suites in the web interface in the same places as cipher suite lists, you cannot add, modify, or delete cipher suites.

You cannot delete a cipher suite list that is in use. Additionally, after you edit a cipher suite list used in an SSL policy, you must reapply the associated access control policy for your changes to take effect.

To create a cipher suite list:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Cipher Suite List.

Step 3 Click Add Cipher Suites.

The Cipher Suite List pop-up window appears.

Step 4 Type a Name for the cipher suite list. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Select one or more cipher suites and click Add.

- Use Shift and Ctrl to select multiple cipher suites, or right-click and Select All .

- Use the filter field (

) to search for existing cipher suites to include, which updates as you type to display matching items. Click the reload icon ( ) above the search field or click the clear icon ( ) in the search field to clear the search string.

Step 6 Click Save.

The cipher suite list is created.

Working with Distinguished Name Objects

License: Any

Supported Devices: Series 3

Each distinguished name object represents the distinguished name listed for a public key certificate’s subject or issuer. You can use distinguished name objects and groups (see Grouping Objects) in SSL rules to control encrypted traffic based on whether the client and server negotiated the SSL session using a server certificate with the distinguished name as subject or issuer.

Your distinguished name object can contain the common name attribute (CN). If you add a common name without “CN=” then the system prepends “CN=” before saving the object.

Table 3-11 Distinguished Name Attributes

Attribute

Description

Allowed Values

C

Country Code

two alphabetic characters

CN

Common Name

up to 64 alphanumeric, backslash (/), hyphen (-), quotation ("), or asterisk (*) characters, or spaces

O

Organization

OU

Organizational Unit

You can define one or more asterisks (*) as wild cards in an attribute. In a common name attribute, you can define one or more asterisks per domain name label. Wild cards match only within that label, though you can define multiple labels with wild cards. See the following table for examples.

Table 3-12 Common Name Attribute Wild Card Examples

Attribute

Matches

Does Not Match

CN=”*ample.com”

example.com

mail.example.com

example.text.com

ampleexam.com

CN=”exam*.com”

example.com

mail.example.com

example.text.com

ampleexam.com

CN=”*xamp*.com”

example.com

mail.example.com

example.text.com

ampleexam.com

CN=”*.example.com”

mail.example.com

example.com

example.text.com

ampleexam.com

CN=”*.com”

example.com

ampleexam.com

mail.example.com

example.text.com

CN=”*.*.com”

mail.example.com

example.text.com

example.com

ampleexam.com

You cannot delete a distinguished name object that is in use. Additionally, after you edit a distinguished name object used in an SSL policy, you must reapply the associated access control policy for your changes to take effect.

To add a distinguished name object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under Distinguished Name, select Individual Objects.

Step 3 Click Add Distinguished Name.

The Distinguished Name pop-up window appears.

Step 4 Type a Name for the distinguished name object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 In the DN field, type a value for the distinguished name or common name. You have the following options:

- If you add a distinguished name, you can include one of each attribute listed in Table 3-11 separated by commas.

- If you add a common name, you can include multiple labels and wild cards.

Step 6 Click Save.

The distinguished name object is added.

Working with PKI Objects

License: Any

Supported Devices: Series 3

PKI objects represent the public key certificates and paired private keys required to support your SSL inspection deployment. Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also contain the private key paired with the certificate. Internal and external certificate objects consist of server certificates; internal certificate objects also contain the private key paired with the certificate. Using these objects in SSL rules, you can decrypt:

- outgoing traffic by re-signing the server certificate with an internal CA object

- incoming traffic using the known private key in an internal certificate object

You can also create SSL rules and match traffic encrypted with:

- the certificate in an external certificate object

- a certificate either signed by the CA in a trusted CA object, or within the CA’s chain of trust

You can manually input certificate and key information, upload a file containing that information, or in some cases, generate a new CA certificate and private key.

When you view a list of PKI objects in the object manager, the system displays the certificate’s Subject distinguished name as the object value. Hover your pointer over the value to view the full certificate Subject distinguished name. To view other certificate details, edit the PKI object.

Note The Defense Center and managed devices encrypt all private keys stored in internal CA objects and internal certificate objects with a randomly generated key before saving them. If you upload private keys that are password protected, the appliance decrypts the key using the user-supplied password, then reencrypts it with the randomly generated key before saving it.

For more information, see the following sections:

- Working with Internal Certificate Authority Objects

- Working with Trusted Certificate Authority Objects

- Working with External Certificate Objects

- Working with Internal Certificate Objects

Working with Internal Certificate Authority Objects

License: Any

Supported Devices: Series 3

Each internal certificate authority (CA) object you configure represents the CA public key certificate of a CA your organization controls. The object consists of the object name, CA certificate, and paired private key. You can use internal CA objects and groups (see Grouping Objects) in SSL rules to decrypt outgoing encrypted traffic by re-signing the server certificate with the internal CA.

Note If you reference an internal CA object in a Decrypt - Resign SSL rule and the rule matches an encrypted session, the user’s browser may warn that the certificate is not trusted while negotiating the SSL handshake. To avoid this, add the internal CA object certificate to either the client or domain list of trusted root certificates.

You can create an internal CA object in the following ways:

- import an existing RSA-based or elliptic curve-based CA certificate and private key

- generate a new self-signed RSA-based CA certificate and private key

- generate an unsigned RSA-based CA certificate and private key. You must submit a certificate signing request (CSR) to another CA to sign the certificate before using the internal CA object.

After you create an internal CA object containing a signed certificate, you can download the CA certificate and private key. The system encrypts downloaded certificates and private keys with a user-provided password.

Whether system-generated or user-created, you can modify the internal CA object name, but cannot modify other object properties.

You cannot delete an internal CA object that is in use. Additionally, after you edit an internal CA object used in an SSL policy, the associated access control policy goes out-of-date. You must reapply the access control policy for your changes to take effect.

For more information, see the following sections:

- Importing a CA Certificate and Private Key

- Generating a New CA Certificate and Private Key

- Obtaining and Uploading a New Signed Certificate

- Downloading a CA Certificate and Private Key

Importing a CA Certificate and Private Key

License: Any

Supported Devices: Series 3

You can configure an internal CA object by importing an X.509 v3 CA certificate and private key. You can upload files encoded in one of the following supported formats:

- Distinguished Encoding Rules (DER)

- Privacy-enhanced Electronic Mail (PEM)

If the private key file is password-protected, you can supply the decryption password. If the certificate and key are encoded in the PEM format, you can also copy and paste the information.

You can upload only files that contain proper certificate or key information, and that are paired with each other. The system validates the pair before saving the object.

Note If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced internal CA certificate’s encryption algorithm type, in addition to any configured rule conditions. You must upload an elliptic curve-based CA certificate to decrypt outgoing traffic encrypted with an elliptic curve-based algorithm, for example. For more information, see Decrypt Actions: Decrypting Traffic for Further Inspection.

To import an internal CA certificate and private key:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal CAs.

Step 3 Click Import CA.

The Import Internal Certificate Authority pop-up window appears.

Step 4 Type a Name for the internal CA object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.

Step 6 Above the Key field, click Browse to upload a DER or PEM-encoded paired private key file.

Step 7 If the uploaded file is password-protected, select the Encrypted, and the password is: check box and enter the password.

Step 8 Click Save.

The internal CA object is added.

Generating a New CA Certificate and Private Key

License: Any

Supported Devices: Series 3

Table 3-13 Generated Internal CA Attributes

Field

Allowed Values

Required

Country Name (two-letter code)

two alphabetic characters

yes

State or Province

up to 64 alphanumeric, backslash (/), hyphen (-), quotation ("), asterisk (*), period (.), or space characters

no

Locality or City

Organization

Organizational Unit

Common Name

The generated CA certificate is valid for ten years. The Valid From date is a week before generation.

To generate a self-signed CA certificate:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal CAs.

Step 3 Click Generate CA.

The Generate Internal Certificate Authority pop-up window appears.

Step 4 Type a Name for the internal CA object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Type the identification attributes, as described in Table 3-13.

Step 6 Click Generate self-signed CA.

The internal CA object is added.

Obtaining and Uploading a New Signed Certificate

License: Any

Supported Devices: Series 3

You can configure an internal CA object by obtaining a signed certificate from a CA. This involves two steps:

- Provide identification information to configure the internal CA object. This generates an unsigned certificate and paired private key, and creates a certificate signing request (CSR) to a CA you specify.

- After the CA issues the signed certificate, upload it to the internal CA object, replacing the unsigned certificate.

You can only reference an internal CA object in an SSL rule if it contains a signed certificate.

To create an unsigned CA certificate and CSR:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal CAs.

Step 3 Click Generate CA.

The Generate Internal Certificate Authority pop-up window appears.

Step 4 Type a Name for the internal CA object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Type the identification attributes, as described in Table 3-13.

Step 6 Click Generate CSR.

The Generate Internal Certificate Authority pop-up window appears.

Step 7 Copy the CSR to submit to a CA.

Step 8 Click OK.

The CA object is created. Note that before you can use it, you must upload a signed certificate issued by a CA.

To upload a signed certificate issued in response to a CSR:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal CAs.

) next to the CA object containing the unsigned certificate awaiting the CSR.

The Edit Internal Certificate Authority pop-up window appears.

Step 4 Click Install Certificate.

The Install Internal Certificate Authority pop-up window appears.

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.

Step 6 If the uploaded file is password protected, select the Encrypted, and the password is: check box and enter the password.

Step 7 Click Save.

The CA object contains a signed certificate, and can be referenced in SSL rules.

Downloading a CA Certificate and Private Key

License: Any

Supported Devices: Series 3

You can back up or transfer a CA certificate and paired private key by downloading a file containing the certificate and key information from an internal CA object.

Caution Always store downloaded key information in a secure location.

The system encrypts the private key stored in an internal CA object with a randomly generated key before saving it to disk. If you download a certificate and private key from an internal CA object, the system first decrypts the information before creating a file containing the certificate and private key information. You must then provide a password the system uses to encrypt the downloaded file.

Caution Private keys downloaded as part of a system backup are decrypted, then stored in the unencrypted backup file. For more information, see Creating Backup Files.

To download an internal CA certificate and private key:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal CAs.

) next to the internal CA object whose certificate and private key you want to download.

The Edit Internal Certificate Authority pop-up window appears.

Step 4 Click Download.

The Encrypt Download File pop-up window appears.

Step 5 Type an encryption password in the Password and Confirm Password fields.

Step 6 Click OK.

You are prompted to save the file.

Working with Trusted Certificate Authority Objects

License: Any

Supported Devices: Series 3

Each trusted certificate authority (CA) object you configure represents a CA public key certificate belonging to a trusted CA outside your organization. The object consists of the object name and CA public key certificate. You can use external CA objects and groups (see Grouping Objects) in the SSL policy to control traffic encrypted with a certificate signed either by the trusted CA, or any CA within the chain of trust.

After you create the trusted CA object, you can modify the name and add certificate revocation lists (CRL), but cannot modify other object properties. There is no limit on the number of CRLs you can add to an object. If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.

You cannot delete a trusted CA object that is in use. Additionally, after you edit a trusted CA object used in an SSL policy, the associated access control policy goes out-of-date. You must reapply the access control policy for your changes to take effect.

For more information, see the following sections:

- Adding a Trusted CA Object

- Adding a Certificate Revocation List to a Trusted CA Object

Adding a Trusted CA Object

License: Any

Supported Devices: Series 3

You can configure an external CA object by uploading an X.509 v3 CA certificate. You can upload a file encoded in one of the following supported formats:

- Distinguished Encoding Rules (DER)

- Privacy-enhanced Electronic Mail (PEM)

If the file is password-protected, you must supply the decryption password. If the certificate is encoded in the PEM format, you can also copy and paste the information.

You can upload a CA certificate only if the file contains proper certificate information; the system validates the certificate before saving the object.

To import a trusted CA certificate:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Trusted CAs.

Step 3 Click Add Trusted CAs.

The Import Trusted Certificate Authority pop-up window appears.

Step 4 Type a Name for the trusted CA object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 CA certificate file.

Step 6 If the file is password-protected, select the Encrypted, and the password is: check box and enter the password.

Step 7 Click OK.

The trusted CA object is added.

Adding a Certificate Revocation List to a Trusted CA Object

License: Any

Supported Devices: Series 3

You can upload CRLs to a trusted CA object. If you reference that trusted CA object in an SSL policy, you can control encrypted traffic based on whether the CA that issued the session encryption certificate subsequently revoked the certificate. You can upload files encoded in one of the following supported formats:

- Distinguished Encoding Rules (DER)

- Privacy-enhanced Electronic Mail (PEM)

After you add the CRL, you can view the list of revoked certificates. If you want to modify a CRL you have uploaded to an object, you must delete the object and recreate it.

You can upload only files that contain a proper CRL. There is no limit to the number of CRLs you can add to a trusted CA object. However, you must save the object each time you upload a CRL, before adding another CRL.

To upload a CRL:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Trusted CAs.

) next to a trusted CA object.

The Edit Trusted Certificate Authority pop-up window appears.

Step 4 Click Add CRL to upload a DER or PEM-encoded CRL file.

Step 5 Click OK.

Your changes are saved.

Working with External Certificate Objects

License: Any

Supported Devices: Series 3

Each external certificate object you configure represents a server public key certificate that does not belong to your organization. The object consists of the object name and certificate. You can use external certificate objects and groups (see Grouping Objects) in SSL rules to control traffic encrypted with the server certificate. For example, you can upload a self-signed server certificate that you trust, but cannot verify with a trusted CA certificate.

You can configure an external certificate object by uploading an X.509 v3 server certificate. You can upload a file in one of the following supported formats:

- Distinguished Encoding Rules (DER)

- Privacy-enhanced Electronic Mail (PEM)

You can upload only files that contains proper server certificate information; the system validates the file before saving the object. If the certificate is encoded in the PEM format, you can also copy and paste the information.

After you create the external certificate object, you can modify the name, but cannot modify other object properties.

You cannot delete an external certificate object that is in use. Additionally, after you edit an external certificate object used in an SSL policy, the associated access control policy goes out-of-date. You must reapply the access control policy for your changes to take effect.

To add an external certificate object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select External Certs.

Step 3 Click Add External Cert.

The Add Known External Certificate pop-up window appears.

Step 4 Type a Name for the external certificate object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate file.

Step 6 Click Save.

The internal CA object is added.

Working with Internal Certificate Objects

License: Any

Supported Devices: Series 3

Each internal certificate object you configure represents a server public key certificate belonging to your organization. The object consists of the object name, public key certificate, and paired private key. You can use internal certificate objects and groups (see Grouping Objects) in SSL rules to decrypt traffic incoming to one of your organization’s servers using the known private key.

You can configure an internal certificate object by uploading an X.509 v3 RSA-based or elliptic curve-based server certificate and paired private key. You can upload a file in one of the following supported formats:

- Distinguished Encoding Rules (DER)

- Privacy-enhanced Electronic Mail (PEM)

If the file is password-protected, you must supply the decryption password. If the certificate and key are encoded in the PEM format, you can also copy and paste the information.

You can upload only files that contain proper certificate or key information, and that are paired with each other. The system validates the pair before saving the object.

After you create the internal certificate object, you can modify the name, but cannot modify other object properties.

You cannot delete an internal certificate object that is in use. Additionally, after you edit an internal certificate object used in an SSL policy, the associated access control policy goes out-of-date. You must reapply the access control policy for your changes to take effect.

To add an internal certificate object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Under PKI, select Internal Certs.

Step 3 Click Add Internal Cert.

The Add Known Internal Certificate pop-up window appears.

Step 4 Type a Name for the internal certificate object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Above the Certificate Data field, click Browse to upload a DER or PEM-encoded X.509 v3 server certificate file.

Step 6 Above the Key field, or click Browse to upload a DER or PEM-encoded paired private key file.

Step 7 If the uploaded private key file is password-protected, select the Encrypted, and the password is: check box and enter the password.

Step 8 Click Save.

The internal certificate object is added.

Working with Geolocation Objects

License: FireSIGHT

Supported Devices: Series 3, virtual, ASA FirePOWER

Supported Defense Centers: All except DC500

Each geolocation object you configure represents one or more countries or continents that the system has identified as the source or destination of traffic on your monitored network. You can use geolocation objects in various places in the system’s web interface, including access control policies, SSL policies, and event searches. For example, you could write an access control rule that blocks traffic to or from certain countries. For information on filtering traffic by geographical location, see Controlling Traffic by Network or Geographical Location. For information on filtering encrypted traffic by geographic location, see Controlling Encrypted Traffic by Network or Geographical Location.

To ensure that you are using up-to-date information to filter your network traffic, Cisco strongly recommends that you regularly update your Geolocation Database (GeoDB). For information on downloading and installing GeoDB updates, see Updating the Geolocation Database.

You cannot delete a geolocation object that is in use. Additionally, after you edit a geolocation object used in an access control policy or SSL policy, you must reapply the access control policy for your changes to take effect.

To add a geolocation object:

Access: Admin/Access Admin/Network Admin

Step 1 Select Objects > Object Management.

The Object Management page appears.

Step 2 Select Geolocation.

The Geolocation Objects page appears.

Step 3 Click Add Geolocation.

The Geolocation Object pop-up window appears.

Step 4 Type a Name for the geolocation object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 Select the check boxes for the countries and continents you want to include in your geolocation object.

Selecting a continent selects all countries within that continent, as well as any countries that GeoDB updates may add under that continent in the future. Deselecting any country under a continent deselects the continent. You can select any combination of countries and continents.

Step 6 Click Save.

The geolocation object is added.

Managing Devices

The Defense Center is a key component in the FireSIGHT System. You can use the Defense Center to manage the full range of devices that comprise the FireSIGHT System, and to aggregate, analyze, and respond to the threats they detect on your network.

By using the Defense Center to manage devices, you can:

- configure policies for all your devices from a single location, making it easier to change configurations

- install various types of software updates on devices

- push health policies to your managed devices and monitor their health status from the Defense Center

The Defense Center aggregates and correlates intrusion events, network discovery information, and device performance data, allowing you to monitor the information that your devices are reporting in relation to one another, and to assess the overall activity occurring on your network.

For more information, see the following sections:

- Management Concepts describes some of the features and limitations involved with managing your devices with a Defense Center.

- Understanding Management Interfaces describes how you can use traffic channels and multiple management interfaces to improve performance or isolate traffic between devices on different networks.

- Working in NAT Environments describes the principles of setting up the management of your devices in Network Address Translation environments.

- Configuring High Availability describes how to set up two Defense Centers as a high availability pair to help ensure continuity of operations.

- Working with Devices describes how to establish and disable connections between devices and your Defense Center. It also explains how to add, delete, and change the state of managed devices.

- Managing Device Groups describes how to create device groups as well as how to add and remove devices from groups.

- Clustering Devices describes how to establish and manage high availability between two managed devices.

- Editing Device Configuration describes the device attributes you can edit and explains how to edit them.

- Managing Stacked Devices describes how to create a stack of managed devices and how to remove devices from a stack.

- Configuring Sensing Interfaces explains how to configure interfaces on your managed devices.

Management Concepts

You can use a Defense Center to manage nearly every aspect of a device’s behavior. You need only one Defense Center to manage a device, though you can also use a second Defense Center as part of a high availability pair. The sections that follow explain some of the concepts you need to know as you plan your FireSIGHT System deployment:

- What Can Be Managed by a Defense Center?

- Beyond Policies and Events

- Using Redundant Defense Centers

What Can Be Managed by a Defense Center?

You can use your Defense Center as a central management point in a FireSIGHT System deployment to manage the following devices:

- FirePOWER managed devices

- Cisco ASA with FirePOWER Services devices

- software-based devices, such as virtual devices and Cisco NGIPS for Blue Coat X-Series

Note Cisco recommends than you manage no more than three devices (including software-based devices) with the DC500 model Defense Center. For details on DC500 database limitations see the Database Event Limits table.

When you manage a device, information is transmitted between the Defense Center and the device over a secure, SSL-encrypted TCP tunnel.

The following illustration lists what is transmitted between a Defense Center and its managed devices. Note that the types of events and policies that are sent between the appliances are based on the device type.

Beyond Policies and Events

License: Any

In addition to applying policies to devices and receiving events from them, you can also perform other device-related tasks on the Defense Center.

Backing Up a Device

You cannot create or restore backup files for virtual managed devices, Cisco NGIPS for Blue Coat X-Series, or Cisco ASA with FirePOWER Services.

When you perform a backup of a physical managed device from the device itself, you back up the device configuration only. To back up configuration data and, optionally, unified files, perform a backup of the device using the managing Defense Center.

To back up event data, perform a backup of the managing Defense Center. For more information, see Creating Backup Files.

Updating Devices

From time to time, Cisco releases updates to the FireSIGHT System, including:

- intrusion rule updates, which may contain new and updated intrusion rules

- vulnerability database updates

- geolocation updates

- software patches and updates

You can use the Defense Center to install an update on the devices it manages.

Using Redundant Defense Centers

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

You can set up two Defense Centers as a high availability pair. This ensures redundant functionality in case one of the Defense Centers fails. Policies, user accounts, and more are shared between the two Defense Centers. Events are automatically sent to both Defense Centers. See Configuring High Availability for more information.

Understanding Management Interfaces

Management interfaces provide the means of communication between the Defense Center and all devices it manages. Maintaining good traffic control between the appliances is essential to the success of your deployment.

On Series 3 appliances and virtual Defense Centers, you can change the default configuration to enable the management interface on the Defense Center, device, or both, to sort traffic between the appliances into two separate traffic channels. The management traffic channel carries all internal traffic (such as inter-device traffic specific to the management of the appliance and the system), and the event traffic channel carries all event traffic (such as web events). When you split traffic into two channels, you create two connection points between the appliances, increasing throughput and thus improving performance. You can also enable multiple management interfaces, each with a unique IP address (IPv4 or IPv6) and hostname, to separate and manage traffic channels and provide still greater throughput.

With multiple management interfaces, you can also isolate and manage traffic from different networks using only one Defense Center. You use a management interface to add a static route to the destination network, and register devices to the separate management interfaces to ensure that traffic from one network is isolated from traffic on another network. You can send both traffic channels on the same interface, or, if you have enough additional management interfaces, you can both isolate the network traffic and configure each management interface to carry only one traffic channel.

Management interfaces are often located on the back of the appliance. See Identifying the Management Interfaces in FireSIGHT System Installation Guide for more information. To learn more about management interfaces, see the following sections for more information:

- Using a Single Management Interface

- Using Multiple Management Interfaces

- Using Traffic Channels

- Using Network Routes

Using a Single Management Interface

License: Any

Supported Devices: Any

Supported Defense Centers: Any

When you register your device to a Defense Center, you establish a single communication channel that carries all traffic between the management interface on the Defense Center and the management interface on the device.

The following graphic shows the default single communication channel. One interface carries one communication channel that contains both management and event traffic.

Using Multiple Management Interfaces

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3, Virtual

You can enable and configure multiple management interfaces, each with a unique IP address (IPv4 or IPv6) and, optionally, a hostname, to provide greater traffic throughput by sending each traffic channel to a different management interface. Configure a smaller interface to carry the lighter management traffic load, and a larger interface to carry the heavier event traffic load. You can register devices to separate management interfaces and configure both traffic channels for the same interface, or use a dedicated management interface to carry the event traffic channels for all devices managed by the Defense Center.

You can also create a route from a specific management interface on your Defense Center to a device on a different network. When you register a device on a different network to a non-default management interface, traffic on that device is isolated from traffic on devices registered to the default (eth0) management interface. See Using Network Routes for more information.

Non-default management interfaces have many of the same capabilities as the default management interface (such as using high availability between the Defense Centers) with the following exceptions:

- You can configure DHCP on the default ( eth0 ) management interface only. Additional ( eth1 and so on) interfaces require unique static IP addresses and hostnames.

- You must configure both traffic channels to use the same management interface when you use a non-default management interface to connect your Defense Center and managed device and those appliances are separated by a NAT device.

- You can use Lights-Out Management on the default management interface only.

- On the 70xx Family, you can separate traffic into two channels and configure those channels to send traffic to one or more management interfaces on the Defense Center. However, because the 70xx Family contains only one management interface, the device receives traffic sent from the Defense Center on only one management interface.

Using Traffic Channels

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3, Virtual

When you use two traffic channels on one management interface, you create two connections between the Defense Center and the managed device. One channel carries management traffic and one carries event traffic, separately and on the same interface.

When you use multiple management interfaces, you can improve your performance by dividing the traffic channels over two management interfaces, thus increasing the traffic flow by adding the capacity of both interfaces. One interface carries the management traffic channel and the other carries the event traffic channel. If either interface fails, all traffic reroutes to the active interface and the connection is maintained.

The following graphic shows the management traffic channel and the event traffic channel over two management interfaces.

You can use a dedicated management interface to carry only event traffic from multiple devices. In this configuration, each device is registered to a different management interface to carry the management traffic channel, and one management interface on the Defense Center carries all event traffic channels from all devices. If an interface fails, traffic reroutes to the active interface and the connection is maintained. Note that because event traffic for all devices is carried on the same interface, traffic is not isolated between networks.

The following graphic shows two devices using different management channel traffic interfaces sharing the same dedicated interface for event traffic channels.

When you use two traffic channels on one management interface, you create two connections between the Defense Center and the managed device. One channel carries management traffic and one carries event traffic, separately and on the same interface. Using multiple management interfaces, you can improve your performance further by dividing the traffic channels over two management interfaces, thus increasing the traffic flow by adding the capacity of both interfaces. One interface carries the management traffic channel and the other carries the event traffic channel. If either interface fails, all traffic reroutes to the active interface and the connection is maintained.

You can also use a dedicated management interface to carry only event traffic from multiple devices. In this configuration, each device is registered to a different management interface to carry the management traffic channel, and one management interface on the Defense Center carries all event traffic channels from all devices. If an interface fails, traffic reroutes to the active interface and the connection is maintained. Note that because event traffic for all devices is carried on the same interface, traffic is not isolated between networks.

Using Network Routes

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3, Virtual

You can create a route from a specific management interface on your Defense Center to a different network. When you register a device from that network to the specified management interface on the Defense Center, you provide an isolated connection between the Defense Center and the device on a different network. Configure both traffic channels to use the same management interface to ensure that traffic from that device remains isolated from device traffic on other networks. Because the routed interface is isolated from all other interfaces on the Defense Center, if the routed management interface fails, the connection is lost.

Tip Cisco recommends that you use the static IP address when you register a Defense Center and its devices using any management interface other than the default (eth0) management interface. DHCP is supported only on the default management interface.

After you install your Defense Center, you configure multiple management interfaces using the web interface. See Configuring Appliance Settings in the FireSIGHT System User Guide for more information.

The following graphic shows two devices isolating network traffic by using separate management interfaces for all traffic. You can add more management interfaces to configure separate management and event traffic channel interfaces for each device.

Working in NAT Environments

License: Any

Network address translation (NAT) is a method of transmitting and receiving network traffic through a router that involves reassigning the source or destination IP address as the traffic passes through the router. Typical applications using NAT enable multiple hosts on a private network to use a single public IP address to access the public network.

When you add a device to a Defense Center, you establish communications between the appliances. The information you need to establish communications depends on whether the environment uses NAT:

- In an environment without NAT, you need a registration key and the IP addresses or fully qualified domain names of both appliances.

- In an environment with NAT, you need a registration key and a unique NAT ID.

Note The NAT ID must be unique among all NAT IDs used to register devices to a Defense Center.

Note that when you use a non-default management interface to connect your Defense Center and managed device and those appliances are separated by a NAT device, you must configure both traffic channels to use the same management interface.

The following diagram shows a Defense Center managing two devices in a NAT environment. You can use the same registration key when adding both devices, because registration keys do not have to be unique. However, you must use unique NAT IDs when adding the devices to the Defense Center.

Configuring High Availability

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

To ensure the continuity of operations, the high availability feature allows you to designate redundant Defense Centers to manage devices. Event data streams from managed devices to both Defense Centers and certain configuration elements are maintained on both Defense Centers. If one Defense Center fails, you can monitor your network without interruption using the other Defense Center.

Caution Because the system restricts some functionality to the primary Defense Center, if that appliance fails, you must promote the secondary Defense Center to Active. See Monitoring and Changing High Availability Status.

See the following sections for more information about setting up high availability:

- Using High Availability lists the configurations that are and are not shared when you implement high availability.

- Guidelines for Implementing High Availability outlines guidelines you must follow if you want to implement high availability.

- Setting Up High Availability explains how to specify primary and secondary Defense Centers.

- Monitoring and Changing High Availability Status explains how to check the status of your linked Defense Centers and how to change the roles of the Defense Center if the primary Defense Center fails.

- Disabling High Availability and Unregistering Devices explains how to permanently remove the link between linked Defense Centers.

- Pausing Communication Between Paired Defense Centers explains how to pause communications between linked Defense Centers.

- Restarting Communication Between Paired Defense Centers explains how to restart communications between linked Defense Centers.

Using High Availability

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

DC1500s, DC2000s, DC3500s, and DC4000s support high availability configurations; DC750s and the virtual Defense Centers do not. Cisco strongly recommends that both Defense Centers in a high availability pair be the same model. Do not attempt to set up high availability between different Defense Center models.

Although Defense Centers in high availability mode are designated primary and secondary, you can make policy or other changes to either Defense Center. However, Cisco recommends that you change configurations only on the primary Defense Center and that you keep your secondary Defense Center as a backup.

Defense Centers periodically update each other on changes to their configurations, and any change you make to one Defense Center should be applied on the other Defense Center within ten minutes. (Each Defense Center has a five-minute synchronization cycle, but the cycles themselves could be out of synchronization by as much as five minutes, so changes appear within two five-minute cycles.) During this ten-minute window, configurations may appear differently on the Defense Centers.

For example, if you create a policy on your primary Defense Center and apply it to a device that is also managed by your secondary Defense Center, the device could contact the secondary Defense Center before the Defense Centers contact each other. Because the device has a policy applied to it that the secondary Defense Center does not recognize, the secondary Defense Center displays a new policy with the name “unknown” until the Defense Centers synchronize.

Also, if you make conflicting policy or other changes to both Defense Centers within the same window between Defense Centers syncs, the last change you make takes precedence, regardless of the designations of the Defense Center as primary and secondary.

Before you establish a high availability pair, note the following prerequisites:

- Make sure both Defense Centers have a user account named admin with Administrator privileges. These accounts must use the same password.

- Make sure that other than the admin account, the two Defense Centers do not have user accounts with identical user names. Remove or rename one of the duplicate user accounts before you establish high availability.

Note that Defense Centers configured as a high availability pair do not need to be on the same trusted management network, nor do they have to be in the same geographic location.

To ensure continuity of operations, both Defense Centers in a high availability pair must have Internet access; see Internet Access Requirements. For specific features, the primary Defense Center contacts the Internet, then shares information with the secondary during the synchronization process. Therefore, if the primary fails, you should promote the secondary to Active as described in Monitoring and Changing High Availability Status.

For more information on which configurations are shared or not shared between members of a high availability pair, see:

- Shared Configurations

- Health and System Policies

- Correlation Responses

- Licenses

- URL Filtering and Security Intelligence

- Cloud Connections and Malware Information

- User Agents

Shared Configurations

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Defense Centers in a high availability pair share the following information:

- user account attributes, authentication configurations, and custom user roles

- authentication objects for user accounts and user awareness, as well as the users and groups that are available to user conditions in access control rules

- custom dashboards

- custom workflows and tables

- device attributes, such as the device’s host name, where events generated by the device are stored, and the group in which the device resides

- access control, SSL, network analysis, intrusion, file, and network discovery policies

- local intrusion rules

- custom intrusion rule classifications

- network discovery policies

- user-defined application protocol detectors and the applications they detect

- activated custom fingerprints

- host attributes

- network discovery user feedback, including notes and host criticality; the deletion of hosts, applications, and networks from the network map; and the deactivation or modification of vulnerabilities

- correlation policies and rules, compliance white lists, and traffic profiles

- change reconciliation snapshots and report settings

- intrusion rule, geolocation database (GeoDB), and vulnerability database (VDB) updates

- reusable objects, including variable sets, associated with any of the above configurations

Health and System Policies

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Health and system policies for Defense Centers and managed devices are shared in high availability pairs. Allow enough time to ensure that information about health policies, modules, blacklists, is synchronized on a newly activated Defense Center.

Note Although system policies are shared by Defense Centers in a high availability pair, they are not automatically applied. If you want identical system policies on both Defense Centers, apply the policy after it synchronizes.

Defense Centers in a high availability pair share the following system and health policy information:

- system policies

- system policy configurations (what policy is applied where)

- health policies

- health monitoring configurations (what policy is applied where)

- which appliances are blacklisted from health monitoring

- which appliances have individual health monitoring policies blacklisted

Correlation Responses

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Although Defense Centers share correlation policies, rules, and responses, Defense Centers do not share the associations between correlation rules and their responses. This is to avoid launching duplicate responses when correlation policies are violated.

You must upload and install any custom remediation modules and configure remediation instances on your secondary Defense Center before remediations are available to associate with correlation policies. If the primary Defense Center fails, not only should you quickly associate your correlation policies with the appropriate responses and remediations on the secondary Defense Center, but you must also use the web interface on the secondary Defense Center to promote it to Active to maintain continuity of operations. For more information, see Monitoring and Changing High Availability Status. For more information about correlation responses, see Creating Correlation Policies and Creating Remediations.

When you restore your primary Defense Center after a failure, if you created associations between rules or white lists and their responses and remediations on the secondary Defense Center, make sure you remove the associations so responses and remediations will only be generated by the primary Defense Center.

Licenses

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Defense Centers in a high availability pair do not share licenses. You must add equivalent licenses to each member of the pair. For more information, see Understanding Licensing.

URL Filtering and Security Intelligence

License: URL Filtering or Protection

Supported Devices: Series 3, virtual, X-Series, ASA FirePOWER

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

URL filtering and Security Intelligence configurations and information are synchronized between Defense Centers in a high availability deployment. However, only the primary Defense Center downloads URL category and reputation data and for updates to Security Intelligence feeds.

If the primary Defense Center fails, not only must you make sure that the secondary Defense Center can access the URL filtering cloud and any configured feed sites, but you must also use the web interface on the secondary Defense Center to promote it to Active. For information, see Monitoring and Changing High Availability Status.

Cloud Connections and Malware Information

License: Any or Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Although they share file policies and related configurations, Defense Centers in a high availability pair share neither Collective Security Intelligence Cloud connections nor malware dispositions. To ensure continuity of operations, and to ensure that detected files’ malware dispositions are the same on both Defense Centers, both primary and secondary Defense Centers must have access to the cloud. For more information, see Understanding Malware Protection and File Control.

User Agents

License: FireSIGHT

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

User Agents can connect to up to five Defense Centers at a time. You should connect agents to the primary Defense Center. If the primary Defense Center fails, you must make sure that any agents can communicate with the secondary Defense Center. See Using User Agents to Report Active Directory Logins for more information.

Guidelines for Implementing High Availability

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

To take advantage of high availability, you must follow the guidelines in the following sections.

Primary and Secondary Defense Center Requirements

You must designate one Defense Center as the primary Defense Center and one as the secondary. When appliances switch from Active to Inactive (and vice versa), they retain their original primary and secondary designations.

Regardless of their designations as primary and secondary, both Defense Centers can be configured with policies, rules, managed devices, and so on before you set up high availability.

To avoid confusion, start with the secondary Defense Center in its original state. That is, you have not created or modified any policies, nor created any new rules, nor have you previously managed any devices with it. To make sure the secondary Defense Center is in its original state, restore it to factory defaults. Note that this also deletes event and configuration data from the Defense Center. For more information, see the FireSIGHT System Installation Guide.

Version Requirements

Both Defense Centers must be running the same software and rule update version. Additionally, this software version must be the same or newer than the software version of managed devices.

Communication Requirements

By default, paired Defense Centers use port 8305/tcp for communications. You can change the port as described in Changing the Management Port.

The two Defense Centers do not need to be on the same network segment, but each of the Defense Centers must be able to communicate with the other and with the devices they share. That is, the primary Defense Center must be able to contact the secondary Defense Center at the IP address on the secondary Defense Center’s own management interface, and vice versa. In addition, each Defense Center must be able to contact the devices it manages or the devices must be able to contact the Defense Center.

Setting Up High Availability

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

To use high availability, you must designate one Defense Center as the primary and another Defense Center of the same model as the secondary. For information about editing the remote management communications between the two appliances, see Editing Remote Management.

Caution Cisco recommends that you change configurations only on the primary Defense Center and that you use your secondary Defense Center as a backup.

Before you configure high availability, make sure you synchronize time settings between the Defense Centers you want to link. For details on setting time, see Synchronizing Time.

Depending upon the number of policies and custom standard text rules they have, it may take up to 10 minutes before all the rules and policies appear on both Defense Centers. You can view the High Availability page to check the status of the link between the two Defense Centers. You can also monitor the Task Status to see when the process completes. See Monitoring and Changing High Availability Status.

If one of the Defense Centers in the high availability pair must be reimaged, disable the high availability link first. After you reimage the Defense Center, re-establish the high availability pair and the data will synchronize from the existing Defense Center to the newly added Defense Center. If a Defense Center cannot be reimaged (for example, the appliance has failed), contact Support.

To set up high availability for two Defense Centers:

Access: Admin

Step 1 Log into the Defense Center that you want to designate as the secondary Defense Center.

Step 2 Select System > Local > Registration.

The Registration page appears.

Step 3 Click High Availability.

The High Availability page appears.

Step 4 Click the secondary Defense Center option.

The Secondary Defense Center Setup page appears.

Step 5 Type the hostname or IP address of the primary Defense Center in the Primary DC Host text box.

Caution Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses.

Note that you can leave the Primary DC Host field empty if the management host does not have a routable address. In that case, use both the Registration Key and the Unique NAT ID fields.

Step 6 Type a one-time-use registration key in the Registration Key text box

Step 7 Optionally, in the Unique NAT ID field, type a unique alphanumeric registration ID that you want to use to identify the primary Defense Center. Do not see Managing Stacked Devices. See Working in NAT Environments on 4-8 for more information.

Step 8 Click Register.

A success message appears, and the Peer Manager page appears, showing the current state of the secondary Defense Center.

Step 9 Using an account with Admin access, log into the Defense Center that you want to designate as the primary.

Step 10 Select System > Local > Registration.

The Registration page appears.

Step 11 Click High Availability.

The High Availability page appears.

Step 12 Click the primary Defense Center option.

The Primary Defense Center Setup page appears.

Step 13 Type the hostname or IP address of the secondary Defense Center in the Secondary DC Host text box.

Caution Make sure you use hostnames rather than IP addresses if your network uses DHCP to assign IP addresses.

Step 14 Type the same one-time-use registration key in the Registration Key text box you used in step 6.

Step 15 If you used a unique NAT ID on the secondary Defense Center, type the same registration ID that you used in step 7 in the Unique NAT ID text box.

Step 16 Click Register.

A success message appears, and the Peer Manager page appears, showing the current state of the primary Defense Center.

Monitoring and Changing High Availability Status

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

After you have identified your primary and secondary Defense Centers, from either appliance in the high availability pair you can view information about the local Defense Center and its peer, including:

- the peer IP address or host name

- the peer product model

- the peer software version

- the peer operating system

- the amount of time since the members of the high availability pair last synchronized

- the role and status of the local appliance (Active & Primary, Inactive & Primary, Inactive & Secondary, or Active & Secondary)

You can also use the High Availability page to change the roles of the Defense Centers if the primary Defense Center fails. Because the system restricts the following functionality to the primary Defense Center, if that appliance fails, you must promote the secondary Defense Center to Active:

- Updates to URL category and reputation data; see URL Filtering and Security Intelligence for more information.

- Updates to Security Intelligence feeds; see URL Filtering and Security Intelligence for more information.

- Associations between correlation rules and responses; see Correlation Responses for more information.

To check high availability status:

Access: Admin

Step 1 Log into one of the Defense Centers that you linked using high availability.

Step 2 Select System > Local > Registration.

The Registration page appears.

Step 3 Click High Availability.

The High Availability page appears.

Step 4 Under High Availability Status, you can view the following information about the Defense Centers in the high availability pair:

- the peer IP address or host name

- the peer product model

- the peer software version

- the peer operating system

- the amount of time since the members of the high availability pair last synchronized

- the role and status of the local appliance (Active & Primary, Inactive & Primary, Inactive & Secondary, or Active & Secondary)

- the option to switch roles between the two Defense Centers

Step 5 The two Defense Centers automatically synchronize within ten minutes (five minutes for each Defense Center) after any action that affects a shared feature. For example, if you create a new policy on one Defense Center, it is automatically shared with the other Defense Center within 5 minutes. However, if you want to synchronize the policy immediately, click Synchronize.

Note If you delete a device from a Defense Center configured in a high availability pair and intend to re-add it, Cisco recommends that you wait at least five minutes before adding the device back. This interval ensures that the high availability pair resynchronizes first. If you do not wait five minutes, it may take more than one synchronization cycle to add the device to both Defense Centers.

Step 6 Click Switch Roles to change the local role from Active to Inactive, or Inactive to Active.

With the Primary or Secondary designation unchanged, the roles are switched between the two peers.

Step 7 Click Peer Manager in the toolbar.

The Peer Manager page appears.

You can view the following information:

- the IP address of the other Defense Center in the high availability pair

- the status, registered or unregistered, of the communications link

- the state, enabled or disabled, of the high availability pair

For information about editing the remote management communications between the two appliances, see Editing Remote Management.

Disabling High Availability and Unregistering Devices

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

If you want to remove one of the Defense Centers from a high availability pair, you must first disable the high availability link between them.

To disable a high availability pair:

Access: Admin

Step 1 Log into one of the Defense Centers in the high availability pair.

Step 2 Select System > Local > Registration.

The Registration page appears.

Step 3 Click High Availability.

The High Availability page appears.

Step 4 Select one of the following options from the Handle Registered Devices drop-down list:

- To control all the managed devices with the Defense Center where you are accessing this page, select Unregister devices on the other peer .

- To control all the managed devices with the other Defense Center, select Unregister devices on this peer .

- To stop managing the devices altogether, select Unregister devices on both peers .

Step 5 Click Break High Availability.

After you answer the prompt Do you really want to Break High Availability? by selecting OK, high availability is disabled and any managed devices are deleted from the Defense Centers according to your selection.

You can enable high availability with a different Defense Center as described in Setting Up High Availability.

Pausing Communication Between Paired Defense Centers

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

If you want to temporarily disable high availability, you can disable the communications channel between the Defense Centers.

To disable the communications channel for a high availability pair:

Access: Admin

Step 1 Click Peer Manager.

The Peer Manager page appears.

Step 2 Click the slider to disable the communications channel between the two Defense Centers.

For information about editing the remote management communications between the two appliances, see Editing Remote Management.

Restarting Communication Between Paired Defense Centers

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

If you temporarily disabled high availability, you can enable the communications channel between the Defense Centers to restart high availability.

To enable the communications channel for a high availability pair:

Access: Admin

Step 1 Click Peer Manager.

The Peer Manager page appears.

Step 2 Click the slider to enable the communications channel between the two Defense Centers.

For information about editing the remote management communications between the two appliances, see Editing Remote Management.

Working with Devices

License: Any

You can use the Defense Center to manage the full range of devices that are a part of the FireSIGHT System. When you manage a device, you set up a two-way, SSL-encrypted communication channel between the Defense Center and the device. The Defense Center uses this channel to send information to the device about how you want to analyze and manage your network traffic.

As the device evaluates the traffic, it generates events and sends them to the Defense Center using the same channel.

See the following sections for more information about managing devices:

- Understanding the Device Management Page

- Configuring Remote Management

- Adding Devices to the Defense Center

- Configuring Remote Management

- Managing Device Groups

- Clustering Devices

- Editing Device Configuration

- Configuring Sensing Interfaces

Understanding the Device Management Page

License: Any

The Device Management page provides you with a range of information and options that you can use to manage your registered devices, device clusters, and device groups. The page displays a list of all the devices currently registered on the Defense Center.

You can use the sort-by drop-down list to sort the appliance list according to your needs. Devices are displayed in the appliance list grouped by the category you select. You can sort by:

- Group (that is, device group); see Managing Device Groups for more information

- Type (that is, the type of licenses applied to the device); see Licensing the FireSIGHT System for more information

- Model (that is, the model of the device being managed by the Defense Center)

- Health Policy; see Using Health Monitoring for more information

- System Policy; see Managing System Policies for more information

- Access Control Policy; see Managing Access Control Policies for more information

For device groups, you can expand and collapse the list of devices in the group. The list appears collapsed by default.

Table 4-1 Appliance List Fields

Field

Description

Name

A list of the hostname, IP address, device model, and software version for each device. The status icon to the left of the appliance indicates its current health status.

License Type

The licenses that are enabled on the managed device.

Health Policy

The currently applied health policy for the device. You can click the name of the health policy to view a read-only version of the policy. See Editing Health Policies for information about modifying an existing health policy.

System Policy

The currently applied system policy for the device. You can click the name of the system policy to view a read-only version of the policy. See Managing System Policies for more information.

Access Control Policy

A link to the currently applied access control policy. See Managing Access Control Policies.

See the following sections for more information:

- Configuring Remote Management

- Adding Devices to the Defense Center

- Managing Device Groups

- Clustering Devices

- Managing Stacked Devices

Configuring Remote Management

License: Any

Before you can manage one FireSIGHT System appliance with another, you must set up a two-way, SSL-encrypted communication channel between the two appliances. The appliances use the channel to share configuration and event information. High availability peers also use the channel, which is by default on port 8305/tcp.

You must configure remote management on the appliance that will be managed, that is, on the device that you want to manage with a Defense Center. After you configure remote management, you can use the managing appliance’s web interface to add the managed appliance to your deployment.

Note that the procedure in this section explains how to configure remote management on FirePOWER physical appliances.

To enable communications between two appliances, you must provide a way for the appliances to recognize each other. There are three criteria the FireSIGHT System uses when allowing communications:

- the hostname or IP address of the appliance with which you are trying to establish communication

In NAT environments, even if the other appliance does not have a routable address, you must provide a hostname or an IP address either when you are configuring remote management, or when you are adding the managed appliance.

- a self-generated alphanumeric registration key up to 37 characters in length that identifies the connection

- an optional unique alphanumeric NAT ID that can help the FireSIGHT System establish communications in a NAT environment

The NAT ID must be unique among all NAT IDs used to register managed appliances. For more information, see Working in NAT Environments.

When you register a managed device to a Defense Center, you can select an access control policy to apply to the device. However, if the device is incompatible with the policy, the policy apply fails. This incompatibility could occur for multiple reasons, including licensing mismatches, model restrictions, passive vs inline issues, and other misconfigurations. If the initial access control policy apply fails, the initial network discovery policy apply also fails. After you resolve the issue that caused the failure, you must manually apply access control and network discovery policies to the device. For more information about issues that could cause access control policy apply to fail, see Troubleshooting Access Control Policies and Rules.

To configure remote management of the local appliance:

Access: Admin

Step 1 On the web interface for the device you want to manage, select System > Local > Registration.

The Remote Management page appears.

Caution Cisco strongly recommends that you not change the value for the management port. If you change it, you must also change it for all appliances in your deployment that need to communicate with each other. For more information, see Changing the Management Port.

Step 2 Click Add Manager.

The Add Remote Management page appears.

Step 3 In the Management Host field, type the IP address or the hostname of the appliance that you want to use to manage this appliance.

The hostname is the fully qualified domain name or the name that resolves through the local DNS to a valid IP address.

In a NAT environment, you do not need to specify an IP address or hostname here if you plan to specify it when you add the managed appliance. In this case, the FireSIGHT System uses the NAT ID you will provide later to identify the remote manager on the managed appliance’s web interface.

Caution Use a hostname rather than an IP address if your network uses DHCP to assign IP addresses.

Step 4 In the Registration Key field, type the registration key that you want to use to set up communications between appliances.

Step 5 For NAT environments, in the Unique NAT ID field, type a unique alphanumeric NAT ID that you want to use to set up communications between appliances.

Step 6 Click Save.

After the appliances confirm that they can communicate with each other, the Pending Registration status appears.

Step 7 Use the managing appliance’s web interface to add this appliance to your deployment.

For more information, see Adding Devices to the Defense Center.

Note When enabling remote management of a device, in some high availability deployments that use NAT, you may also need to add the secondary Defense Center as a manager. For more information, contact Support.

Editing Remote Management

License: Any

Use the following procedure to edit the hostname or IP address of the managing appliance. You can also change the display name of the managing appliance, which is a name only used within the context of the FireSIGHT System. Although you can use the hostname as the display name of the appliance, entering a different display name does not change the hostname.

Note that you cannot add devices running software more than one major version lower than the Defense Center. For example, if your Defense Center is running Version 5.4.0, you can add devices running 5.3.x or higher but not devices running 5.2.x.

Tip You can click the slider to enable or disable management of the managed device. Disabling management blocks the connection between the Defense Center and the device, but does not delete the device from the Defense Center. If you no longer want to manage a device, see Deleting Devices.

To edit remote management:

Access: Admin

Step 1 On the web interface for the device, select System > Local > Registration.

The Remote Management page appears.

) next to the manager for which you want to edit remote management settings.

The Edit Remote Management page appears.

Step 3 In the Name field, change the display name of the managing appliance.

Step 4 In the Host field, change the IP address or the hostname of the managing appliance.

The hostname is the fully qualified domain name or the name that resolves through the local DNS to a valid IP address.

Step 5 Click Save.

Your changes are saved.

Changing the Management Port

License: Any

FireSIGHT System appliances communicate using a two-way, SSL-encrypted communication channel, which by default is on port 8305.

Although Cisco strongly recommends that you keep the default setting, if the management port conflicts with other communications on your network, you can choose a different port. Usually, changes to the management port are made during installation of the FireSIGHT System.

Caution If you change the management port, you must change it for all appliances in your deployment that need to communicate with each other.

To change the management port:

Access: Admin

Step 1 On the web interface for the device, select System > Local > Configuration.

The Information page appears.

Step 2 Click Network.

The Network Settings page appears.

Step 3 In the Remote Management Port field, enter the port number that you want to use.

Step 4 Click Save.

The management port is changed.

Step 5 Repeat this procedure for every appliance in your deployment that must communicate with this appliance.

Adding Devices to the Defense Center

License: Any

When you manage a device, you set up a two-way, SSL-encrypted communication channel between the Defense Center and the device. The Defense Center uses this channel to send information about how you want to analyze your network traffic to the device. As the device evaluates the traffic, it generates events and sends them to the Defense Center using the same channel. For more information about configuring this channel, see Configuring Remote Management.

Note that you cannot add devices running software more than one major version lower than the Defense Center. For example, if your Defense Center is running Version 5.4, you can add devices running Version 5.3.x or higher but not devices running Version 5.2.x.

Before you manage a device with a Defense Center, you must make sure that the network settings are configured correctly on the device. This is usually completed as part of the installation process. See Configuring Management Interfaces for more information.

Note that if you registered a Defense Center and a device using IPv4 and want to convert them to IPv6, you must delete and re-register the device.

When you register a managed device to a Defense Center, you can select an access control policy to apply to the device. However, if the device is incompatible with the policy, the policy apply fails. This incompatibility could occur for multiple reasons, including licensing mismatches, model restrictions, passive vs inline issues, and other misconfigurations. If the initial access control policy apply fails, the initial network discovery policy apply also fails. After you resolve the issue that caused the failure, you must manually apply access control and network discovery policies to the device. For more information on issues that could cause access control policy apply to fail, see Troubleshooting Access Control Policies and Rules.

When you register a device cluster or device stack, although you can select licenses, these licenses cannot be applied upon device registration. This ensures that the cluster or stack is running the proper licenses to prevent it from entering a degraded state with mismatched licenses. After registration, you can evaluate the licenses in either the general properties (cluster) or stack properties (stack) of the Device Management page. For more information, see Establishing Device Clusters or Establishing Device Stacks.

When you register a Series 2 device, although you can select licenses, any licenses you select are not applied upon device registration. Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence filtering. You cannot disable these capabilities, nor can you apply other licenses to a Series 2 device.

To add a device to a Defense Center:

Access: Admin/Network Admin

Step 1 Configure the device to be managed by the Defense Center.

For FirePOWER devices, use the procedure in Configuring Remote Management. After the device confirms communication with the Defense Center, the Pending Registration status appears.

For virtual devices, Cisco NGIPS for Blue Coat X-Series, and ASA FirePOWER devices, configure remote management using the device’s command line interface (CLI).

Note In some high availability deployments where network address translation (NAT) is used, you may also need to add the secondary Defense Center as a manager. For more information, contact Support.

Step 2 On the web interface for the Defense Center, select Devices > Device Management.

The Device Management page appears.

Step 3 From the Add drop-down menu, select Add Device.

The Add Device pop-up window appears.

Step 4 In the Host field, type the IP address or the hostname of the device you want to add.

The hostname of the device is the fully qualified domain name or the name that resolves through the local DNS to a valid IP address.

Note that in a NAT environment, you may not need to specify the IP address or host name of the device, if you already specified the IP address or host name of the Defense Center when you configured the device to be managed by the Defense Center. For more information, see Working in NAT Environments.

Caution Use a hostname rather than an IP address if your network uses DHCP to assign IP addresses.

Step 5 In the Registration Key field, type the same registration key that you used when you configured the device to be managed by the Defense Center.

Step 6 Optionally, add the device to a device group by selecting the group from the Group drop-down list.

For more information about device groups, see Managing Device Groups.

Step 7 From the Access Control Policy drop-down list, select an initial policy to apply to the device:

- The Default Access Control policy blocks all traffic from entering your network.

- The Default Intrusion Prevention policy allows all traffic that is also passed by the Balanced Security and Connectivity intrusion policy.

- The Default Network Discovery policy allows all traffic, which is inspected by network discovery only.

- You can select any existing user-defined access control policy.

For more information, see Managing Access Control Policies.

Step 8 Select licenses to apply to the device. Note that:

- Control, Malware, and URL Filtering licenses require a Protection license.

- You cannot enable a VPN license on a virtual device, Cisco NGIPS for Blue Coat X-Series, or ASA FirePOWER device.

- You cannot enable a Control license on Cisco NGIPS for Blue Coat X-Series.

- Although you can enable a Control license on a virtual device or ASA FirePOWER device, these devices do not support fast-path rules, switching, routing, stacking, or clustering.

- You cannot change the license settings on clustered devices.

- For stacked devices, you enable or disable the licenses for the stack on the Stack page of the appliance editor.

- When you register a Series 2 device, any licenses you select are not applied upon device registration. Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence filtering. You cannot disable these capabilities, nor can you apply other licenses to a Series 2 device.

For more information, see Licensing the FireSIGHT System.

Step 9 If you used a NAT ID to identify the device when you configured it to be managed by the Defense Center, expand the Advanced section and enter the same NAT ID in the Unique NAT ID field.

Step 10 To allow the device to transfer packets to the Defense Center, select the Transfer Packets check box.

This option is enabled by default. If you disable it, you completely prohibit packet transfer to the Defense Center.

Step 11 Click Register.

The device is added to the Defense Center. Note that it may take up to two minutes for the Defense Center to verify the device’s heartbeat and establish communication.

Applying Changes to Devices

License: Any

After you make changes to the configuration of a device, a device cluster, or a device stack, you must apply the changes before they take effect throughout the system. Note that the device must have unapplied changes or this option remains disabled.

Tip You can apply device changes from the Device Management page or from the Interfaces tab of the appliance editor.

To apply changes to the device:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

Step 3 When prompted, click Apply.

The device changes are applied.

Tip Optionally, from the Apply Device Changes dialog box, click View Changes. The Device Management Revision Comparison Report page appears in a new browser window. For more information, see Using the Device Management Revision Comparison Report.

Step 4 Click OK.

You are returned to the Device Management page.

Using the Device Management Revision Comparison Report

License: Any

A device management comparison report allows you to view the changes you have made to an appliance before you apply them. The report displays all differences between the current appliance configuration and the proposed appliance configuration. This gives you an opportunity to discover any potential configuration errors.

To compare appliance changes before applying them:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Apply Device Changes pop-up window appears. Note that the appliance must have unapplied changes or the apply icon remains disabled.

Step 3 Click View Changes.

The Device Management Revision Comparison Report page appears in a new window.

Step 4 Click Previous and Next to scroll through the differences between the current appliance configuration and the proposed appliance configuration.

Step 5 Optionally, click Comparison Report to produce a PDF version of the report.

Deleting Devices

License: Any

If you no longer want to manage a device, you can delete it from the Defense Center. Deleting a device severs all communication between the Defense Center and the device. To manage the device again at a later date, you must re-add it to the Defense Center.

Note If you delete a device from a Defense Center configured in a high availability pair and want to re-add it, Cisco recommends that you wait at least five minutes before re-adding it. This interval ensures that the high availability pair resynchronizes so that both Defense Centers recognize the deletion. If you do not wait five minutes, it may take more than one synchronization cycle to add the device to both Defense Centers.

To delete a device from the Defense Center:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

When prompted, confirm that you want to delete the device. Communication between the device and the Defense Center is discontinued and the device is deleted from the Device Management page. If the device has a system policy that causes it to receive time from the Defense Center via NTP, the device reverts to local time management.

Managing Device Groups

License: Any

The Defense Center allows you to group devices so you can easily apply policies and install updates on multiple devices. You can expand and collapse the list of devices in the group. The list appears collapsed by default.

See the following sections for more information:

- Adding Device Groups

- Editing Device Groups

- Deleting Device Groups

Adding Device Groups

License: Any

The following procedure explains how to add a device group so you can easily apply policies and install updates on multiple devices.

If you add the primary device in a stack or a cluster to a group, both devices are added to the group. If you unstack or uncluster the devices, both devices remain in that group.

To create a device group and add devices to it:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

Step 2 From the Add drop-down menu, select Add Group.

The Add Group pop-up window appears.

Step 3 In the Name field, type the name of the group.

Step 4 Under Available Devices, select one or more appliances to add to the device group. Use Ctrl or Shift while clicking to select multiple appliances.

Step 5 Click Add to include the selected appliances in the device group.

Step 6 Click OK.

The device group is added.

Editing Device Groups

License: Any

You can change the set of devices that reside in any device group. You must remove an appliance from its current group before you can add it to a new group.

Moving an appliance to a new group does not change its policy to the policy previously applied to the group. To change the device’s policy, you must apply a new policy to the device or device group.

Note that if you add the primary device in a stack or a cluster to a group, both devices are added to the group. If you unstack or uncluster the devices, both devices remain in that group.

To edit a device group:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Edit Group pop-up window appears.

Step 3 Optionally, in the Name field, type a new name for the group

Step 4 Under Available Devices, select one or more appliances to add to the device group. Use Ctrl or Shift while clicking to select multiple appliances.

Step 5 Click Add to include the selected appliances in the device group.

).

Step 7 Click OK.

The changes to the device group are saved.

Deleting Device Groups

License: Any

If you delete a device group that contains devices, the devices are moved to the Ungrouped category on the Device Management page. They are not deleted from the Defense Center.

To delete a device group:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

Step 3 When prompted, confirm that you want to delete the device group.

The device group is deleted.

Clustering Devices

License: Control

Supported Devices: Series 3

With device clustering (also called device high availability), you can establish redundancy of networking functionality and configuration data between two peer devices or two peer device stacks. See Managing Stacked Devices for more information about stacking devices.

You achieve configuration redundancy by clustering two peer devices or two peer device stacks as a single logical system for policy applies, system updates, and registration. The system automatically synchronizes other configuration data.

Clustering Requirements

Before you can configure a device cluster, both devices or device stack primary members must be the same model and have identical copper or fiber interfaces. Both devices or device stacks must also be running the same software and have the same licenses. Device stacks must have identical hardware configurations, except for an installed malware storage pack. For example, you can cluster a 3D8290 with a 3D8290; none, one, or all devices in either stack might have a malware storage pack. If the devices are targeted by NAT policies, both peers must have the same NAT policy. After you cluster the devices, you cannot change the license options for individual clustered devices, but you can change the license for the entire cluster. See Establishing Device Clusters for more information.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware storage pack. See the FireSIGHT System Malware Storage Pack Guide for more information.

Clustering Failover and Maintenance Mode

With a device cluster, the system fails over either manually or automatically. You manually trigger failover by placing one of the clustered devices or stacks in maintenance mode. For more information about maintenance mode, see Placing a Clustered Device into Maintenance Mode.

Automatic failover occurs after the health of the active device or stack becomes compromised, during a system update, or after a user with Administrator privileges shuts down the device. Automatic failover also occurs after an active device or device stack experiences NMSB failure, NFE failure, hardware failure, firmware failure, critical process failure, a disk full condition, or link failure between two stacked devices. If the health of the backup device or stack becomes similarly compromised, the system does not fail over and enters a degraded state. The system also does not fail over when one of the devices or device stacks is in maintenance mode. Note that disconnecting the stacking cable from an active stack sends that stack into maintenance mode. Shutting down the secondary device in an active stack also sends that stack into maintenance mode.

Note If the active cluster member goes into maintenance mode and the active role fails over to the other cluster member, when the original active cluster member is restored to normal operation it does not automatically reclaim the active role.

Applying Policies and Updates

When you apply policies, you apply them to the device cluster instead of the individual devices or stacks. If the policy fails, the system does not apply it to either device or stack. The policy first applies to the active device or stack and then the backup, so that the cluster always has one peer handling network traffic.

Caution When you apply policies, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. On 7010, 7020, and 7030 managed devices, deploying configuration changes can take up to five minutes. See Configurations that Restart the Snort Process and How Snort Restarts Affect Traffic.

Clustered devices receive updates as a single entity rather than individual devices or stacks. When the update is started, the system first applies it to the backup device or stack, which goes into maintenance mode until any necessary processes restart and the device begins processing traffic again. The system then applies the update to the active device or stack, which follows the same process.

Achieving Redundancy Without Clustering Devices

In most cases, you can achieve Layer 3 redundancy without clustering devices by using the Cisco Redundancy Protocol (SFRP). SFRP allows devices to act as redundant gateways for specified IP addresses. With network redundancy, you configure two devices or stacks to provide identical network connections, ensuring connectivity for other hosts on the network. For more information about SFRP, see Configuring SFRP.

You determine how to configure device high availability depending on your FireSIGHT System deployment: passive, inline, routed, or switched. You can also deploy your system in multiple roles at once. Of the four deployment types, only passive deployments require that you cluster devices or stacks to provide redundancy. You can establish network redundancy for the other deployment types with or without device clusters. The following sections provide a brief overview of high availability in each deployment type.

Passive Deployment Redundancy

Passive interfaces are generally connected to tap ports on central switches, which allows them to analyze all of the traffic flowing across the switch. If multiple devices are connected to the same tap feed, the system generates events from each of the devices. When clustered, devices act as either active or backup, which allows the system to analyze traffic even in the event of a system failure while also preventing duplicate events.

Inline Deployment Redundancy

Because an inline set has no control over the routing of the packets being passed through it, it must always be active in a deployment. Therefore, redundancy relies on external systems to route traffic correctly. You can configure redundant inline sets with or without device clusters.

To deploy redundant inline sets, you configure the network topology so that it allows traffic to pass through only one of the inline sets while preventing circular routing. If one of the inline sets fails, the surrounding network infrastructure detects the loss of connectivity to the gateway address and adjusts the routes to send traffic through the redundant set.

Routed Deployment Redundancy

Hosts in an IP network must use a well-known gateway address to send traffic to different networks. Establishing redundancy in a routed deployment requires that routed interfaces share the gateway addresses so that only one interface handles traffic for that address at any given time. To accomplish this, you must maintain an equal number of IP addresses on a virtual router. One interface advertises the address. If that interface goes down, the backup interface begins advertising the address.

In non-clustered devices, you use SFRP to establish redundancy by configuring gateway IP addresses shared between multiple routed interfaces. You can configure SFRP with or without device clusters. You can also establish redundancy using dynamic routing such as OSPF or RIP.

Switched Deployment Redundancy

You establish redundancy in a switched deployment using the Spanning Tree Protocol (STP). STP is a protocol that manages the topology of bridged networks. It is specifically designed to allow redundant links to provide automatic backup for switched interfaces without configuring backup links. Devices in a switched deployment rely on STP to manage traffic between redundant interfaces. Two devices connected to the same broadcast network receive traffic based on the topology calculated by STP. See Configuring Advanced Virtual Switch Settings for more information about enabling STP.

Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy in a device cluster.

See the following sections for more information about clustering devices and stacks:

- Establishing Device Clusters

- Editing Device Clusters

- Configuring Individual Devices in a Cluster

- Configuring Individual Device Stacks in a Cluster

- Configuring Interfaces on a Clustered Device

- Switching the Active Peer in a Cluster

- Placing a Clustered Device into Maintenance Mode

- Replacing a Device in a Clustered Stack

- Establishing Clustered State Sharing

- Troubleshooting Clustered State Sharing

- Separating Clustered Devices

- Configuring SFRP

- Configuring HA Link Interfaces

Establishing Device Clusters

License: Control

Supported Devices: Series 3

Before you establish a device cluster, you must meet the following prerequisites:

- Configure interfaces on each device or each primary device in a stack.

- Each device or device stack primary member that you include in the cluster must be the same model and have identical copper or fiber interfaces.

- Both devices or device stacks must have normal health status, run the same software, and have the same licenses. See Using the Health Monitor for more information. In particular, the devices cannot have hardware failures that would cause them to enter maintenance mode and trigger a failover.

- You cannot mismatch devices and stacks in a cluster. You must cluster single devices with single devices or device stacks with device stacks that have identical hardware configurations, except for the presence of a malware storage pack. For example, you can cluster a 3D8290 with a 3D8290; none, one, or all devices in either stack might have an installed malware storage pack. For more information on the malware storage pack, see the FireSIGHT System Malware Storage Pack Guide .

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware storage pack. See the FireSIGHT System Malware Storage Pack Guide for more information.

- If the devices are targeted by NAT policies, both peers must have the same NAT policy.

When establishing a device cluster, you designate one of the devices or stacks as active and the other as backup. The system applies a merged configuration to the clustered devices. If there is a conflict, the system applies the configuration from the device or stack you designated as active.

After you cluster the devices, you cannot change the license options for individual clustered devices, but you can change the license for the entire cluster. See Editing Device Clusters for more information. If there are interface attributes that need to be set on switched interfaces or routed interfaces, the system establishes the cluster, but sets it to a pending status. After you configure the necessary attributes, the system completes the device cluster and sets it to a normal status.

) in the appliance list. Any configuration changes you make are synchronized between the clustered devices. The Device Management page displays which device or stack in the cluster is active, which changes after manual or automatic failover. See Placing a Clustered Device into Maintenance Mode for more information about manual failover.

Removing registration of a device cluster from a Defense Center removes registration from both devices or stacks. You remove a device cluster from the Defense Center as you would an individual managed device. See Deleting Devices for more information.

You can then register the cluster on another Defense Center. To register clustered single devices, you add remote management to the active device in the cluster and then add that device to the Defense Center, which adds the entire cluster. To register clustered stacked devices, you add remote management to the primary device of the either stack and then add that device to the Defense Center, which adds the entire cluster. See Adding Devices to the Defense Center for more information.

After you establish a device cluster, you can configure a high availability link interface, as explained in Configuring HA Link Interfaces.

To cluster devices or device stacks:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

Step 2 From the Add drop-down menu, select Add Cluster.

The Add Cluster pop-up window appears.

Step 3 In the Name field, type the name of the cluster.

You may enter alphanumeric characters and special characters, with the exception of the following characters, which are invalid: +, (, ), {, }, #, &, \, <, >, ?, ‘, and “.

Step 4 Select the Active device or stack for the cluster.

Step 5 Select the Backup device or stack for the cluster.

Step 6 Click Cluster.

The device cluster is added. This process takes a few minutes as the process synchronizes system data.

Editing Device Clusters

License: Control

Supported Devices: Series 3

After you establish a device cluster, most changes you make to the device configuration also change the configuration of the entire cluster.

You can view the status of the cluster by hovering your pointer over the status icon in the General section. You can also view which device or stack is the active peer and backup peer in the cluster.

See the following sections for more information:

- Editing General Device Settings

- Enabling and Disabling Device Licenses

- Establishing Clustered State Sharing

- Editing Advanced Device Settings

To edit a device cluster:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page appears.

Step 3 Use the sections on the Cluster page to make changes to the clustered configuration as you would a single device configuration.

Configuring Individual Devices in a Cluster

License: Control

Supported Devices: Series 3

After you establish a device cluster, you can still configure some attributes for each device within the cluster. You can make changes to a clustered device just as you would to a single device.

See the following sections for more information:

- Editing General Device Settings

- Editing Device System Settings

- Viewing the Health of a Device

- Editing Device Management Settings

To configure an individual device in a cluster:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page appears.

Step 3 Click Devices.

The Devices page appears.

Step 4 From the Selected Device drop-down list, select the device you want to modify.

Step 5 Use the sections on the Devices page to make changes to the individual clustered device as you would a single device.

Configuring Individual Device Stacks in a Cluster

License: Control

Supported Devices: Series 3

After you cluster a pair of stacked devices, the system limits the stack attributes that you can edit. You can edit the name of a stack in a clustered stack. In addition, you can edit the network configuration of the stack, as described in Configuring Interfaces on a Clustered Device.

To edit the name of a stack in a cluster:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page appears.

Step 3 Click Stacks.

The Stacks page appears.

From the Selected Device drop-down list, select the stack you want to modify.

).

You may enter alphanumeric characters and special characters, with the exception of the following characters, which are invalid: +, (, ), {, }, #, &, \, <, >, ?, ‘, and “.

Step 6 Click Save.

The new name is saved. Note that your changes do not take effect until you apply the stack configuration; see Applying Changes to Devices for more information.

Configuring Interfaces on a Clustered Device

License: Control

Supported Devices: Series 3

You can configure interfaces on individual devices in a cluster. However, you must also configure an equivalent interface on the peer device in the cluster. For clustered stacks, you configure identical interfaces on the primary devices of the stacks. When you configure virtual routers, you select the stack where you want to configure the routers. See Configuring Virtual Routers for more information.

The Interfaces page of a clustered device includes the hardware and interfaces views that you find on an individual device. See Configuring Sensing Interfaces for more information.

To configure interfaces on a clustered device:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page appears.

Step 3 Click Interfaces.

The Interfaces page appears.

Step 4 From the Selected Device drop-down list, select the device you want to modify.

Step 5 Configure interfaces as you would on an individual device. See Configuring Sensing Interfaces for more information.

Switching the Active Peer in a Cluster

License: Control

Supported Devices: Series 3

After you establish a device cluster, you can manually switch the active and backup peer devices or stacks.

To switch the active peer in a cluster:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Switch Active Peer pop-up window appears.

Step 3 Click Yes to immediately make the backup device the active device in the cluster. Click No to cancel and return to the Device Management page.

Placing a Clustered Device into Maintenance Mode

License: Control

Supported Devices: Series 3

After you establish a cluster, you can manually trigger failover by placing one of the clustered devices or stacks into maintenance mode to perform maintenance on the devices. In maintenance mode, the system administratively takes down all interfaces except for the management interface. After maintenance is completed, you can re-enable the device to resume normal operation.

Note You should not place both members of a cluster into maintenance mode at the same time. Doing so will prevent that cluster from inspecting traffic.

To place a clustered device into maintenance mode:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Confirm Maintenance Mode pop-up window appears.

Step 3 Click Yes to confirm maintenance mode or click No to cancel.

) again to bring the device out of maintenance mode.

Replacing a Device in a Clustered Stack

License: Control

Supported Devices: Series 3

After you place a stack that is a cluster member into maintenance mode, you can replace a secondary device in the stack for another device. You can only select devices that are not currently stacked or clustered. The new device must follow the same guidelines for establishing a device stack. See Establishing Device Stacks.

To replace a device in a clustered stack:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Confirm Maintenance Mode pop-up window appears.

Step 3 Click Yes to confirm maintenance mode or click No to cancel.

).

The Replace Device pop-up window appears.

Step 5 Select the Replacement Device from the drop-down list.

Step 6 Click Replace to replace the device or click Cancel to keep the current device and return to the Device Management page.

) again to bring the stack immediately out of maintenance mode.

You do not need to reapply the device configuration.

Establishing Clustered State Sharing

License: Control

Supported Devices: Series 3

Clustered state sharing allows clustered devices or clustered stacks to synchronize as much state as necessary, so that if either device or stack fails, the other peer can take over with no interruption to traffic flow. Without state sharing, the following features may not fail over properly:

- Strict TCP enforcement

- Unidirectional access control rules

- Blocking persistence

Note, however, that enabling state sharing slows system performance.

You must configure and enable HA link interfaces on both devices or the primary stacked devices in the cluster before you can configure clustered state sharing. 82xx Family and 83xx Family devices require a 10G HA link, while other model devices require a 1G HA link. See Configuring HA Link Interfaces for more information.

Note If clustered devices fail over, the system terminates all existing SSL-encrypted sessions on the active device. Even if you establish clustered state sharing, these sessions must be renegotiated on the backup device. If the server establishing the SSL session supports session reuse and the backup device does not have the SSL session ID, it cannot renegotiate the session. For more information, see Clustering Devices.

Strict TCP Enforcement

When you enable strict TCP enforcement for a domain, the system drops any packets that are out of order on TCP sessions. For example, the system drops non-SYN packets received on an unestablished connection. With state sharing, devices in the cluster allow TCP sessions to continue after failover without having to reestablish the connection, even if strict TCP enforcement is enabled. You can enable strict TCP enforcement on inline sets, virtual routers, and virtual switches.

Unidirectional Access Control Rules

If you have configured unidirectional access control rules, network traffic may match a different access control rule than intended when the system reevaluates a connection midstream after failover. For example, consider if you have a policy containing the following two access control rules:

Rule 1: Allow from 192.168.1.0/24 to 192.168.2.0/24

Rule 2: Block all

Without state sharing, if an allowed connection from 192.168.1.1 to 192.168.2.1 is still active following a failover and the next packet is seen as a response packet, the system denies the connection. With state sharing, a midstream pickup would match the existing connection and continue to be allowed.

Blocking Persistence

While many connections are blocked on the first packet based on access control rules or other factors, there are cases where the system allows some number of packets through before determining that the connection should be blocked. With state sharing, the system immediately blocks the connection on the peer device or stack as well.

When establishing clustered state sharing, you can configure the following options:

Enabled

Click the check box to enable state sharing. Clear the check box to disable state sharing.

Minimum Flow Lifetime

Specify the minimum time (in milliseconds) for a session before the system sends any synchronization messages for it. You can use any integer from 0 to 65535. The system does not synchronize any sessions that have not met the minimum flow lifetime, and the system synchronizes only when a packet is received for the connection.

Minimum Sync. Interval

Specify the minimum time (in milliseconds) between update messages for a session. You can use any integer from 0 to 65535. The minimum synchronization interval prevents synchronization messages for a given connection from being sent more frequently than the configured value after the connection reaches the minimum lifetime.

Maximum HTTP URL Length

Specify the maximum characters for the URL the system synchronizes between the clustered devices. You may use any integer from 0 to 225.

Note Cisco recommends that you use the default values, unless your deployment presents a good reason to change them. Decreasing the values allows increased clustered peer readiness, while increasing the values allows better performance.

To establish clustered state sharing:

Access: Admin/Network Admin

Step 1 Configure HA link interfaces for each device in the cluster.

See Configuring HA Link Interfaces for more information.

Step 2 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page appears.

).

The State Sharing pop-up window appears.

Step 5 Configure the state sharing, as described earlier in this section.

Step 6 Click OK.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Troubleshooting Clustered State Sharing

License: Control

Supported Devices: Series 3

After you enable state sharing, you can view the following information about the configuration in the State Sharing section of the Cluster page:

- The HA link interface that is being used and its current link state

- Detailed synchronization statistics for troubleshooting issues

The state sharing statistics are primarily counters for different aspects of the clustered synchronization traffic sent and received, along with some other error counters. In addition, you can view the latest system logs for each device in the cluster.

See the following sections for more information about the statistics you can view for each device and how you can use them to troubleshoot your clustered state sharing configuration.

Messages Received (Unicast)

Messages received are the number of cluster synchronization messages received from the clustered peer.

The value should be close to the number of messages sent by the peer. During active use, the values may not match, but should be close. If traffic stops, the values should become stable and the messages received will match the messages sent.

For troubleshooting, you should view both the messages received and the messages sent, compare the rate of increase, and make sure the values are close. The sent value on each peer should be incrementing at approximately the same rate as the received value on the opposite peer.

Contact Support if the received messages stop incrementing or increment slower than the messages sent by the peer.

Packets Received

The system batches multiple messages into single packets in order to decrease overhead. The Packets Received counter displays the total number of these data packets, as well as other control packets that have been received by a device.

The value should be close to the number of packets sent by the peer device. During active use, the values may not match, but should be close. Because the number of messages received should be close and incrementing at the same rate as the number of messages sent by the peer, the number of packets received should have the same behavior.

For troubleshooting, you should view both the packets received and the messages sent, compare the rate of increase, and make sure the values are increasing at the same rate. If the sent value on the clustered peer is incrementing, the received value on the device should also increase at the same rate.

Contact Support if the received packets stop incrementing or increment slower than the messages sent by the peer.

Total Bytes Received

Total bytes received are the number of bytes that make up the packets received by the peer.

The value should be close to the number of bytes sent by the other peer. During active use, the values may not match, but should be close.

For troubleshooting, you should view both the total bytes received and the messages sent, compare the rate of increase, and make sure the values are increasing at the same rate. If the sent value on the clustered peer is incrementing, the received value on the device should also increase at the same rate.

Contact Support if the received bytes stop incrementing or increment slower than the messages sent by the peer.

Protocol Bytes Received

Protocol bytes received are the number of bytes of protocol overhead received, which includes everything but the payload of session state synchronization messages.

The value should be close to the number of bytes sent by the peer. During active use, the values may not match, but should be close.

For troubleshooting, you should view the total bytes received to discover how much actual state data is being shared in comparison to protocol data. If the protocol data is a large percentage of the data being sent, you can adjust the minimum sync interval.

Contact Support if the protocol bytes received increment at a similar rate to the total bytes received. Protocol bytes received should be minimal in relation to the total bytes received.

Messages Sent

Messages sent are the number of cluster synchronization messages sent to the clustered peer.

This data is useful in comparison to the number of messages received. During active use, the values may not match, but should be close.

For troubleshooting, you should view both the messages received and the messages sent, compare the rate of increase, and make sure the values are close.

Contact Support if the messages sent increment at a similar rate to the total bytes received.

Bytes Sent

Bytes sent are the total number of bytes sent that make up the cluster synchronization messages sent to the peer.

This data are useful in comparison to the number of messages received. During active use, the values may not match, but should be close. The number of bytes received on the peer should be close to, but not more than this value.

Contact Support if the total bytes received is not incrementing at about the same rate as the bytes sent.

Tx Errors

Tx errors are the number of memory allocation failures the system encounters when trying to allocate space for messages to be sent to the clustered peer.

This value should be zero at all times on both peers. Contact Support if this number is not zero or if the number steadily increases, which indicates the system has encountered an error where it cannot allocate memory.

Tx Overruns

Tx overruns are the number of times the system attempts and fails to place a message into the transit queue.

This value should be zero at all times on both peers. When the value is not zero or is steadily increasing, it indicates that the system is sharing too much data across the HA link that cannot be sent quickly enough.

You should increase the HA link MTU if it was previously set below the default value (9918 or 9922). You can change the minimum flow lifetime and minimum synchronization interval settings to reduce the amount of data shared across the HA link to prevent the number from incrementing.

Contact Support if this value persists or continues to increase.

Recent Logs

The system log displays the most recent clustered synchronization messages. The log should not display any ERROR or WARN messages. It should remain comparable between the peers, such as the same number of sockets being connected.

However, the data displayed may be opposite in some instances, for example, one peer reports that it received a connection from the other peer and references different IP addresses. The log provides a comprehensive view of the clustered state sharing connection, and any errors within the connection.

Contact Support if the log displays an ERROR or WARN message, or any message that does not appear to be purely informational.

To view clustered state sharing statistics:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Cluster page for the device cluster appears.

).

The State Sharing Statistics pop-up window appears.

Step 4 Optionally, select a Device to view if your cluster is composed of device stacks.

Step 5 Optionally, click Refresh to update the statistics.

Step 6 Optionally, click View to view the latest data log for each clustered device.

Separating Clustered Devices

License: Control

Supported Devices: Series 3

When you break device clustering, the active device or stack retains full deployment functionality. The backup device or stack loses its interface configurations and fails over to the active device or stack, unless you choose to leave the interface configurations active, in which case the backup device or stack resumes normal operation. Breaking a cluster always removes the configuration of passive interfaces on the backup devices. Any devices in maintenance mode resume normal operation upon breaking the cluster.

To separate a clustered device:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Confirm Break pop-up window appears.

Step 3 Optionally, select the check box to remove the interface configurations on the backup device or stack, which means all interfaces except for the management interface are administratively taken down.

Step 4 Click Yes.

The device cluster is separated.

Managing Stacked Devices

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, ASM3D9900

You can increase the amount of traffic inspected on a network segment by using devices in a stacked configuration. For each stacked configuration, all devices in the stack must have the same hardware. However, if the stack does not contain a 3D9900, none, some, or all devices might have an installed malware storage pack. The devices must also be from the same device family based on the following stacked configurations:

For Series 2 and the 81xx Family:

- two 3D8140s

- two 3D9900s

For the 82xx Family:

- up to four 3D8250s

- a 3D8260 (a primary device and a secondary device)

- a 3D8270 (a primary device with 40G capacity and two secondary devices)

- a 3D8290 (a primary device with 40G capacity and three secondary devices)

For the 83xx Family:

- up to four 3D8350s

- a 3D8360 (a primary device with 40G capacity and a secondary device)

- a 3D8370 (a primary device with 40G capacity and two secondary devices)

- a 3D8390 (a primary device with 40G capacity and three secondary devices)

- up to four AMP8350s

- an AMP8360 (a primary device with 40G capacity and a secondary device)

- an AMP8370 (a primary device with 40G capacity and two secondary devices)

- an AMP8390 (a primary device with 40G capacity and three secondary devices)

For more information about stacked configurations, see the FireSIGHT System Installation Guide. For more information about the malware storage pack, see the FireSIGHT System Malware Storage Pack Guide.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware storage pack. See the FireSIGHT System Malware Storage Pack Guide for more information.

When you establish a stacked configuration, you combine the resources of each stacked device into a single, shared configuration.

You designate one device as the primary device, where you configure the interfaces for the entire stack. You designate the other devices as secondary. Secondary devices must not be currently sensing any traffic and must not have link on any interface.

Connect the primary device to the network segment you want to analyze in the same way you would configure a single device. See Configuring Sensing Interfaces for more information. Connect the secondary devices to the primary device using the stacked device cabling instructions found in the FireSIGHT System Installation Guide.

All devices in the stacked configuration must have the same hardware, run the same software version, and have the same licenses. If the devices are targeted by NAT policies, both the primary and secondary device must have the same NAT policy. See Managing NAT Policies for more information. You must apply updates to the entire stack from the Defense Center. If an update fails on one or more devices in the stack, the stack enters a mixed-version state. You cannot apply policies to or update a stack in a mixed-version state. To correct this state, you can break the stack or remove individual devices with different versions, update the individual devices, then reestablish the stacked configuration. After you stack the devices, you can change the licenses only for the entire stack at once.

After you establish the stacked configuration, the devices act like a single, shared configuration. If the primary device fails, no traffic is passed to the secondary devices. Health alerts are generated indicating that the stacking heartbeat has failed on the secondary devices. See Using Health Monitoring for more information.

If the secondary device in a stack fails, inline sets with configurable bypass enabled go into bypass mode on the primary device. For all other configurations, the system continues to load balance traffic to the failed secondary device. In either case, a health alert is generated to indicate loss of link.

You can use a device stack as you would a single device in your deployment, with a few exceptions. If you have clustered devices, you cannot stack a device cluster or a device in a clustered pair. See Clustering Devices for more information. You also cannot configure NAT on a device stack.

Note If you use eStreamer to stream event data from stacked devices to an external client application, collect the data from each device and ensure that you configure each device identically. The eStreamer settings are not automatically synchronized between stacked devices.

See the following sections for more information:

- Establishing Device Stacks

- Editing Device Stacks

- Configuring Individual Devices in a Stack

- Separating Stacked Devices

- Replacing a Device in a Stack

Establishing Device Stacks

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

You can increase the amount of traffic inspected on a network segment by stacking two fiber-based 3D9900s, two 3D8140 devices, up to four 3D8250s, a 3D8260, a 3D8270, a 3D8290, up to four 3D8350s, a 3D8360, a 3D8370, or a 3D8390, up to four AMP8350s, an AMP8360, and AMP8370, or an AMP8390 and using their combined resources in a single, shared, configuration. Before you begin, you must:

- decide which unit will be the primary device

- cable the units properly before designating the primary/secondary relationship. For information about cabling, see the FireSIGHT System Installation Guide .

Note If you have clustered devices, you cannot stack a device cluster or a device in a clustered pair. However, you can cluster a device stack. See Clustering Devices for more information.

) in the appliance list.

Removing registration of a device stack from a Defense Center also removes registration from both devices. You delete stacked devices from the Defense Center as you would a single managed device; you can then register the stack on another Defense Center. You only need to register one of the stacked devices on the new Defense Center for the entire stack to appear. See Deleting Devices and Adding Devices to the Defense Center for more information.

After you establish the device stack, you cannot change which devices are primary or secondary unless you break and reestablish the stack. However, you can:

- add secondary devices to an existing stack of two or three 3D8250s, a 3D8260, or a 3D8270 up to the limit of four 3D8250s in a stack

- add secondary devices to an existing stack of two or three 3D8350s, a 3D8360, or a 3D8370 up to the limit of four 3D8350s in a stack

- add secondary devices to an existing stack of two or three AMP8350s, an AMP8360, or an AMP8370 up to the limit of four AMP8350s in a stack

For additional devices, the primary device in the stack must have the necessary stacking NetMods for additional cabled devices. For example, if you have a 3D8260 where the primary only has a single stacking NetMod, you cannot add another secondary device to this stack. You add secondary devices to an existing stack in the same manner that you initially establish a stacked device configuration.

To establish a stacked device configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

Step 2 From the Add drop-down menu, select Add Stack.

The Add Stack pop-up window appears.

Step 3 From the Primary drop-down list, select the device that you cabled for primary operation.

Note If you edit a device that is not cabled as the primary device, you cannot perform the next series of steps.

Step 4 In the Name field, type the name of the stack. You may enter alphanumeric characters and special characters, with the exception of the following characters, which are invalid: +, (, ), {, }, #, &, \, <, >, ?, ‘, and “.

Step 5 Click Add to select the devices you want to form a stack with.

The Add Secondary Connection pop-up window appears. The following graphic displays the primary device front view for a 3D8140.

Step 6 From the Slot on Primary Device drop-down list, select the stacking network module that connects the primary device to the secondary device.

Step 7 From the Secondary Device drop-down list, select the device you cabled for secondary operation.

Note All devices in a stack must be of the same hardware model (for example, 3D9900 with 3D9900, 3D8140 with 3D8140, and so on). You can stack a total of four devices (one primary device and up to three secondary devices) in the 82xx Family and in the 83xx Family.

Step 8 From the Slot on Secondary Device drop-down list, select the stacking network module that connects the secondary device to the primary device.

Step 9 Click Add.

The Add Stack window reappears with the new secondary device included.

Step 10 Optionally, repeat steps 5 through 9 if you are adding secondary devices to an existing stack of 3D8250s, a 3D8260, a 3D8270, an existing stack of 3D8350s, a 3D8360, or a 3D8370, or an existing stack of AMP8350s, an AMP8360, or an AMP8370.

Step 11 Click Stack.

The device stack is established or the additional secondary devices are added. Note that this process takes a few minutes as the process synchronizes system data.

Editing Device Stacks

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

After you establish a device stack, most changes you make to the device configuration also change the configuration of the entire stack. On the Stack page of the appliance editor, you can make changes to the stack configuration as on the Device page of a single device.

You can change the display name of the stack, enable and disable licenses, view system and health policies, configure automatic application bypass, and set up fast-path rules.

See the following sections for more information:

- Editing General Device Settings

- Enabling and Disabling Device Licenses

- Editing Advanced Device Settings

To edit a stacked configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Stack page for that device appears.

Step 3 Use the sections on the Stack page to make changes to the stacked configuration as you would a single device configuration.

Configuring Individual Devices in a Stack

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

After you establish a device stack, you can still configure some attributes for only one device within the stack. On the Devices page of the appliance editor, you can make changes to a device configured in a stack as on the Device page of a single device.

You can change the display name of a device, view system settings, shut down or restart a device, view health information, and edit device management settings.

See the following sections for more information:

- Editing General Device Settings

- Editing Device System Settings

- Viewing the Health of a Device

- Editing Device Management Settings

To configure an individual device in a stack:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Stack page for that device appears.

Step 3 Click Devices.

The Devices page appears.

Step 4 From the Selected Device drop-down list, select the device you want to modify.

Step 5 Use the sections on the Devices page to make changes to the individual stacked device as you would a single device.

Configuring Interfaces on a Stacked Device

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

Except for the management interface, you configure stacked device interfaces on the Interfaces page of the primary device in the stack. You can select any device in the stack to configure the management interface. See Configuring Management Interfaces for more information.

The Interfaces page of a Series 3 stacked device includes the hardware and interfaces views that you find on an individual device. The interfaces page of a 3D9900 does not include these views. See Configuring Sensing Interfaces for more information.

To configure interfaces on a stacked device:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Stack page for that device appears.

Step 3 Click Interfaces.

The Interfaces page appears.

Step 4 From the Selected Device drop-down list, select the device you want to modify.

Step 5 Configure interfaces as you would on an individual device. See Configuring Sensing Interfaces for more information.

Separating Stacked Devices

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

If you no longer need to use a stacked configuration for your devices, you can break the stack and separate the devices.

To separate stacked devices:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Confirm Break pop-up window appears.

Step 3 Click Yes.

The device stack is separated.

Replacing a Device in a Stack

License: Any

Supported Devices: 3D8140, 3D8200 family, 3D8300 family, AMP8300 family, 3D9900

To replace a stacked device, you must break the stack.

Warning If the Defense Center cannot communicate with the device, you must connect to the device and use CLI commands to separate the stack and unregister the device from the Defense Center. For more information, see stacking disable and delete CLI commands in Configuration Commands.

To replace a device in a device stack:

Step 1 Select the stack with the device to replace and break that stack. For more information, see Separating Stacked Devices.

Step 2 Unregister the device from the Defense Center. For more information, see Disabling High Availability and Unregistering Devices.

Step 3 Register the replacement device to the Defense Center. For more information, see Adding Devices to the Defense Center.

Step 4 Create a device stack that includes the replacement device. For more information, see Establishing Device Stacks.

Editing Device Configuration

License: Any

The Device page of the appliance editor displays detailed device configuration and information. It also allows you to make changes to some parts of device configuration, such as enabling and disabling licenses, shutting down and restarting a device, modifying management, and setting up fast-path rules.

See the following sections for more information:

- Editing General Device Settings

- Enabling and Disabling Device Licenses

- Editing Device System Settings

- Viewing the Health of a Device

- Editing Device Management Settings

- Understanding Advanced Device Settings

Editing General Device Settings

License: Any

The General section of the Device tab displays the managed device settings listed below, which you can change.

Name

The assigned name for the managed device.

Transfer Packets

Indicates whether packet data is transferred to the Defense Center to be stored with events.

To edit the general device settings:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces page for that device appears.

Step 3 Click Device.

The Device page appears.

Tip For stacked devices, you edit the assigned device name for the stack on the Stack page of the appliance editor. You can edit the assigned device name for an individual device on the Devices page of the appliance editor.

).

The General pop-up window appears.

Step 5 In the Name field, type a new assigned name for the device. You may enter alphanumeric characters and special characters, with the exception of the following characters, which are invalid: +, (, ), {, }, #, &, \, <, >, ?, ‘, and “.

Step 6 Select the Transfer Packets check box to allow packet data to be stored with events on the Defense Center. Clear the check box to prevent the managed device from sending packet data with the events.

Step 7 Click Save.

The changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Enabling and Disabling Device Licenses

License: Any

Supported Devices: Series 3, Virtual, X-Series, ASA FirePOWER

You can enable licenses on your device if you have available licenses on your Defense Center. Note that:

- Control, Malware, and URL Filtering licenses require a Protection license.

- You cannot enable a VPN license on a virtual device, Cisco NGIPS for Blue Coat X-Series, or ASA FirePOWER devices.

- Although you can enable a Control license on a virtual device, Cisco NGIPS for Blue Coat X-Series, or ASA FirePOWER device, these devices do not support fast-path rules, switching, routing, stacking, or clustering. Cisco NGIPS for Blue Coat X-Series also does not support application or user control.

- You cannot change the license settings on clustered devices.

- Because Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence filtering, you cannot disable these capabilities, nor can you apply other licenses to a Series 2 device.

For more information, see Licensing the FireSIGHT System.

To enable or disable device licenses:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

Tip For stacked devices, you enable or disable the licenses for the stack on the Stack page of the appliance editor.

).

The License pop-up window appears.

Step 5 You have the following options:

- To enable a license, select the check box next to the license name.

- To disable a license, clear the check box next to the license name.

Step 6 Click Save.

The changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Editing Device System Settings

License: Any

The System section of the Device tab displays a read-only table of system information, as described in the following table.

Table 4-2 System Section Table Fields

Field

Description

Model

The model name and number for the managed device.

Serial

The serial number of the chassis of the managed device.

Time

The current system time of the device.

Version

The version of the software currently installed on the managed device.

Policy

A link to the system policy currently applied to the managed device.

You can also shut down or restart the device.

Note You cannot shut down or restart X-Series or ASA FirePOWER devices with the FireSIGHT System user interface. See the Cisco NGIPS for Blue Coat X-Series Installation Guide or the ASA documentation for more information on how to shut down the respective devices.

To shut down and restart a managed device:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

Tip For stacked devices, you shut down or restart an individual device on the Devices page of the appliance editor.

).

Step 5 When prompted, confirm that you want to shut down the device.

You are returned to the Device Management page.

).

Step 7 When prompted, confirm that you want to restart the device.

The device is restarted.

Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Viewing the Health of a Device

License: Any

The Health section of the Device tab displays health-related information. You can view an icon showing the current health status of the managed device. You can also click the icon to navigate to the Health Monitor page for that device. See Interpreting Health Monitor Status for more information.

You can click the Policy link to view a read-only version of the currently applied health policy. See Editing Health Policies for more information.

You can also click the Blacklist link to go to the Health Blacklist page, where you can enable and disable health blacklist modules. See Blacklisting a Health Policy Module for more information.

Editing Device Management Settings

License: Any

The Management section of the Device tab displays the remote management information listed below.

Host

The current management host name or IP address of the device. You can use this setting to specify the management host name and regenerate the virtual IP address.

Note In some cases, if you edit the host name or IP address of a device by another method (using the device’s LCD panel or CLI, for example), you may need to use the procedure below to manually update the host name or IP address on the managing Defense Center.

Status

Specifies the status of the communication channel between the Defense Center and the managed device.

Tip You can click the slider to enable or disable management of the managed device. Disabling management blocks the connection between the Defense Center and the device, but does not delete the device from the Defense Center. If you no longer want to manage a device, see Deleting Devices.

To modify device management options:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

Tip For stacked devices, you modify management options on an individual device on the Devices page of the appliance editor.

).

The Management pop-up window appears.

Step 5 In the Host field, enter the name or IP address of the management host.

Step 6 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Understanding Advanced Device Settings

License: Any

Supported Devices: feature dependent

Table 4-3 Advanced Section Table Fields

Field

Description

Supported Devices

Application Bypass

The state of Automatic Application Bypass on the device.

Series 2, Series 3, Virtual

Bypass Threshold

The Automatic Application Bypass threshold, in milliseconds.

Series 2, Series 3, Virtual

Inspect Local Router Traffic

Whether the device inspects traffic received on routed interfaces that is destined for itself, such as ICMP, DHCP, and OSPF traffic.

Series 3

Fast-Path Rules

The number of fast-path rules that have been created on the device.

8000 Series, 3D9900

You can use the Advanced section to edit any of these settings. See the following sections for more information:

- Automatic Application Bypass

- Editing Advanced Device Settings

- Configuring Fast-Path Rules

Automatic Application Bypass

License: Any

The Automatic Application Bypass (AAB) feature limits the time allowed to process packets through an interface and allows packets to bypass detection if the time is exceeded. The feature functions with any deployment; however, it is most valuable in inline deployments.

You balance packet processing delays with your network’s tolerance for packet latency. When a malfunction within Snort or a device misconfiguration causes traffic processing time to exceed a specified threshold, AAB causes Snort to restart within ten minutes of the failure, and generates troubleshoot data that can be analyzed to investigate the cause of the excessive processing time.

In Version 5.4.1 and higher, the default behavior for the AAB option varies by device, as follows:

- Series 3: off

- Series 2 and virtual: on

- ASA FirePOWER: not supported

- X-Series: not supported

If you upgrade from a version earlier than 5.3, the existing setting is retained. You can change the bypass threshold if the option is selected. The default setting is 3000 milliseconds (ms). The valid range is from 250 ms to 60,000 ms.

Typically, you use Rule Latency Thresholding in the intrusion policy to fast-path packets after the latency threshold value is exceeded. Rule Latency Thresholding does not shut down the engine or generate troubleshoot data. For more information, see Configuring Packet and Intrusion Rule Latency Thresholds.

Note AAB is activated only when an excessive amount of time is spent processing a single packet. If AAB engages the Snort process restarts. which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

If detection is bypassed, the device generates a health monitoring alert. For more information on that health monitoring alert, see Using the Health Monitor.

For more information about enabling Automatic Application Bypass and setting the bypass threshold, see Editing Advanced Device Settings.

Editing Advanced Device Settings

License: Any

Supported Devices: feature dependent

You can use the Advanced section of the Devices tab to modify the Automatic Application Bypass and Inspect Local Router Traffic settings. You can also configure fast-path rules, as explained in Configuring Fast-Path Rules.

Note the following:

- you can configure fast-path rules only on 8000 Series and 3D9900 devices.

- you can configure Inspect Local Router Traffic only on Series 3 devices

To modify advanced device settings:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

Tip For stacked devices, you edit the advanced device settings for the stack on the Stack page of the appliance editor.

).

The Advanced pop-up window appears.

Step 5 Optionally, select Automatic Application Bypass if your network is sensitive to latency. Automatic Application Bypass is most useful in inline deployments. For more information, see Automatic Application Bypass.

Step 6 When you select the Automatic Application Bypass option, you can type a Bypass Threshold in milliseconds (ms). The default setting is 3000 ms and the valid range is from 250 ms to 60,000 ms.

Step 7 Optionally, select the Inspect Local Router Traffic check box to inspect exception traffic when deployed as a router.

Step 8 Optionally, configure fast-path rules. For more information, see Configuring Fast-Path Rules.

Step 9 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Configuring Fast-Path Rules

License: Any

Supported Devices: 8000 Series, 3D9900

You can create fast-path rules to send traffic directly through a device with no further inspection. Fast-path rules divert traffic that does not need to be analyzed to bypass the device. Fast-path rules either send traffic to the fast-path (out of the interface) or allow it to continue into the device for further analysis. Their advantage is the speed at which they determine the correct path for the traffic. Because the fast-path rules function at the hardware level, they only determine limited information about the packet.

See the following sections for more information:

- Adding IPv4 Fast-Path Rules

- Adding IPv6 Fast-Path Rules

- Deleting Fast-Path Rules

Adding IPv4 Fast-Path Rules

License: Any

Supported Devices: 8000 Series, 3D9900

Fast-path rules send traffic to the fast-path (out of the interface) or into the device for further analysis. You can use the following criteria to select the IPv4 traffic you want to divert to the fast-path and not inspect:

- initiator or responder IP address or CIDR block

- protocol

- initiator or responder port, for TCP or UDP protocols

- VLAN ID

- bidirectional option

Note that the outermost ID is used for fast-path rules.

To build or edit IPv4 fast-path rules:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

).

The Advanced pop-up window appears.

Step 5 Click New IPv4 Rule to add a fast-path rule.

The New IPv4 Rule pop-up window appears.

Step 6 From the Domain drop-down list, select an inline set or passive security zone. See Setting Up an IPS Device for more information.

Step 7 Use CIDR notation in the Initiator and the Responder fields to designate the IP addresses of initiators or responders whose packets should bypass further analysis.

Your rule matches packets from the designated initiators or packets to the designated responders. For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 8 Optionally, from the Protocol drop-down list, select the protocol on which you want the rule to act or select All to match traffic from any protocol on the list.

Step 9 Optionally, if you chose the TCP or UDP protocol in step 8, enter initiator and responder ports in the Initiator Port and the Responder Port fields to designate ports.

Tip You can enter a comma-separated list of port numbers in each rule. You cannot use port ranges in IPv4 fast-path rules. Note that a blank port value is treated as Any.

If you also select the Bidirectional option, your filter criteria are narrowed to packets from those initiator ports or packets to those responder ports.

Step 10 Optionally, enter a VLAN ID in the VLAN field.

Your rule matches only traffic for that VLAN. Note that a blank VLAN value is treated as Any.

Step 11 Optionally, select the Bidirectional option to filter all traffic traveling between the specified initiator and responder IP addresses. Clear the option to filter only traffic from the specified initiator IP address to the specified responder IP address.

Step 12 Click Save.

The rule is added under Fast-Path Rules in the Advanced pop-up window. Although the rule is added, you must click Save again to save the rule. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Adding IPv6 Fast-Path Rules

License: Any

Supported Devices: Series 3, 3D9900

Fast-path rules send traffic to the fast-path (out of the interface) or into the device for further analysis. You can use the following criteria to select the IPv6 traffic you want to divert to the fast-path and not inspect:

- initiator or responder IP address or address block

- protocol

- initiator or responder port, for TCP or UDP protocols

- VLAN ID

- bidirectional option

Note that the outermost VLAN ID is used for fast-path rules.

To add an IPv6 fast-path rule:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

Step 4 Next to the Advanced section, click the edit icon.

The Advanced pop-up window appears.

Step 5 Click New IPv6 Rule to add a fast-path rule.

The New IPv6 Rule pop-up window appears. Note that the initiator and responder fields are fixed and indicate that the filter applies to IPv6 packets from any initiator or responder.

Step 6 From the Domain drop-down list, select an inline set or passive security zone. See Setting Up an IPS Device for more information.

Step 7 Type IP addresses or use IPv6 prefix length notation to specify address blocks in the Initiator and the Responder fields for the IP addresses of initiators or responders whose packets should bypass further analysis.

Your rule matches packets from the designated initiators or packets to the designated responders. For information on using IPv6 prefix length notation in the FireSIGHT System, see IP Address Conventions.

Step 8 Optionally, from the Protocol drop-down list, select the protocol on which you want the rule to act or select All to match traffic from any protocol on the list.

Your fast-path rule matches only the selected protocol’s packets.

Step 9 Optionally, if you chose the TCP or UDP protocol in step 7, enter initiator and responder ports in the Initiator Port and the Responder Port fields to designate ports.

Tip You can enter a comma-separated list of port numbers in each rule. You cannot use port ranges in IPv6 fast-path rules. Note that a blank port value is treated as Any.

Step 10 Optionally, enter a VLAN ID in the VLAN field.

Your rule matches only traffic for that VLAN. Note that a blank VLAN value is treated as Any.

Step 11 Optionally, select Bidirectional to filter all traffic traveling between the specified initiator and responder ports. Clear the option to specify that your rule matches only packets from those initiator ports or packets to those responder ports.

Step 12 Click Save.

The rule is added under Fast-Path Rules in the Advanced pop-up window.

Step 13 In the Advanced pop-up window, click Save.

The rule is saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Deleting Fast-Path Rules

License: Any

Supported Devices: 8000 Series, 3D9900

The following procedure explains how to delete any IPv4 or IPv6 fast-path rule.

To delete any fast-path rule:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Devices tab appears.

).

The Advanced pop-up window appears.

).

Step 6 When prompted, confirm that you want to delete the rule.

The rule is removed from the Advanced pop-up window.

Step 7 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Configuring Sensing Interfaces

License: Any

You can configure the sensing interfaces of a managed device, according to your FireSIGHT System deployment, from the Interfaces page of the appliance editor.

Table 4-4 Using the Hardware View

To...

You can...

view a network module’s type, part number, and serial number

hover your cursor over the dark circle in the lower left corner of the network module.

select an interface in the interfaces table view

click the interface.

open an interface editor

double-click the interface.

view the name of the interface, the type of interface, whether the interface has link, the interface’s speed setting, and whether the interface is currently in bypass mode

hover your cursor over the interface.

view the details about an error or warning

hover your cursor over the affected port on the network module.

The interfaces table view, which is below the Series 3 hardware view, lists all the available interfaces you have on a device. The table includes an expandable navigation tree you can use to view all configured interfaces. You can click the arrow icon next to an interface to collapse or expand the interface to hide or view its subcomponents. The interfaces table view also provides summarized information about each interface, as described in the following table. Note that only 8000 Series devices display the MAC Address and IP Address columns. See the following table for more information.

Table 4-5 Interfaces Table View Fields

Field

Description

Name

Each interface type is represented by a unique icon that indicates its type and link state (if applicable). You can hover your pointer over the name or the icon to view the interface type, speed, and duplex mode (if applicable) in a tooltip. The interface icons are described in Table 4-6.

The icons use a badging convention to indicate the current link state of the interface, which may be one of three states:

- error (

)

- fault (

)

- not available (

)

Logical interfaces have the same link state as their parent physical interface. Cisco NGIPS for Blue Coat X-Series and ASA FirePOWER devices do not display link state. Note that disabled interfaces are represented by semi-transparent icons.

Interface names, which appear to the right of the icons, are auto-generated with the exception of hybrid and ASA FirePOWER interfaces, which are user-defined. Note that for ASA FirePOWER interfaces, the system displays only interfaces that are enabled, named, and have link.

Physical interfaces display the name of the physical interface. Logical interfaces display the name of the physical interface and the assigned VLAN tag.

ASA FirePOWER interfaces display the name of the security context and the name of the interface if there are multiple security contexts. If there is only one security context, the system displays only the name of the interface.

Security Zone

).

Used by

The inline set, virtual switch, or virtual router where the interface is assigned. ASA FirePOWER devices do not display the Used by column.

MAC Address

The MAC address displayed for the interface when it is enabled for switched and routed features.

For virtual devices, the MAC address is displayed so that you can match the network adapters configured on your device to the interfaces that appear on the Interfaces page. Cisco NGIPS for Blue Coat X-Series and ASA FirePOWER devices do not display MAC addresses.

IP Addresses

Table 4-6 Interface Icon Types and Descriptions

Icon

Interface Type

For more information, see...

Physical — an unconfigured physical interface.

—

Passive — a sensing interface configured to analyze traffic in a passive deployment.

Configuring Passive Interfaces

Inline — a sensing interface configured to handle traffic in an inline deployment.

Configuring Inline Interfaces

Switched — an interface configured to switch traffic in a Layer 2 deployment.

Configuring Switched Interfaces

Routed — an interface configured to route traffic in a Layer 3 deployment.

Configuring Routed Interfaces

HA — an interface configured on each member of a clustered pair of devices to act as a redundant communications channel between the devices; also called a high availability link interface.

Configuring HA Link Interfaces

Aggregate — multiple physical interfaces configured as a single logical link.

Setting Up Aggregate Interfaces

Aggregate Switched — multiple physical interfaces configured as a single logical link in a Layer 2 deployment.

Adding Aggregate Switched Interfaces

Aggregate Routed — multiple physical interfaces configured as a single logical link in a Layer 3 deployment.

Adding Aggregate Routed Interfaces

Hybrid — a logical interface configured to bridge traffic between a virtual router and a virtual switch.

Adding Logical Hybrid Interfaces

ASA FirePOWER — an interface configured on an ASA device with the ASA FirePOWER module installed.

Managing Cisco ASA with FirePOWER Services Interfaces

Note that you can only configure a total of 1024 interfaces on a FirePOWER managed device.

Note The Defense Center does not display ASA interfaces when the ASA FirePOWER device is deployed in SPAN port mode.

See the following sections for details on the different ways you can configure interfaces on a device:

- Configuring HA Link Interfaces

- MTU Ranges for Managed Devices

- Managing Cisco ASA with FirePOWER Services Interfaces

- Disabling Interfaces

- Preventing Duplicate Connection Logging

- Setting Up an IPS Device

- Setting Up Virtual Switches

- Setting Up Virtual Routers

- Setting Up Aggregate Interfaces

- Setting Up Hybrid Interfaces

Configuring HA Link Interfaces

License: Any

Supported Devices: Series 3

After you establish a device cluster, you can configure a physical interface as a high availability (HA) link interface. This link acts as a redundant communications channel for sharing health information between the clustered devices. When you configure an HA link interface on one device, you automatically configure an interface on the second device. You must configure both HA links on the same broadcast domain. See Clustering Devices for more information.

Dynamic NAT relies on dynamically allocating IP addresses and ports to map to other IP addresses and ports. Without an HA link, these mappings are lost in a failover, causing all translated connections to fail as they are routed through the now active device in the cluster.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

To configure an HA link interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Edit Interface pop-up window appears.

Step 4 Click HA Link to display the HA link options.

Step 5 Select the Enabled check box to allow the HA link interface to provide link.

If you clear the check box, the interface becomes disabled and administratively taken down.

Step 6 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to autonegotiate speed and duplex settings.

Step 7 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.

Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 8 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 9 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

MTU Ranges for Managed Devices

License: Any

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

Note that for Cisco NGIPS for Blue Coat X-Series, you configure the interface MTU using the Cisco NGIPS for Blue Coat X-Series CLI. See the Cisco NGIPS for Blue Coat X-Series Installation Guide for more information.

Note Because the system automatically trims 18 bytes from the configured MTU value, any value below 1298 does not comply with the minimum IPv6 MTU setting of 1280, and any value below 594 does not comply with the minimum IPv4 MTU setting of 576. For example, the system automatically trims a configured value of 576 to 558.

Table 4-7 MTU Range by Device

On this Model Device...

The MTU Range is...

Series 2, except 3D6500, 3D9900

576-1518 (all interfaces, inline sets)

3D6500, 3D9900, virtual

576-9018 (all interfaces, inline sets)

Series 3

576-9234 (management interface)

576-10172 (inline sets, passive interface)

576-9922 (all others)

Managing Cisco ASA with FirePOWER Services Interfaces

License: Protection

Supported Devices: ASA FirePOWER

When editing an ASA FirePOWER interface, you can configure only the interface’s security zone from the FireSIGHT Defense Center. See Working with Security Zones for more information.

You fully configure ASA FirePOWER interfaces using the ASA-specific software and CLI. If you edit an ASA FirePOWER device and switch from multiple context mode to single context mode (or visa versa), the device renames all of its interfaces. You must reconfigure all FireSIGHT System security zones, correlation rules, and related configurations to use the updated ASA FirePOWER interface names. For more information about ASA FirePOWER interface configuration, see the ASA documentation.

Note You cannot change the type of ASA FirePOWER interface, nor can you disable the interface from the FireSIGHT Defense Center.

To edit an ASA FirePOWER Interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Edit Interface pop-up window appears.

Step 4 From the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 5 Click Save.

The security zone is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Disabling Interfaces

License: Any

You can disable an interface by setting the interface type to None. Disabled interfaces appear grayed out in the interface list.

Note You cannot change the type of an ASA FirePOWER interface, nor can you disable the interface from the FireSIGHT Defense Center.

To disable an interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Edit Interface pop-up window appears.

Step 4 Click None.

Step 5 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Preventing Duplicate Connection Logging

License: Any

When you update a security zone object, the system saves a new revision of the object. As a result, if you have managed devices in the same security zone that have different revisions of the security zone object configured in the interfaces, you may log what appear to be duplicate connections.

If you notice duplicate connection reporting, you can update all managed devices to use the same revision of the object.

To synchronize security zone object revisions across devices:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

Caution You must not reapply managed device changes to any device until you have edited the zone setting for interfaces on all devices you want to sync.

).

The Interfaces tab for that device appears.

Step 3 For each interface logging duplicate connection events, change the Security Zone to another zone, click Save, then change it back to the desired zone, and click Save again.

Step 4 Repeat steps 2 through 3 for each device logging duplicate events.

Step 5 After all interfaces on all devices have been edited, apply device changes to all managed devices at once.

Setting Up an IPS Device

You can configure your device in either a passive or inline IPS deployment. In a passive deployment, you deploy the system out of band from the flow of network traffic. In an inline deployment, you configure the system transparently on a network segment by binding two ports together.

The following sections describe configuring your device for passive and inline deployments of the FireSIGHT System:

- Understanding Passive IPS Deployments

- Configuring Passive Interfaces

- Understanding Inline IPS Deployments

- Configuring Inline Interfaces

- Configuring Inline Sets

- Configuring Cisco NGIPS for Blue Coat X-Series Interfaces

Understanding Passive IPS Deployments

License: Protection

In a passive IPS deployment, the FireSIGHT System monitors traffic flowing across a network using a switch SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on the switch. This provides the system visibility within the network without being in the flow of network traffic. When configured in a passive deployment, the system cannot take certain actions such as blocking or shaping traffic. Passive interfaces receive all traffic unconditionally and no traffic received on these interfaces is retransmitted.

Note Outbound traffic includes flow control packets. Because of this, passive interfaces on your appliances may show outbound traffic and, depending on your configuration, generate events; this is expected behavior.

Configuring Passive Interfaces

License: Protection

You can configure one or more physical ports on a managed device as passive interfaces.

You configure Cisco NGIPS for Blue Coat X-Series interfaces as either passive or inline when installing the Cisco package. You cannot use the FireSIGHT System web interface to reconfigure Cisco NGIPS for Blue Coat X-Series interfaces. For more information, see Configuring Cisco NGIPS for Blue Coat X-Series Interfaces.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

To configure a passive interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

).

The Edit Interface pop-up window appears.

Step 4 Click Passive to display the passive interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 Select the Enabled check box to allow the passive interface to monitor traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 7 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to automatically negotiate speed and duplex settings. Note that mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options.

Step 8 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 9 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 10 Click Save.

The passive interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Understanding Inline IPS Deployments

License: Protection

In an inline IPS deployment, you configure the FireSIGHT System transparently on a network segment by binding two ports together. This allows the system to be installed in any network environment without the configuration of adjacent network devices. Inline interfaces receive all traffic unconditionally, but all traffic received on these interfaces is retransmitted out of an inline set unless explicitly dropped.

Configuring Inline Interfaces

License: Protection

You can configure one or more physical ports on a managed device as inline interfaces. You must assign a pair of inline interfaces to an inline set before they can handle traffic in an inline deployment.

Note that the system warns you if you set the interfaces in an inline pair to different speeds or if the interfaces negotiate to different speeds.

You configure Cisco NGIPS for Blue Coat X-Series interfaces as either passive or inline when installing the Cisco package. You cannot use the FireSIGHT System web interface to reconfigure Cisco NGIPS for Blue Coat X-Series interfaces. For more information, see Configuring Cisco NGIPS for Blue Coat X-Series Interfaces.

Note If you configure an interface as an inline interface, the adjacent port on its NetMod automatically becomes an inline interface as well to complete the pair.

To configure inline interfaces on a virtual device, you must create the inline pair using adjacent interfaces.

To configure an inline interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

).

The Edit Interface pop-up window appears.

Step 4 Click Inline to display the inline interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 From the Inline Set drop-down list, select an existing inline set or select New to add a new inline set.

Note that if you add a new inline set, you must configure it on the Device Management page (Devices > Device Management > Inline Sets) after you set up the inline interface. For more information, see Adding Inline Sets.

Step 7 Select the Enabled check box to allow the inline interface to handle traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to automatically negotiate speed and duplex settings. Note that Mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 10 Click Save.

The inline interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Configuring Inline Sets

License: Protection

Before you can use inline interfaces in an inline deployment, you must configure inline sets and assign inline interface pairs to them. An inline set is a grouping of one or more inline interface pairs on a device; an inline interface pair can belong to only one inline set at a time.

You can configure the interfaces on your managed device to route traffic between a host on your network and external hosts using different inline interface pairs, depending on whether the device traffic is inbound or outbound. This is an asynchronous routing configuration. If you deploy asynchronous routing but you include only one interface pair in an inline set, the device might not correctly analyze your network traffic because it might see only half of the traffic.

Adding multiple inline interface pairs to the same inline interface set allows the system to identify the inbound and outbound traffic as part of the same traffic flow. For passive interfaces, you can also achieve this by including the interface pairs in the same security zone.

Note If you assign multiple interface pairs to a single inline interface set but you experience issues with duplicate traffic, reconfigure to help the system uniquely identify packets. For example, you could reassign your interface pairs to separate inline sets or modify your security zones.

For devices with inline sets, a software bridge is automatically set up to transport packets after the device restarts. If the device is restarting, there is no software bridge running anywhere. If you enable bypass mode on the inline set, it goes into hardware bypass while the device is restarting. In that case, you may lose a few seconds of packets as the system goes down and comes back up, due to renegotiation of link with the device. However, the system will pass traffic while Snort is restarting.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

See the following sections for more information:

- Viewing Inline Sets

- Adding Inline Sets

- Configuring Advanced Inline Set Options

- Deleting Inline Sets

Viewing Inline Sets

License: Protection

The Inline Sets tab of the Device Management page displays a list of all inline sets you have configured on a device. Note that you cannot configure inline sets to go into bypass mode on a virtual device or Cisco NGIPS for Blue Coat X-Series. The Inline Sets Table View Fields table includes summary information about each set.

Table 5-1 Inline Sets Table View Fields

Field

Description

Name

The name of the inline set.

Interface Pairs

A list of all pairs of inline interfaces assigned to the inline set. A pair is not available when you disable either interface in the pair from the Interfaces tab.

Bypass

The configured bypass mode of the inline set.

Adding Inline Sets

License: Protection

You can add inline sets from the Inline Sets tab of the Device Management page or you can add inline sets as you configure inline interfaces.

You can assign only inline interface pairs to an inline set. If you want to create an inline set before you configure the inline interfaces on your managed devices, you can create an empty inline set and add interfaces to it later.

To add an inline set:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Inline Sets.

The Inline Sets tab appears.

Step 4 Click Add Inline Set.

The Add Inline Set pop-up window appears.

Step 5 In the Name field, type a name for the inline set. You can use alphanumeric characters and spaces.

Step 6 You have two options for selecting inline interface pairs to add to the inline set:

- Next to Interfaces , select one or more inline interface pairs, then click the add selected icon (

). Use Ctrl or Shift to select multiple inline interface pairs.

- To add all interface pairs to the inline set, click the add all icon (

).

Step 7 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 8 Optionally, select Failsafe to specify that traffic is allowed to bypass detection and continue through the device. Managed devices monitor internal traffic buffers and bypass detection if those buffers are full.

Enabling Failsafe on a device with inline sets greatly decreases the risk of dropped packets if the internal traffic buffers are full, but your device may still drop packets in certain conditions. In the worst case, your device may experience a temporary network outage.

Note that only Series 3 devices support this option.

Step 9 Select the bypass mode to configure how the relays in the inline interfaces respond when an interface fails:

- Select Bypass to allow traffic to continue to pass through the interfaces.

- Select Non-Bypass to block traffic.

Note In bypass mode, you may lose a few packets when you reboot the appliance. Also note that you cannot configure bypass mode for inline sets on clustered devices, inline sets on a virtual device or Cisco NGIPS for Blue Coat X-Series, for non-bypass NetMods on 8000 Series devices, or for SFP modules on 3D7115 or 3D7125 devices.

Step 10 Click OK.

The inline set is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Tip To configure advanced settings for the inline set, such as tap mode, link state propagation, and transparent inline mode, see Configuring Advanced Inline Set Options.

Configuring Advanced Inline Set Options

License: Protection

Supported Devices: feature dependent

There are a number of options you may consider as you configure inline sets. See the sections below for more information about each option.

Tap Mode

Supported Devices: Series 3

Tap mode is available on Series 3 devices when you create an inline or inline with fail-open interface set.

With tap mode, the device is deployed inline, but instead of the packet flow passing through the device, a copy of each packet is sent to the device and the network traffic flow is undisturbed. Because you are working with copies of packets rather than the packets themselves, rules that you set to drop and rules that use the replace keyword do not affect the packet stream. However, rules of these types do generate intrusion events when they are triggered, and the table view of intrusion events indicates that the triggering packets would have dropped in an inline deployment.

There are benefits to using tap mode with devices that are deployed inline. For example, you can set up the cabling between the device and the network as if the device were inline and analyze the kinds of intrusion events the device generates. Based on the results, you can modify your intrusion policy and add the drop rules that best protect your network without impacting its efficiency. When you are ready to deploy the device inline, you can disable tap mode and begin dropping suspicious traffic without having to reconfigure the cabling between the device and the network.

Note that you cannot enable this option and strict TCP enforcement on the same inline set.

Propagate Link State

Supported Devices: Series 2, Series 3

Link state propagation is a feature for inline sets configured in bypass mode so both pairs of an inline set track state. Link state propagation is available for both copper and fiber configurable bypass interfaces.

Link state propagation automatically brings down the second interface in the inline interface pair when one of the interfaces in an inline set goes down. When the downed interface comes back up, the second interface automatically comes back up, also. In other words, if the link state of one interface changes, the appliance senses the change and updates the link state of the other interface to match it. Note that appliances require up to 4 seconds to propagate link state changes.

Note When link state propagation triggers, fiber inline sets configured as fail-open on Series 2 devices activate hardware bypass mode. In this case, the interface cards involved do not come out of bypass automatically; you must bring them out of bypass mode manually. For more information about fiber interfaces in inline sets and hardware bypass, see Removing Bypass Mode on Fiber Inline Sets Configured to Fail Open.

Link state propagation is especially useful in resilient network environments where routers are configured to reroute traffic automatically around network devices that are in a failure state.

You cannot disable link state propagation for inline sets configured on clustered devices.

Note that virtual devices, Cisco NGIPS for Blue Coat X-Series, and Cisco ASA with FirePOWER Services do not support link state propagation.

Transparent Inline Mode

Transparent Inline Mode option allows the device to act as a “bump in the wire” and means that the device forwards all the network traffic it sees, regardless of its source and destination. Note that you cannot disable this option on Series 3 or 3D9900 devices.

Strict TCP Enforcement

Supported Devices: Series 3

To maximize TCP security, you can enable strict enforcement, which blocks connections where the three-way handshake was not completed. Strict enforcement also blocks:

- non-SYN TCP packets for connections where the three-way handshake was not completed

- non-SYN/RST packets from the initiator on a TCP connection before the responder sends the SYN-ACK

- non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before the session is established

- SYN packets on an established TCP connection from either the initiator or the responder

Note that Series 2, virtual devices, and Cisco NGIPS for Blue Coat X-Series do not support this option. In addition, you cannot enable this option and tap mode on the same inline set.

To configure advanced inline set options:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Inline Sets.

The Inline Sets tab appears.

).

The Edit Inline Set pop-up window appears.

Step 5 Click Advanced.

The Advanced tab appears.

Step 6 Optionally, select Tap Mode to enable tap mode on the inline interfaces of Series 3 devices.

Note that virtual devices, Cisco NGIPS for Blue Coat X-Series, and Series 2 devices other than 3D9900 do not support this option. In addition, you cannot enable Tap Mode and Strict TCP Enforcement on the same inline set.

Step 7 Optionally, select Propagate Link State on Series 2 or Series 3 devices. This option is especially useful if the routers on your network are able to reroute traffic around a network device that is down.

You cannot disable link state propagation for inline sets configured on clustered devices.

Note that virtual devices and Cisco NGIPS for Blue Coat X-Series do not support this option.

Step 8 Optionally, select Strict TCP Enforcement to enable strict TCP enforcement on Series 3 devices.

Note that Series 2, virtual devices, and Cisco NGIPS for Blue Coat X-Series do not support this option. In addition, you cannot enable Strict TCP Enforcement and Tap Mode on the same inline set.

Step 9 Optionally, select Transparent Inline Mode.

Note that you cannot disable this option on Series 3 devices.

Step 10 Click OK.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Removing Bypass Mode on Fiber Inline Sets Configured to Fail Open

License: Protection

Supported Devices: Series 2

When link state propagation is enabled on a Series 2 device with a fiber inline set configured to fail open and the device goes into bypass mode, all network traffic passes through the inline set without being analyzed. When the links restore, most fiber inline sets configured to fail open do not return from bypass automatically. You can use a command line tool to force the inline set out of bypass mode.

This tool works on inline sets with fiber inline interfaces configured to fail open. It is not necessary to use this tool on inline sets with copper inline interfaces set to fail open.

Note Contact Support if you are having issues with inline sets configured to fail open on your device.

To force a fiber inline set configured to fail open out of bypass mode on a device:

Access: Admin/Network Admin

Step 1 Open a terminal window on your device and sign in as the admin user.

Step 2 Enter the following at the command line:

sudo /var/sf/bin/unbypass_cards.sh

You are prompted for your password.

Step 3 When the interfaces switch out of bypass mode, a message in syslog indicates the device is analyzing traffic. For example:

Fiber pair has been reset by un_bypass

Deleting Inline Sets

License: Protection

When you delete an inline set, any inline interfaces assigned to the set become available for inclusion in another set. The interfaces are not deleted.

To delete an inline set:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Inline Sets.

The Inline Sets tab appears.

).

Step 5 When prompted, confirm that you want to delete the inline set.

The inline set is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Configuring Cisco NGIPS for Blue Coat X-Series Interfaces

License: Protection

Supported Devices: X-Series

You create passive or inline interfaces when you deploy Cisco NGIPS for Blue Coat X-Series package, or after the package has been installed. When you add Cisco NGIPS for Blue Coat X-Series to the Defense Center, these interfaces are already configured. Cisco NGIPS for Blue Coat X-Series does not support advanced configuration options.

You cannot reconfigure Cisco NGIPS for Blue Coat X-Series interfaces using the FireSIGHT System web interface. To reconfigure, you must first delete the current interface from the Defense Center, then create a new interface. For more information on creating and deleting interfaces, see the Cisco NGIPS for Blue Coat X-Series Installation Guide.

To configure an interface on Cisco NGIPS for Blue Coat X-Series:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

) for all Cisco NGIPS for Blue Coat X-Series interfaces.

).

Step 4 From the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 5 Optionally, for an inline interface, from the Inline Set drop-down list, select an existing inline set or select New to add a new inline set.

Note that if you add a new inline set, you must configure it on the Device Management page (Devices > Device Management > Inline Sets) after you set up the inline interface. For more information, see Adding Inline Sets.

Step 6 Click Save.

The interface is configured. Note that your changes do not take effect until you apply the device configurations by clicking Apply Changes at top right of the menu bar.

Setting Up Virtual Switches

You can configure a managed device in a Layer 2 deployment so that it provides packet switching between two or more networks. In a Layer 2 deployment, you can configure virtual switches on managed devices to operate as standalone broadcast domains, dividing your network into logical segments. A virtual switch uses the media access control (MAC) address from a host to determine where to send packets.

When you configure a virtual switch, the switch initially broadcasts packets through every available port on the switch. Over time, the switch uses tagged return traffic to learn which hosts reside on the networks connected to each port.

A virtual switch must contain two or more switched interfaces to handle traffic. For each virtual switch, traffic becomes limited to the set of ports configured as switched interfaces. For example, if you configure a virtual switch with four switched interfaces, packets sent in through one port for broadcast can only be sent out of the remaining three ports on the switch.

When you configure a physical switched interface, you must assign it to a virtual switch. You can also define additional logical switched interfaces on a physical port as needed. On Series 3 managed devices, you can group multiple physical interfaces into a single logical switched interface called a link aggregation group (LAG). This single aggregate logical link provides higher bandwidth, redundancy, and load-balancing between two endpoints.

Caution If a Layer 2 deployment fails for any reason, the device no longer passes traffic.

See the following sections for more information about configuring a Layer 2 deployment:

- Configuring Switched Interfaces

- Configuring Virtual Switches

- Configuring LAGs

Configuring Switched Interfaces

License: Control

Supported Devices: Series 3

You can set up switched interfaces to have either physical or logical configurations. You can configure physical switched interfaces for handling untagged VLAN traffic. You can also create logical switched interfaces for handling traffic with designated VLAN tags.

In a Layer 2 deployment, the system drops any traffic received on an external physical interface that does not have a switched interface waiting for it. If the system receives a packet with no VLAN tag and you have not configured a physical switched interface for that port, it drops the packet. If the system receives a VLAN-tagged packet and you have not configured a logical switched interface, it also drops the packet.

The system handles traffic that has been received with VLAN tags on switched interfaces by stripping the outermost VLAN tag on ingress before any rules evaluation or forwarding decisions. Packets leaving the device through a VLAN-tagged logical switched interface are encapsulated with the associated VLAN tag on egress.

Note that if you change the parent physical interface to inline or passive, the system deletes all the associated logical interfaces.

See the following sections for more information:

- Configuring Physical Switched Interfaces

- Adding Logical Switched Interfaces

- Deleting Logical Switched Interfaces

Configuring Physical Switched Interfaces

License: Control

Supported Devices: Series 3

You can configure one or more physical ports on a managed device as switched interfaces. You must assign a physical switched interface to a virtual switch before it can handle traffic.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

To configure a physical switched interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

).

The Edit Interface pop-up window appears.

Step 4 Click Switched to display the switched interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 Optionally, from the Virtual Switch drop-down list, select an existing virtual switch or select New to add a new virtual switch.

Note that if you add a new virtual switch, you must configure it on the Virtual Switches tab of the Device Management page (Devices > Device Management > Virtual Switches) after you set up the switched interface. See Adding Virtual Switches.

Step 7 Select the Enabled check box to allow the switched interface to handle traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to auto negotiate speed and duplex settings. Note that mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Click Save.

The physical switched interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Adding Logical Switched Interfaces

License: Control

Supported Devices: Series 3

For each physical switched interface, you can add multiple logical switched interfaces. You must associate each logical interface with a VLAN tag to handle traffic received by the physical interface with that specific tag. You must assign a logical switched interface to a virtual switch to handle traffic.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To add a logical switched interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Add Interface.

The Add Interface pop-up window appears.

Step 4 Click Switched to display the switched interface options.

Step 5 From the Interface drop-down list, select the physical interface that will receive the VLAN-tagged traffic.

Step 6 In the VLAN Tag field, type a tag value that gets assigned to inbound and outbound traffic on this interface. The value can be any integer from 1 to 4094.

Step 7 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 8 Optionally, from the Virtual Switch drop-down list, select an existing virtual switch or select New to add a new virtual switch.

Note that if you add a new virtual switch, you must configure it on the Device Management page (Devices > Device Management> Virtual Switches) after you set up the switched interface. See Adding Virtual Switches.

Step 9 Select the Enabled check box to allow the switched interface to handle traffic.

If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a physical interface, you also disable all of the logical interfaces associated with it.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Click Save.

The logical switched interface is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Note When a physical interface is disabled, the logical interface(s) associated with the physical interface is also disabled.

Deleting Logical Switched Interfaces

License: Control

Supported Devices: Series 3

When you delete a logical switched interface, you remove it from the physical interface where it resides, as well as the virtual switch and security zone it is associated with.

To delete a switched interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

) for that device.

The Interfaces tab for that device appears.

).

Step 4 When prompted, confirm that you want to delete the interface.

The interface is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Configuring Virtual Switches

License: Control

Supported Devices: Series 3

Before you can use switched interfaces in a Layer 2 deployment, you must configure virtual switches and assign switched interfaces to them. A virtual switch is a group of switched interfaces that process inbound and outbound traffic through your network.

See the following sections for more information about configuring virtual switches:

- Viewing Virtual Switches

- Adding Virtual Switches

- Configuring Advanced Virtual Switch Settings

- Deleting Virtual Switches

Viewing Virtual Switches

License: Control

Supported Devices: Series 3

Table 6-1 Virtual Switches Table View Fields

Field

Description

Name

The name of the virtual switch.

Interfaces

All switched interfaces that are assigned to the virtual switch. Interfaces that you have disabled from the Interfaces tab are not available.

Hybrid Interface

The optionally configured hybrid interface that ties the virtual switch to a virtual router.

Unicast Packets

Unicast packet statistics for the virtual switch, including:

- Unicast packets received

- Unicast packets forwarded (excludes drops by host)

- Unicast packets unintentionally dropped

Broadcast Packets

Broadcast packet statistics for the virtual switch, including:

- Broadcast packets received

- Broadcast packets forwarded

- Broadcast packets unintentionally dropped

Adding Virtual Switches

License: Control

Supported Devices: Series 3

You can add virtual switches from the Virtual Switches tab of the Device Management page. You can also add switches as you configure switched interfaces.

You can assign only switched interfaces to a virtual switch. If you want to create a virtual switch before you configure the switched interfaces on your managed devices, you can create an empty virtual switch and add interfaces to it later.

To add a virtual switch:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Virtual Switches.

The Virtual Switches tab appears.

Step 4 Click Add Virtual Switch.

The Add Virtual Switch pop-up window appears.

Step 5 In the Name field, type a name for the virtual switch. You can use alphanumeric characters and spaces.

Step 6 Under Available, select one or more switched interfaces to add to the virtual switch.

Tip Interfaces that you have disabled from the Interfaces tab are not available; disabling an interface after you add it removes it from the configuration.

Step 7 Click Add.

Step 8 Optionally, from the Hybrid Interface drop-down list, select a hybrid interface that ties the virtual switch to a virtual router. For more information, see Setting Up Hybrid Interfaces.

Step 9 Click Save.

The virtual switch is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Tip To configure advanced settings for the switch, such as static MAC entries and spanning tree protocol, see Configuring Advanced Virtual Switch Settings.

Configuring Advanced Virtual Switch Settings

License: Control

Supported Devices: Series 3

When adding or editing a virtual switch, you can add static MAC entries, enable Spanning Tree Protocol (STP), drop Bridge Protocol Data Units (BPDU), and enable strict TCP enforcement.

Over time, a virtual switch learns MAC addresses by tagging return traffic from the network. Optionally, you can manually add a static MAC entry, which designates that a MAC address resides on a specific port. Regardless of whether you ever receive traffic from that port, the MAC address remains static in the table. You can specify one or more static MAC addresses for each virtual switch.

STP is a network protocol used to prevent network loops. BPDUs are exchanged through the network, carrying information about network bridges. The protocol uses BPDUs to identify and select the fastest network links, if there are redundant links in the network. If a network link fails, Spanning Tree fails over to an existing alternate link.

If your virtual switch routes traffic between VLANs, similar to a router on a stick, BPDUs enter and exit the device through different logical switched interfaces, but the same physical switched interface. As a result, STP identifies the device as a redundant network loop, which can cause issues in certain Layer 2 deployments. To prevent this, you can configure the virtual switch at the domain level to have the device drop BPDUs when monitoring traffic.

Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy in a device cluster.

To maximize TCP security, you can enable strict enforcement, which blocks connections where the three-way handshake was not completed. Strict enforcement also blocks:

- non-SYN TCP packets for connections where the three-way handshake was not completed

- non-SYN/RST packets from the initiator on a TCP connection before the responder sends the SYN-ACK

- non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before the session is established

- SYN packets on an established TCP connection from either the initiator or the responder

Note that if you associate the virtual switch with a logical hybrid interface, the switch uses the same strict TCP enforcement setting as the virtual router associated with the logical hybrid interface. You cannot specify strict TCP enforcement on the switch in this case.

To configure advanced virtual switch settings:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 Click Virtual Switches.

The Virtual Switches tab appears.

).

The Edit Virtual Switch pop-up window appears.

Step 5 Click Advanced.

The Advanced tab appears.

Step 6 To add a static MAC entry, click Add.

The Add Static MAC Address pop-up window appears.

Step 7 In the MAC Address field, type the address using the standard format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).

Note Broadcast addresses (00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF) cannot be added as static MAC addresses.

Step 8 From the Interface drop-down list, select the interface where you want to assign the MAC address.

Step 9 Click Add.

The MAC address is added to the Static MAC Entries table.

).

Step 10 Optionally, to enable the Spanning Tree Protocol, select Enable Spanning Tree Protocol. Select Enable Spanning Tree Protocol only if your virtual switch switches traffic between multiple network interfaces.

You cannot select Drop BPDUs unless you clear Enable Spanning Tree Protocol.

Step 11 Optionally, select Strict TCP Enforcement to enable strict TCP enforcement.

If you associate the virtual switch with a logical hybrid interface, this option does not appear and the switch uses the same setting as the virtual router associated with the logical hybrid interface.

Step 12 Optionally, select Drop BPDUs to drop BPDUs at the domain level. Select Drop BPDUs only if your virtual switch routes traffic between VLANs on a single physical interface.

You cannot select Enable Spanning Tree Protocol unless you clear Drop BPDUs.

Step 13 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Deleting Virtual Switches

License: Control

Supported Devices: Series 3

When you delete a virtual switch, any switched interfaces assigned to the switch become available for inclusion in another switch.

To delete a virtual switch:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

) for that device.

The Interfaces tab for that device appears.

Step 3 Click Virtual Switches.

The Virtual Switches tab appears.

).

Step 5 When prompted, confirm that you want to delete the virtual switch.

The virtual switch is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Setting Up Virtual Routers

You can configure a managed device in a Layer 3 deployment so that it routes traffic between two or more interfaces. You must assign an IP address to each interface and assign the interfaces to a virtual router to route traffic. On Series 3 managed devices, you can group multiple physical interfaces into a single logical routed interface called a link aggregation group (LAG). This single aggregate logical link provides higher bandwidth, redundancy, and load-balancing between two endpoints.

You can configure the system to route packets by making packet forwarding decisions according to the destination address. Interfaces configured as routed interfaces receive and forward the Layer 3 traffic. Routers obtain the destination from the outgoing interface based on the forwarding criteria, and access control rules designate the security policies to be applied.

In Layer 3 deployments, you can define static routes. In addition, you can configure Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) dynamic routing protocols. You can also configure a combination of static routes and RIP or static routes and OSPF.

Caution If a Layer 3 deployment fails for any reason, the device no longer passes traffic.

Caution Adding a virtual router restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

See the following sections for more information about configuring a Layer 3 deployment:

- Configuring Routed Interfaces

- Configuring Virtual Routers

- Configuring LAGs

Configuring Routed Interfaces

License: Control

Supported Devices: Series 3

You can set up routed interfaces with either physical or logical configurations. You can configure physical routed interfaces for handling untagged VLAN traffic. You can also create logical routed interfaces for handling traffic with designated VLAN tags.

In a Layer 3 deployment, the system drops any traffic received on an external physical interface that does not have a routed interface waiting for it. If the system receives a packet with no VLAN tag and you have not configured a physical routed interface for that port, it drops the packet. If the system receives a VLAN-tagged packet and you have not configured a logical routed interface, it also drops the packet.

The system handles traffic that has been received with VLAN tags on switched interfaces by stripping the outermost VLAN tag on ingress prior to any rules evaluation or forwarding decisions. Packets leaving the device through a VLAN-tagged logical routed interface are encapsulated with the associated VLAN tag on egress. The system drops any traffic received with a VLAN tag after the stripping process completes.

Note that if you change the parent physical interface to inline or passive, the system deletes all the associated logical interfaces.

See the following sections for more information:

- Configuring Physical Routed Interfaces

- Adding Logical Routed Interfaces

- Deleting Logical Routed Interfaces

- Configuring SFRP

Configuring Physical Routed Interfaces

License: Control

Supported Devices: Series 3

You can configure one or more physical ports on a managed device as routed interfaces. You must assign a physical routed interface to a virtual router before it can route traffic.

Caution Adding a routed interface pair on a Series 3 device restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

You can add static Address Resolution Protocol (ARP) entries to a routed interface. If an external host needs to know the MAC address of the destination IP address it needs to send traffic to on your local network, it sends an ARP request. When you configure static ARP entries, the virtual router responds with an IP address and associated MAC address.

Note that disabling the ICMP Enable Responses option for routed interfaces does not prevent ICMP responses in all scenarios. You can add rules to an access control policy to drop packets where the destination IP is the routed interface’s IP and the protocol is ICMP; see Controlling Traffic with Network-Based Rules.

If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets before they reach the host, thereby preventing any response. For more information about inspecting local router traffic, see Understanding Advanced Device Settings.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

To configure a physical routed interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Edit Interface pop-up window appears.

Step 4 Click Routed to display the routed interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 Optionally, from the Virtual Router drop-down list, select an existing virtual router or select New to add a new virtual router.

Note that if you add a new virtual router, you must configure it on the Virtual Routers tab of the Device Management page (Devices > Device Management > Virtual Routers) after you set up the routed interface. See Adding Virtual Routers.

Step 7 Select the Enabled check box to allow the routed interface to handle traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to auto negotiate speed and duplex settings. Note that mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed. Note that the MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Next to ICMP, select the Enable Responses check box to allow the interface to respond to ICMP traffic such as pings and traceroute.

Step 12 Next to IPv6 NDP, select the Enable Router Advertisement check box to enable the interface to broadcast router advertisements.

Step 13 To add an IP address, click Add.

The Add IP Address pop-up window appears.

Step 14 In the Address field, type the routed interface’s IP address and subnet mask using CIDR notation. Note the following:

- You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF.

- You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 Optionally, if your organization uses IPv6 addresses, next to the IPv6 field, select the Address Autoconfiguration check box to set the IP address of the interface automatically.

Step 16 For Type, select either Normal or SFRP.

For SFRP options, see Configuring SFRP for more information.

Step 17 Click OK.

The IP address is added.

).

Note When adding an IP address to a routed interface of a clustered device, you must add a corresponding IP address to the routed interface on the cluster peer.

Step 18 To add a static ARP entry, click Add.

The Add Static ARP Entry pop-up window appears.

Step 19 In the IP Address field, type an IP address for the static ARP entry.

Step 20 In the MAC Address field, type a MAC address to associate with the IP address. Enter the address using the standard format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).

Step 21 Click OK.

The static ARP entry is added.

Step 22 Click Save.

The physical routed interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Logical Routed Interfaces

License: Control

Supported Devices: Series 3

For each physical routed interface, you can add multiple logical routed interfaces. You must associate each logical interface with a VLAN tag to handle traffic received by the physical interface with that specific tag. You must assign a logical routed interface to a virtual router to route traffic.

Caution Adding a routed interface pair on a Series 3 device restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Note that disabling the ICMP Enable Responses option for routed interfaces does not prevent ICMP responses in all scenarios. You can add rules to an access control policy to drop packets where the destination IP is the routed interface’s IP and the protocol is ICMP; see Controlling Traffic with Network-Based Rules.

If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets before they reach the host, thereby preventing any response. For more information about inspecting local router traffic, see Understanding Advanced Device Settings.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To add a logical routed interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Add Interface.

The Add Interface pop-up window appears.

Step 4 Click Routed to display the routed interface options.

Step 5 From the Interface drop-down list, select the physical interface where you want to add the logical interface.

Step 6 In the VLAN Tag field, type a tag value that gets assigned to inbound and outbound traffic on this interface. The value can be any integer from 1 to 4094.

Step 7 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 8 Optionally, from the Virtual Router drop-down list, select an existing virtual router or select New to add a new virtual router.

Note that if you add a new virtual router, you must configure it on the Device Management page (Devices > Device Management > Virtual Routers) after you finish setting up the routed interface. See Adding Virtual Routers.

Step 9 Select the Enabled check box to allow the routed interface to handle traffic.

If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a physical interface, you also disable all of the logical interfaces associated with it.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed. Note that the MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Next to ICMP, select the Enable Responses check box to communicate updates or error information to other routers, intermediary devices, or hosts.

Step 12 Next to IPv6 NDP, select the Enable Router Advertisement check box to enable the interface to broadcast router advertisements.

Step 13 To add an IP address, click Add.

The Add IP Address pop-up window appears.

Step 14 In the Address field, type the IP address in CIDR notation. Note the following:

- You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF.

- You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 Optionally, if your organization uses IPv6 addresses, next to the IPv6 field, select the Address Autoconfiguration check box to set the IP address of the interface automatically.

Step 16 For Type, select either Normal or SFRP.

For SFRP options, see Configuring SFRP for more information.

Step 17 Click OK.

The IP address is added.

).

Note When you add an IP address to a routed interface of a clustered device, you must add a corresponding IP address to the routed interface on the cluster peer.

Step 18 To add a static ARP entry, click Add.

The Add Static ARP Entry pop-up window appears.

Step 19 In the IP Address field, type an IP address for the static ARP entry.

Step 20 In the MAC Address field, type a MAC address to associate with the IP address. Enter the address using the standard format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).

Step 21 Click OK.

The static ARP entry is added.

Step 22 Click Save.

The logical routed interface is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Note When a physical interface is disabled, the logical interface(s) associated with the physical interface is also disabled.

Deleting Logical Routed Interfaces

License: Control

Supported Devices: Series 3

When you delete a logical routed interface, you remove it from the physical interface where it resides, as well as its assigned virtual router and security zone.

Caution Adding a routed interface pair on a Series 3 device restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To delete a routed interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

Step 4 When prompted, confirm that you want to delete the interface.

The interface is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Configuring SFRP

License: Control

Supported Devices: Series 3

You can configure Cisco Redundancy Protocol (SFRP) to achieve network redundancy for high availability on either a device cluster or individual devices. SFRP provides gateway redundancy for both IPv4 and IPv6 addresses. You can configure SFRP on routed and hybrid interfaces.

If the interfaces are configured on individual devices, they must be in the same broadcast domain. You must designate at least one of the interfaces as master and an equal number as backup. The system supports only one master and one backup per IP address. If network connectivity is lost, the system automatically promotes the backup to master to maintain connectivity.

The options you set for SFRP must be the same on all interfaces in a group of SFRP interfaces. Multiple IP addresses in a group must be in the same master/backup state. Therefore, when you add or edit an IP address, the state you set for that address propagates to all the addresses in the group. For security purposes, you must enter values for Group ID and Shared Secret that are shared among the interfaces in the group.

To enable SFRP IP addresses on a virtual router, you must also configure at least one non-SFRP IP address.

For clustered devices, you designate the shared secret and the system copies it to the cluster peer along with the SFRP IP configuration. The shared secret authenticates peer data.

Note Cisco does not recommend enabling more than one non-SFRP IP address on a clustered Series 3 device’s routed or hybrid interface where one SFRP IP address is already configured.

For more information about clustering devices, see Clustering Devices.

To configure SFRP:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Edit Interface pop-up window appears.

Step 4 Select the type of interface where you want to configure SFRP:

- Click Routed to display the routed interface options.

- Click Hybrid to display the hybrid interface options.

Step 5 You can configure SFRP while adding or editing an IP address:

- To add an IP address, click Add .

- To edit an IP address, click the edit icon (

).

The Add IP Address or Edit IP Address pop-up window appears.

Step 6 For Type, select SFRP to display the SFRP options.

Step 7 In the Group ID field, enter a value that designates a group of master or backup interfaces configured for SFRP.

Step 8 For Priority, select either Master or Backup to designate the preferred interface:

- For individual devices, you must set one interface to master on one device and the other to backup on a second device.

- For device clusters, when you set one interface as master, the other automatically becomes the backup.

Step 9 In the Shared Secret field, type a shared secret.

The Shared Secret field populates automatically for a group in a device cluster.

Step 10 In the Adv. Interval (seconds) field, enter an interval for route advertisements for Layer 3 traffic.

Step 11 Click OK.

The IP address is added or edited.

Step 12 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Configuring Virtual Routers

License: Control

Supported Devices: Series 3

Before you can use routed interfaces in a Layer 3 deployment, you must configure virtual routers and assign routed interfaces to them. A virtual router is a group of routed interfaces that route Layer 3 traffic.

See the following sections for more information about configuring virtual routers:

- Viewing Virtual Routers

- Adding Virtual Routers

- Viewing Virtual Router Statistics

- Deleting Virtual Routers

Viewing Virtual Routers

License: Control

Supported Devices: Series 3

Table 7-1 Virtual Routers Table View Fields

Field

Description

Name

The name of the virtual router.

Interfaces

A list of all routed interfaces that are assigned to the virtual router. Disabling an interface from the Interfaces tab removes it.

Protocols

The protocols currently in use by the virtual router, which is one of the following:

- Static

- Static, RIP

- Static, OSPF

Adding Virtual Routers

License: Control

Supported Devices: Series 3

You can add virtual routers from the Virtual Routers tab of the Device Management page. You can also add routers as you configure routed interfaces.

You can assign only routed and hybrid interfaces to a virtual router. If you want to create a virtual router before you configure the interfaces on your managed devices, you can create an empty virtual router and add interfaces to it later.

To maximize TCP security, you can enable strict enforcement, which blocks connections where the three-way handshake was not completed. Strict enforcement also blocks:

- non-SYN TCP packets for connections where the three-way handshake was not completed

- non-SYN/RST packets from the initiator on a TCP connection before the responder sends the SYN-ACK

- non-SYN-ACK/RST packets from the responder on a TCP connection after the SYN but before the session is established

- SYN packets on an established TCP connection from either the initiator or the responder

Note that if you change the configuration of a Layer 3 interface to a non-Layer 3 interface or remove a Layer 3 interface from the virtual router, the router may fall into an invalid state. For example, if it is used in DHCPv6, it may cause an upstream and downstream mismatch. Any changes you make to an existing virtual router may interrupt traffic on the device.

You can configure virtual routers in several different ways beyond the general options. See the following sections for more information about these configurations:

- Setting Up DHCP Relay

- Setting Up Static Routes

- Setting Up Dynamic Routing

- Setting Up RIP Configuration

- Setting Up OSPF Configuration

- Setting Up Virtual Router Filters

- Adding Virtual Router Authentication Profiles

To add a virtual router:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

Tip If your devices are in a clustered stack deployment, select the stack you want to modify from the Selected Device drop-down list.

Step 4 Click Add Virtual Router.

The Add Virtual Router pop-up window appears.

Step 5 In the Name field, type a name for the virtual router. You can use alphanumeric characters and spaces.

Step 6 To enable IPv6 static routing, OSPFv3, and RIPng on your virtual router, select the IPv6 Support check box. To disable these features, clear the check box.

Step 7 Optionally, clear Strict TCP Enforcement if you do not want to enable strict TCP enforcement.

This option is enabled by default.

Step 8 Under Interfaces, the Available list contains all enabled Layer 3 interfaces, routed and hybrid, on the device that you can assign to the virtual router. Select one or more interfaces to assign to the virtual router and click Add.

Step 9 Click Save.

The virtual router is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up DHCP Relay

License: Control

Supported Devices: Series 3

DHCP provides configuration parameters to Internet hosts. A DHCP client that has not yet acquired an IP address cannot communicate directly with a DHCP server outside its broadcast domain. To allow DHCP clients to communicate with DHCP servers, you can configure DHCP relay instances to handle cases where the client is not on the same broadcast domain as the server.

You can set up DHCP relay for each virtual router you configure. By default, this feature is disabled. You can enable either DHCPv4 relay or DHCPv6 relay.

See the following sections for more information:

- Setting Up DHCPv4 Relay

- Setting Up DHCPv6 Relay

Setting Up DHCPv4 Relay

License: Control

Supported Devices: Series 3

The following procedure explains how to set up DHCPv4 relay on a virtual router.

To set up DHCPv4 relay:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 To set up DHCP relay for DHCPv4, select the DHCPv4 check box.

Step 6 Under the Servers field, type a server IP address.

Step 7 Click Add.

The IP address is added to the Servers field. You can add up to four DHCP servers.

Step 8 In the Max Hops field, type the maximum number of hops from 1 to 255.

Step 9 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up DHCPv6 Relay

License: Control

Supported Devices: Series 3

The following procedure explains how to set up DHCPv6 relay on a virtual router.

Note You cannot run a DHCPv6 Relay chain through two or more virtual routers running on the same device.

To set up DHCPv6 relay:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 To set up DHCP relay for DHCPv6, select the DHCPv6 check box.

Step 6 In the Interfaces field, select the check boxes next to one or more interfaces that have been assigned to the virtual router.

Tip You cannot disable an interface from the Interfaces tab while it is configured for DHCPv6 Relay. You must first clear the DHCPv6 Relay interfaces check box and save the configuration.

Step 7 Next to a selected interface, click the drop-down icon and select whether the interface relays DHCP requests Upstream, Downstream, or Both.

Note that you must include at least one downstream interface and one upstream interface. Selecting both means that the interface is both downstream and upstream.

Step 8 In the Max Hops field, type the maximum number of hops from 1 to 255

Step 9 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up Static Routes

License: Control

Supported Devices: Series 3

Static routing allows you to write rules about the IP addresses of traffic passing through a router. It is the simplest way of configuring path selection of a virtual router because there is no communication with other routers regarding the current topology of the network.

See the following sections for more information:

- Understanding the Static Routes Table View

- Adding Static Routes

Understanding the Static Routes Table View

License: Control

Supported Devices: Series 3

Table 7-2 Static Routes Table View Fields

Field

Description

Enabled

Specifies whether this route is currently enabled or disabled.

Name

The name of the static route.

Destination

The destination network where traffic is routed.

Type

Specifies the action that is taken for this route, which will is one of the following:

- IP — designates that the route forwards packets to the address of a neighboring router.

- Interface — designates that the route forwards packets to an interface through which traffic is routed to hosts on a directly connected network.

- Discard — designates that the static route drops packets.

Gateway

The target IP address if you selected IP as the static route type or the interface if you selected Interface as the static route type.

Preference

Determines the route selection. If you have multiple routes to the same destination, the system selects the route with the higher preference.

Adding Static Routes

License: Control

Supported Devices: Series 3

The following procedure explains how to add a static route.

).

To add a static route:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Static to display the static route options.

Step 6 Click Add Static Route.

The Add Static Route pop-up window appears.

Step 7 In the Route Name field, type a name for the static route. You can use alphanumeric characters and spaces.

Step 8 For Enabled, select the check box to specify that the route is currently enabled.

Step 9 In the Preference field, type a numerical value between 1 and 65535 to determine the route selection.

If you have multiple routes to the same destination, the system selects the route with the higher preference.

Step 10 From the Type drop-down list, select the type of static route you are configuring.

Step 11 In the Destination field, type the IP address for the destination network where traffic should be routed.

Step 12 In the Gateway field, you have two options:

- If you selected IP as the selected static route type, type an IP address.

- If you selected Interface as the selected static route type, select an enabled interface from the drop-down list.

Tip Interfaces you have disabled from the Interfaces tab are not available; disabling an interface you have added removes it from the configuration.

Step 13 Click OK.

The static route is added.

Step 14 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up Dynamic Routing

License: Control

Supported Devices: Series 3

Dynamic, or adaptive, routing uses a routing protocol to alter the path that a route takes in response to a change in network conditions. The adaptation is intended to allow as many routes as possible to remain valid, that is, have destinations that can be reached in response to the change. This allows the network to “route around” damage, such as loss of a node or a connection between nodes, so long as other path choices are available. You can configure a router with no dynamic routing, or you can configure the Routing Information Protocol (RIP) or the Open Shortest Path First (OSPF) routing protocol.

See the following sections for more information:

- Setting Up RIP Configuration

- Setting Up OSPF Configuration

Setting Up RIP Configuration

License: Control

Supported Devices: Series 3

Routing Information Protocol (RIP) is a dynamic routing protocol, designed for small IP networks, that relies on hop count to determine routes. The best routes use the fewest number of hops. The maximum number of hops allowed for RIP is 15. This hop limit also limits the size of the network that RIP can support.

See the following sections for more information on configuring RIP:

- Adding Interfaces for RIP Configuration

- Configuring Authentication Settings for RIP Configuration

- Configuring Advanced Settings for RIP Configuration

- Adding Import Filters for RIP Configuration

- Adding Export Filters for RIP Configuration

Adding Interfaces for RIP Configuration

License: Control

Supported Devices: Series 3

While configuring RIP, you must select interfaces from those already included in the virtual router, where you want to configure RIP. Disabled interfaces are not available.

).

To add an interface for RIP configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click RIP to display the RIP options.

).

The Add an Interface pop-up window appears.

Step 8 From the Name drop-down list, select the interface where you want to configure RIP.

Tip Interfaces you have disabled from the Interfaces tab are not available; disabling an interface you have added removes it from the configuration.

Step 9 In the Metric field, type a metric for the interface. When routes from different RIP instances are available and all of them have the same preference, the route with the lowest metric becomes the preferred route.

Step 10 From the Mode drop-down list, select one of the following options:

- Multicast — default mode where RIP multicasts the entire routing table to all adjacent routers at a specified address.

- Broadcast — forces RIP to use broadcast (for example, RIPv1) even though multicast mode is possible.

- Quiet — RIP will not transmit any periodic messages to this interface.

- No Listen — RIP will send to this interface but not listen to it.

Step 11 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Configuring Authentication Settings for RIP Configuration

License: Control

Supported Devices: Series 3

RIP authentication uses one of the authentication profiles you configured on the virtual router. For more information about configuring authentication profiles, see Adding Virtual Router Authentication Profiles.

To configure authentication settings for RIP configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click RIP to display the RIP options.

Step 7 Under Authentication, use the Profile drop-down list to select an existing virtual router authentication profile or select None.

Step 8 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Configuring Advanced Settings for RIP Configuration

License: Control

Supported Devices: Series 3

You can configure several advanced RIP settings pertaining to various timeout values and other features that affect the behavior of the protocol.

Caution Changing any of the advanced RIP settings to incorrect values can prevent the router from communicating successfully with other RIP routers.

To configure advanced settings for RIP configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click RIP to display the RIP options.

Step 7 In the Preference field, type a numerical value (higher is better) for the preference of the routing protocol. The system prefers routes learned through RIP over static routes.

Step 8 In the Period field, type the interval, in seconds, between periodic updates. A lower number determines faster convergence, but larger network load.

Step 9 In the Timeout Time field, type a numerical value that specifies how old routes must be, in seconds, before being considered unreachable.

Step 10 In the Garbage Time field, type a numerical value that specifies how old routes must be, in seconds, before being discarded.

Step 11 In the Infinity field, type a numerical value that specifies a value for infinity distance in convergence calculations. Larger values will make protocol convergence slower.

Step 12 From the Honor drop-down list, select one of the following options to designate when requests for dumping routing tables should be honored:

- Always — always honor requests

- Neighbor — only honor requests sent from a host on a directly connected network

- Never — never honor requests

Step 13 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Import Filters for RIP Configuration

License: Control

Supported Devices: Series 3

You can add an import filter to designate which routes are accepted or rejected from RIP into the route table. Import filters are applied in the order they appear in the table.

When adding an import filter, you use one of the filters you configured on the virtual router. For more information about configuring filters, see Setting Up Virtual Router Filters.

To add an import filter for RIP configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click RIP to display the RIP options.

).

The Add an Import Filter pop-up window appears.

Step 8 From the Name drop-down list, select the filter you want to add as an import filter.

Step 9 Next to Action, select Accept or Reject.

Step 10 Click OK.

The import filter is added.

Step 11 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Export Filters for RIP Configuration

License: Control

Supported Devices: Series 3

You can add an export filter to define which routes will be accepted or rejected from the route table to RIP. Export filters are applied in the order they appear in the table.

When adding an export filter, you use one of the filters you configured on the virtual router. For more information about configuring filters, see Setting Up Virtual Router Filters.

To add an export filter for RIP configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click RIP to display the RIP options.

).

The Add an Export Filter pop-up window appears.

Step 8 From the Name drop-down list, select the filter you want to add as an export filter.

Step 9 Next to Action, select Accept or Reject.

Step 10 Click OK.

The export filter is added.

Step 11 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up OSPF Configuration

License: Control

Supported Devices: Series 3

Open Shortest Path First (OSPF) is an adaptive routing protocol that defines routes dynamically by obtaining information from other routers and advertising routes to other routers using link state advertisements. The router keeps information about the links between it and the destination to make routing decisions. OSPF assigns a cost to each routed interface, and considers the best routes to have the lowest costs.

See the following sections for more information:

- Setting Up OSPF Routing Areas

- Adding Import Filters for OSPF Configuration

- Adding Export Filters for OSPF Configuration

Setting Up OSPF Routing Areas

License: Control

Supported Devices: Series 3

An OSPF network may be structured, or subdivided, into routing areas to simplify administration and optimize traffic and resource use. Areas are identified by 32-bit numbers, expressed either simply in decimal or often in octet-based dot-decimal notation.

By convention, area zero or 0.0.0.0 represents the core or backbone region of an OSPF network. You may choose to identify other areas. Often, administrators select the IP address of a main router in an area as the area's identification. Each additional area must have a direct or virtual connection to the backbone OSPF area. Such connections are maintained by an interconnecting router, known as the area border router (ABR). An ABR maintains separate link state databases for each area it serves and maintains summarized routes for all areas in the network.

See the following sections for more information on setting up OSPF areas:

- Adding OSPF Areas

- Adding OSPF Area Interfaces

- Adding OSPF Area Vlinks

Adding OSPF Areas

License: Control

Supported Devices: Series 3

The following procedure explains how to add an OSPF area and configure general settings.

To add an OSPF area:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click OSPF to display the OSPF options.

).

The Add OSPF Area pop-up window appears.

Step 8 In the Area Id field, type a numerical value for the area. This value can be either an integer or an IPv4 address.

Step 9 Optionally, select the Stubnet check box to designate that the area does not receive router advertisements external to the autonomous system and routing from within the area is based entirely on a default route. If you clear the check box, the area becomes a backbone area or otherwise non-stub area.

The Default cost field and Stubnet field appear.

Step 10 In the Default cost field, type a cost associated with the default route for the area.

).

Step 12 In the IP Address field, type an IP address in CIDR notation.

Step 13 Select the Hidden check box to indicate that the stubnet is hidden. Hidden stubnets are not propagated into other areas.

Step 14 Select the Summary check box to designate that default stubnets that are subnetworks of this stubnet are suppressed.

Step 15 In the Stub cost field, type a value that defines the cost associated with routing to this stub network.

Step 16 Click OK.

The stubnet is added.

).

Step 18 In the IP Address field, type an IP address in CIDR notation for the network.

Step 19 Select the Hidden check box to indicate that the network is hidden. Hidden networks are not propagated into other areas.

Step 20 Click OK.

The network is added.

Step 21 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding OSPF Area Interfaces

License: Control

Supported Devices: Series 3

You can configure a subset of the interfaces assigned to the virtual router for OSPF. The following list describes the options you can specify on each interface.

Interfaces

Select the interface where you want to configure OSPF. Interfaces you have disabled from the Interfaces tab are not available.

Type

Select the type of OSPF interface from the following choices:

– Broadcast — On broadcast networks, flooding and hello messages are sent using multicasts, a single packet for all the neighbors. The option designates a router to be responsible for synchronizing the link state databases and originating network link state advertisements. This network type cannot be used on physically non-broadcast multiple-access (NBMP) networks and on unnumbered networks without proper IP prefixes.

– Point-to-Point (PtP) — Point-to-point networks connect just two routers together. No election is performed and no network link state advertisement is originated, which makes it simpler and faster to establish. This network type is useful not only for physically PtP interfaces, but also for broadcast networks used as PtP links. This network type cannot be used on physically NBMP networks.

– Non-Broadcast — On NBMP networks, the packets are sent to each neighbor separately because of the lack of multicast capabilities. Similar to broadcast networks, the option designates a router, which plays a central role in the propagation of link state advertisements. This network type cannot be used on unnumbered networks.

– Autodetect — The system determines the correct type based on the specified interface.

Cost

Specify the output cost of the interface.

Stub

Specify whether the interface should listen for OSPF traffic and transmit its own traffic.

Priority

Enter a numerical value that specifies the priority value used in designated router election. On every multiple access network, the system designates a router and backup router. These routers have some special functions in the flooding process. Higher priority increases preferences in this election. You cannot configure a router with a priority of 0.

Nonbroadcast

Specify whether hello packets are sent to any undefined neighbors. This switch is ignored on any NBMA network.

Authentication

Select the OSPF authentication profile that this interface uses from one of the authentication profiles you configured on the virtual router or select None. For more information about configuring authentication profiles, see Adding Virtual Router Authentication Profiles.

Hello Interval

Type the interval, in seconds, between the sending of hello messages.

Poll

Type the interval, in seconds, between the sending of hello messages for some neighbors on NBMA networks.

Retrans Interval

Type the interval, in seconds, between retransmissions of unacknowledged updates.

Retrans Delay

Type the estimated number of seconds it takes to transmit a link state update packet over the interface.

Wait Time

Type the number of seconds that the router waits between starting election and building adjacency.

Dead Interval

Type the number of seconds that the router waits before declaring a neighbor down when not receiving messages from it. If this value is defined, it overrides the value calculated from dead count.

Dead Count

Type a numerical value that when multiplied by the hello interval specifies the number of seconds that the router waits before declaring a neighbor down when not receiving messages from it.

). Disabling a configured interface from the Interfaces tab also deletes it.

Note You can select only one interface for use in an OSPF area.

To add an OSPF area interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click OSPF to display the OSPF options.

).

The Add OSPF Area pop-up window appears.

Step 8 Click Interfaces.

The Interfaces tab appears.

).

The Add OSPF Area Interface pop-up window appears.

Step 10 Take any of the actions as described in Adding OSPF Area Interfaces.

).

Step 12 In the IP address field, type an IP address for the neighbor receiving hello messages on non-broadcast networks from this interface.

Step 13 Select the Eligible check box to indicate that the neighbor is eligible to receive messages.

Step 14 Click OK.

The neighbor is added.

Step 15 Click OK.

The OSPF area interface is added.

Step 16 Click Save.

The OSPF area is saved.

Step 17 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding OSPF Area Vlinks

License: Control

Supported Devices: Series 3

All areas in an OSPF autonomous system must be physically connected to the backbone area. In some cases where this physical connection is not possible, you can use a vlink to connect to the backbone through a non-backbone area. Vlinks can also be used to connect two parts of a partitioned backbone through a non-backbone area.

You must add a minimum of two OSPF areas before you can add a vlink.

To add an OSPF area vlink:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click OSPF to display the OSPF options.

).

The Add OSPF Area pop-up window appears.

Step 8 Click Vlinks.

The Vlinks tab appears.

).

The Add OSPF Area Vlink pop-up window appears.

Step 10 In the Router ID field, type an IP address for the router.

Step 11 From the Authentication drop-down list, select the authentication profile the vlink will use.

Step 12 In the Hello Interval field, type the interval, in seconds, between sending of hello messages.

Step 13 In the Retrans Interval field, type the interval, in seconds, between retransmissions of unacknowledged updates.

Step 14 In the Wait Time field, type the number of seconds that the router waits between starting election and building adjacency.

Step 15 In the Dead Interval field, type the number of seconds that the router waits before declaring a neighbor down when not receiving messages from it. If this value is defined, it overrides the value calculated from dead count.

Step 16 In the Dead Count field, type a numerical value that when multiplied by the hello interval, specifies the number of seconds that the router waits before declaring a neighbor down when not receiving messages from it.

Step 17 Click OK.

The OSPF area vlink is added.

Step 18 Click Save.

The OSPF area is saved.

Step 19 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Import Filters for OSPF Configuration

License: Control

Supported Devices: Series 3

You can add an import filter to define which routes are accepted or rejected from OSPF into the route table. Import filters are applied in the order they appear in the table.

When adding an import filter, you use one of the filters you configured on the virtual router. For more information about configuring filters, see Setting Up Virtual Router Filters.

To add an import filter for OSPF configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click OSPF to display the OSPF options.

).

The Add Import Filter pop-up window appears.

Step 8 From the Name drop-down list, select the filter you want to add as an import filter.

Step 9 Next to Action, select Accept or Reject.

Step 10 Click OK.

The import filter is added.

Step 11 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Export Filters for OSPF Configuration

License: Control

Supported Devices: Series 3

You can add an export filter to define which routes will be accepted or rejected from the route table to OSPF. Export filters are applied in the order they appear in the table.

When adding an export filter, you use one of the filters you configured on the virtual router. For more information about configuring filters, see Setting Up Virtual Router Filters.

To add an export filter for OSPF configuration:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Dynamic Routing to display the dynamic routing options.

Step 6 Click OSPF to display the OSPF options.

).

The Add an Export Filter pop-up window appears.

Step 8 From the Name drop-down list, select the filter you want to add as an export filter.

Step 9 Next to Action, select Accept or Reject.

Step 10 Click OK.

The export filter is added.

Step 11 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up Virtual Router Filters

License: Control

Supported Devices: Series 3

Filters provide a way to match routes for importing into the virtual router’s route table and for exporting routes to dynamic protocols. You can create and manage a list of filters. Each filter defines specific criteria to look for in routes that are defined statically or received from a dynamic protocol.

Table 7-3 Virtual Router Filters Table View Fields

Field

Description

Name

The name of the filter.

Protocol

The protocol that the route originates from:

- Static — The route originates as a local static route.

- RIP — The route originates from a dynamic RIP configuration.

- OSPF — The route originates from a dynamic OSPF configuration.

From Router

The router IP addresses that this filter attempts to match in a router. You must enter this value for static and RIP filters.

Next Hop

The next hop where packets using this route are forwarded. You must enter this value for static and RIP filters.

Destination Type

The type of destination where packets are sent:

- Router

- Device

- Discard

Destination Network

The networks that this filter attempts to match in a route.

OSPF Path Type

Applies only to OSPF protocol. The path type can be one of the following:

- Ext-1

- Ext-2

- Inter Area

- Intra Area

OSPF Router ID

Applies only to OSPF protocol. The router ID of the router advertising that route/network.

To add a virtual router filter:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Filter to display the Filter options.

Step 6 Click Add Filter.

The Create Filter pop-up window appears.

Step 7 In the Name field, type a name for the filter. You can use alphanumeric characters only.

Step 8 Under Protocol, select All or select the protocol that applies to the filter.

Step 9 If you selected All, Static, or RIP as the Protocol, under From Router, type the router IP addresses that this filter will attempt to match in a route.

Note that you can also enter a /32 CIDR block for IPv4 addresses and a /128 prefix length for IPv6 addresses. All other address blocks are invalid for this field.

Step 10 Click Add.

The From Router field is populated.

Step 11 If you selected All, Static, or RIP as the Protocol, under Next Hop, type the IP addresses for the gateways that this filter will attempt to match in a route.

Note that you can also enter a /32 CIDR block for IPv4 addresses and a /128 prefix length for IPv6 addresses. All other address blocks are invalid for this field.

Step 12 Click Add.

The Next Hop field is populated.

Step 13 Under Destination Type, select the options that apply to the filter.

Step 14 Under Destination Network, type the IP address of the network that this filter will attempt to match in a route.

Step 15 Click Add.

The Destination Network field is populated.

Step 16 If you selected All or OSPF as the Protocol, under Path Type, select the options that apply to the filter.

You must select at least one path type.

Step 17 If you selected OSPF as the Protocol, under Router ID, type the IP address that serves as the router ID of the router advertising the route/network.

Step 18 Click Add.

The Router ID field is populated.

Step 19 Click OK.

The filter is added.

Step 20 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Virtual Router Authentication Profiles

License: Control

Supported Devices: Series 3

You can set up Authentication Profiles for use in RIP and OSPF configurations. You can configure a simple password or specify a shared cryptographic key. Simple passwords allow for every packet to carry eight bytes of the password. The system ignores received packets lacking this password. Cryptographic keys allow for validation, a 16-byte long digest generated from a password to be appended to every packet.

Note that for OSPF, each area can have a different authentication method. Therefore, you create authentication profiles that can be shared among many areas. You cannot add authentication for OSPFv3.

To add a virtual router authentication profile:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Edit Virtual Router pop-up window appears.

Step 5 Click Authentication Profile.

The Authentication Profile tab appears.

Step 6 Click Add Authentication Profile.

The Add Authentication Profile pop-up window appears.

Step 7 In the Authentication Profile Name field, type a name for the authentication profile.

Step 8 From the Authentication Type drop down list, select simple or cryptographic.

Step 9 In the Password field, type a secure password.

Step 10 In the Confirm Password field, type the password again to confirm it.

Step 11 Click OK.

The authentication profile is added.

Step 12 Click Save.

Your changes are saved. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Viewing Virtual Router Statistics

License: Control

Supported Devices: Series 3

You can view runtime statistics for each virtual router. The statistics display unicast packets, packets dropped, and separate routing tables for IPv4 and IPv6 addresses.

To view virtual router statistics:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

The Statistics pop-up window appears.

Step 5 Click OK to close the window.

Deleting Virtual Routers

License: Control

Supported Devices: Series 3

When you delete a virtual router, any routed interfaces assigned to the router become available for inclusion in another router.

To delete a virtual router:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Virtual Routers.

The Virtual Routers tab appears.

).

Step 5 When prompted, confirm that you want to delete the virtual router.

The virtual router is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up Aggregate Interfaces

You can group multiple physical Ethernet interfaces into a single logical link on Series 3 managed devices configured in either a Layer 2 deployment that provides packet switching between networks, or a Layer 3 deployment that routes traffic between interfaces. This single aggregate logical link provides higher bandwidth, redundancy, and load-balancing between two endpoints.

You create aggregate links by creating a switched or routed link aggregation group, or LAG. When you create an aggregation group, a logical interface called an aggregate interface is created. To an upper layer entity a LAG looks like a single logical link and data traffic is transmitted through the aggregate interface. The aggregate link provides increased bandwidth by adding the bandwidth of multiple links together. It also provides redundancy by load-balancing traffic across all available links. If one link fails, the system automatically load-balances traffic across all remaining links.

The endpoints in a LAG can be two FirePOWER managed devices, as shown in the illustration above, or a FirePOWER managed device connected to a third-party access switch or router. The two devices do not have to match, but they must have the same physical configuration and they must support the IEEE 802.ad link aggregation standard. A typical deployment for a LAG might be to aggregate access links between two managed devices, or to create a point-to-point connection between a managed device and an access switch or a router.

Note that you cannot configure aggregate interfaces on a virtual managed device, a Cisco ASA with FirePOWER Services device, or a Cisco NGIPS for Blue Coat X-Series device.

For more information about setting up aggregate interfaces, see Configuring LAGs.

Configuring LAGs

License: Control

Supported Devices: Series 3

There are two types of aggregate interfaces: switched, which are Layer 2 aggregate interfaces, and routed, which are Layer 3 aggregate interfaces. You implement link aggregation through the use of link aggregation groups (LAGs). You configure a LAG by creating an aggregate switched or routed interface and then associating a set of physical interfaces with the link. All of the physical interfaces must be of the same speed and medium.

You create aggregate links either dynamically or statically. Dynamic link aggregation uses Link Aggregation Control Protocol (LACP), a component of the IEEE 802.ad link aggregation standard, while static link aggregation does not. LACP enables each device on either end of the LAG to exchange link and system information to determine which links will be actively used in the aggregation. A static LAG configuration requires you to manually maintain link aggregations and apply load-balancing and link selection policies.

When you create a switched or routed aggregate interface, a link aggregation group of the same type is created and numbered automatically. For example, when you create your first LAG (switched or routed), the aggregate interface can be identified by the lag0 label in the Interfaces tab for your managed device. When you associate physical and logical interfaces with this LAG, they appear nested below the primary LAG in a hierarchical tree menu. Note that a switched LAG can only contain switched physical interfaces, and a routed LAG can only contain routed physical interfaces.

Consider the following requirements when you configure a LAG:

- The FireSIGHT system supports a maximum of 14 LAGs, and assigns a unique ID to each LAG interface in the range of 0 to 13. The LAG ID is not configurable.

- You must configure the LAG on both sides of the link, and you must set the interfaces on either side of the link to the same speed.

- You must associate at least two physical interfaces per LAG, up to a maximum of eight. A physical interface cannot belong to more than one LAG.

- Physical interfaces in a LAG cannot be used in any other mode of operation, either as inline or passive, or be used as part of another logical interface for tagged traffic.

- Physical interfaces in a LAG can span multiple NetMods, but cannot span multiple sensors (i.e. all physical interfaces must reside on the same device).

- A LAG cannot contain a stacking NetMod.

Note Link aggregation is not supported on device clusters.

See the following sections for more information:

- Specifying a Load-Balancing Algorithm

- Specifying a Link Selection Policy

- Configuring LACP

- Adding Aggregate Switched Interfaces

- Adding Aggregate Routed Interfaces

- Adding Logical Aggregate Interfaces

- Viewing Aggregate Interface Statistics

- Deleting Aggregate Interfaces

Specifying a Load-Balancing Algorithm

License: Control

Supported Devices: Series 3

You assign an egress load-balancing algorithm to the LAG that determines how to distribute traffic to the LAG bundle’s member links. The load-balancing algorithm makes hashing decisions based on values in various packet fields, such as Layer 2 MAC addresses, Layer 3 IP addresses, and Layer 4 port numbers (TCP/UDP traffic). The load-balancing algorithm you select applies to all of the LAG bundle’s member links.

Select the load-balancing algorithm that supports your deployment scenario from the following options when you configure a LAG:

- Destination IP

- Destination MAC

- Destination Port

- Source IP

- Source MAC

- Source Port

- Source and Destination IP

- Source and Destination MAC

- Source and Destination Port

Note You should configure both ends of the LAG to have the same load-balancing algorithm. Higher layer algorithms will back off to lower layer algorithms as necessary (such as a Layer 4 algorithm backing off to Layer 3 for ICMP traffic).

Specifying a Link Selection Policy

License: Control

Supported Devices: Series 3

Link aggregation requires the speed and medium of each link to be the same at both endpoints. Because link properties can change dynamically, the link selection policy helps determine how the system manages the link selection process. A link selection policy that maximizes the highest port count supports link redundancy, while a link selection policy that maximizes total bandwidth supports overall link speed. A stable link selection policy attempts to minimize excessive changes in link states.

Note You should configure both ends of the LAG to have the same link selection policy.

Select the link selection policy that supports your deployment scenario from the following options when you configure a LAG:

- Highest Port Count — select this option for the highest total active port count to provide added redundancy.

- Highest Total Bandwidth — select this option to provide the highest total bandwidth for the aggregated link.

- Stable — select this option if your primary concern is link stability and reliability. Once you configure a LAG, the active links change only when absolutely necessary (such as link failure) rather than doing so for added port count or bandwidth.

- LACP Priority — select this option to use the LACP algorithm to determine which links are active in the LAG. This setting is appropriate if you have undefined deployment goals, or if the device at the other end of the LAG is a non-FirePOWER device.

When LACP is enabled, a link selection policy based on LACP priority uses two properties of LACP, the system priority and link priority, which are described as follows:

– LACP system priority. You configure this value on each partnered device running LACP to determine which one is superior in link aggregation. The system with the lower value has the higher system priority. In dynamic link aggregation, the system with the higher LACP system priority sets the selected state of member links on its side first, then the system with the lower priority sets its member links accordingly. You can specify 0 to 65535. If you do not specify a value, the default priority is 32768.

– LACP link priority. You configure this value on each link belonging to the aggregation group. The link priority determines the active and standby links in the LAG. Links with lower values have higher priority. If an active link goes down, the standby link with the highest priority is selected to replace the downed link. However, if two or more links have the same LACP link priority, the link with the lowest physical port number is selected as the standby link. You can specify 0 to 65535. If you do not specify a value, the default priority is 32768.

LACP is a key aspect of automating the link selection method that supports dynamic link aggregation. For more information, see Configuring LACP.

Configuring LACP

License: Control

Supported Devices: Series 3

Link Aggregation Control Protocol (LACP), a component of IEEE 802.3ad, is a method of exchanging system and port information to create and maintain LAG bundles. When you enable LACP, each device on either end of the LAG uses LACP to determine which links will be actively used in the aggregation. LACP provides availability and redundancy by exchanging LACP packets (or control messages) between links. It learns the capabilities of the links dynamically and informs the other links. Once LACP identifies correctly matched links, it facilitates grouping the links into the LAG. If a link fails, traffic continues on the remaining links. LACP must be enabled at both ends of the LAG for the link to be operational.

When you enable LACP, you need to select a transmission mode for each end of the LAG that determines how LACP packets are exchanged between partnered devices. There are two options for LACP mode:

- Active — select this mode to place a device into an active negotiating state, in which the device initiates negotiations with remote links by sending LACP packets.

- Passive — select this mode to place a device into a passive negotiating state, in which the device responds to LACP packets it receives but does not initiate LACP negotiation.

Note Both modes allow LACP to negotiate between links to determine if they can form a link bundle based on criteria such as port speed. However, you should avoid a passive-passive configuration, which essentially places both ends of the LAG in listening mode.

LACP has a timer which defines how often LACP packets are sent between devices. LACP exchanges packets at these rates:

- Slow — 30 seconds

- Fast — 1 second

The device where this option is applied expects to receive LACP packets with this frequency from the partner device on the other side of the LAG.

Note When a LAG is configured on a managed device that is part of a device stack, only the primary device participates in LACP communication with the partner system. All secondary devices forward LACP messages to the primary device. The primary device relays any dynamic LAG modifications to the secondary devices.

Adding Aggregate Switched Interfaces

License: Control

Supported Devices: Series 3

You can combine between two and eight physical ports on a managed device to create a switched LAG interface. You must assign a switched LAG interface to a virtual switch before it can handle traffic. A managed device can support up to 14 LAG interfaces.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To configure a switched LAG interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 From the Add drop-down menu, select Add Aggregate Interface.

Step 4 Click Switched to display the switched LAG interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 From the Virtual Switch drop-down list, you must select an existing virtual switch or select New to add a new virtual switch.

Note If you add a new virtual switch, you must configure it on the Virtual Switches tab of the Device Management page (Devices > Device Management > Virtual Switches) after you set up the switched interface. See Adding Virtual Switches.

Step 7 Select the Enabled check box to allow the switched LAG interface to handle traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the interface is configured to auto negotiate speed and duplex settings. Note that mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options. When links auto negotiate speed, all active links are selected for the LAG based on the same speed setting.

Step 9 From the MDI/MDIX drop-down list, select an option to designate whether the interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Under Link Aggregation, you have two options for selecting physical interfaces to add to the LAG bundle:

- Next to Available Interfaces , select one or more interfaces, then click the add selected icon (

). Use Ctrl or Shift to select multiple physical interfaces.

- To add all interface pairs to the LAG bundle, click the add all icon (

).

Step 12 From the Load-Balancing Algorithm drop-down list, select the option that supports your deployment scenario. See Specifying a Load-Balancing Algorithm for more information.

Step 13 From the Link Selection Policy drop-down list, select the option that supports your deployment scenario: Highest Port Count (redundancy), Highest Total Bandwidth (speed), Stable (no excessive change in maintain link state), or LACP Priority (automatic link aggregation).

If you select LACP Priority, you need to assign a value for System Priority. You then need to click the Configure Interface Priority link to assign a priority value for each interface in the LAG. You can specify 0 to 65535. If you do not specify a value, the default priority is 32768. See Specifying a Link Selection Policy for more information.

Note Select LACP Priority when you configure an aggregate interface between a FireSIGHT System device and a third-party network device.

Step 14 From the Tunnel Level drop-down list, select the option that supports your deployment scenario, either Inner or Outer.

Note that the tunnel level only applies to IPv4 traffic when Layer 3 load balancing is configured. The outer tunnel is always used for Layer 2 and IPv6 traffic. If the Tunnel Level is not explicitly set, the default is Outer.

Step 15 Under LACP, select the Enabled check box to allow the switched LAG interface to handle traffic using the Link Aggregation Control Protocol. See Configuring LACP for more information.

If you clear the check box, the LAG interface becomes a static configuration and the FireSIGHT System will use all of the physical interfaces selected for the aggregation.

Step 16 Select a Rate radio button to set the frequency that determines how often LACP control messages are received from the partner device.

- Select Slow to receive packets every 30 seconds.

- Select Fast to receive packets every 1 second.

Step 17 Select a Mode radio button to establish the listening mode of the device.

- Select Active to initiate negotiations with remote links by sending LACP packets to the partner device.

- Select Passive to respond to LACP packets received.

Step 18 Click Save.

The switched LAG interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices for more information.

Adding Aggregate Routed Interfaces

License: Control

Supported Devices: Series 3

You can combine between two and eight physical ports on a managed device to create a routed LAG interface. You must assign a routed LAG interface to a virtual router before it can route traffic. A managed device can support up to 14 LAG interfaces.

Caution Adding a routed interface pair on a Series 3 device restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

You can add static Address Resolution Protocol (ARP) entries to a routed LAG interface. If an external host needs to know the MAC address of the destination IP address it needs to send traffic to on your local network, it sends an ARP request. When you configure static ARP entries, the virtual router responds with an IP address and associated MAC address.

Note that disabling the ICMP Enable Responses option for routed LAG interfaces does not prevent ICMP responses in all scenarios. You can add rules to an access control policy to drop packets where the destination IP is the routed interface’s IP and the protocol is ICMP; see Controlling Traffic with Network-Based Rules.

If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets before they reach the host, thereby preventing any response. For more information about inspecting local router traffic, see Understanding Advanced Device Settings.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To configure a routed LAG interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 From the Add drop-down menu, select Add Aggregate Interface.

Step 4 Click Routed to display the routed LAG interface options.

Step 5 Optionally, from the Security Zone drop-down list, select an existing security zone or select New to add a new security zone.

Step 6 From the Virtual Router drop-down list, you must select an existing virtual router or select New to add a new virtual router.

Note If you add a new virtual router, you must configure it on the Virtual Routers tab of the Device Management page (Devices > Device Management > Virtual Routers) after you set up the routed interface. See Adding Virtual Routers.

Step 7 Select the Enabled check box to allow the routed LAG interface to handle traffic.

If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode drop-down list, select an option to designate the link mode or select Autonegotiation to specify that the LAG interface is configured to auto negotiate speed and duplex settings. Note that mode settings are available only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options. When links auto negotiate speed, all active links are selected for the LAG based on the same speed setting.

Step 9 From the MDI/MDIX drop-down list, select an option to designate whether the LAG interface is configured for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX. Note that MDI/MDIX settings are available only for copper interfaces.

Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX to attain link.

Step 10 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed. Note that the MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 11 Next to ICMP, select the Enable Responses check box to allow the LAG interface to respond to ICMP traffic such as pings and traceroute.

Step 12 Next to IPv6 NDP, select the Enable Router Advertisement check box to enable the LAG interface to broadcast router advertisements.

Step 13 To add an IP address, click Add.

The Add IP Address pop-up window appears.

Step 14 In the Address field, type the routed LAG interface’s IP address and subnet mask using CIDR notation. Note the following:

- You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF.

- You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 Optionally, if your organization uses IPv6 addresses, next to the IPv6 field, select the Address Autoconfiguration check box to set the IP address of the LAG interface automatically.

Step 16 For Type, select either Normal or SFRP.

For SFRP options, see Configuring SFRP for more information.

Step 17 Click OK.

The IP address is added.

).

Note When adding an IP address to a routed interface of a clustered device, you must add a corresponding IP address to the routed interface on the cluster peer.

Step 18 To add a static ARP entry, click Add.

The Add Static ARP Entry pop-up window appears.

Step 19 In the IP Address field, type an IP address for the static ARP entry.

Step 20 In the MAC Address field, type a MAC address to associate with the IP address. Enter the address using the standard format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).

Step 21 Click OK.

The static ARP entry is added.

Step 22 Under Link Aggregation, you have two options for selecting physical interfaces to add to the LAG bundle:

- Next to Available Interfaces , select one or more interfaces, then click the add selected icon (

). Use Ctrl or Shift to select multiple physical interfaces.

- To add all interface pairs to the LAG bundle, click the add all icon (

).

Step 23 From the Load-Balancing Algorithm drop-down list, select the option that supports your deployment scenario. See Specifying a Load-Balancing Algorithm for more information.

Step 24 From the Link Selection Policy drop-down list, select the option that supports your deployment scenario: Highest Port Count (redundancy), Highest Total Bandwidth (speed), Stable (no excessive change in maintain link state), or LACP Priority (automatic link aggregation).

If you select LACP Priority, you need to assign a value for System Priority. You then need to click the Configure Interface Priority link to assign a priority value for each interface in the LAG. You can specify 0 to 65535. If you do not specify a value, the default priority is 32768. See Specifying a Link Selection Policy for more information.

Note Select LACP Priority when you configure an aggregate interface between a FireSIGHT System device and a third-party network device.

Step 25 From the Tunnel Level drop-down list, select the option that supports your deployment scenario, either Inner or Outer.

Note that the tunnel level only applies to IPv4 traffic when Layer 3 load balancing is configured. The outer tunnel is always used for Layer 2 and IPv6 traffic. If the Tunnel Level is not explicitly set, the default is Outer.

Step 26 Under LACP, select the Enabled check box to allow the switched LAG interface to handle traffic using the Link Aggregation Control Protocol. See Configuring LACP for more information.

If you clear the check box, the LAG interface becomes a static configuration and the FireSIGHT System will use all of the physical interfaces for the aggregation.

Step 27 Select a Rate radio button to set the frequency that determines how often LACP control messages are received from the partner device.

- Select Slow to receive packets every 30 seconds.

- Select Fast to receive packets every 1 second.

Step 28 Select a Mode radio button to establish the listening mode of the device.

- Select Active to initiate negotiations with remote links by sending LACP packets to the partner device.

- Select Passive to respond to LACP packets received.

Step 29 Click Save.

The routed LAG interface is configured. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Adding Logical Aggregate Interfaces

License: Control

Supported Devices: Series 3

For each switched or routed aggregate interface, you can add multiple logical interfaces. You must associate each logical LAG interface with a VLAN tag to handle traffic received by the LAG interface with that specific tag. You add logical interfaces to switched or routed aggregate interfaces in the same way you would add them to physical switched or routed interfaces.

Note When you create a LAG interface you also create an “untagged” logical interface by default, which is identified by the lagn.0 label, where n is an integer from 0 to 13. To be operational, each LAG requires this one logical interface at a minimum. You can associate additional logical interfaces with any LAG to handle VLAN-tagged traffic. Each additional logical interface requires a unique VLAN tag. The FireSIGHT system supports VLAN tags in the range of 1 through 4094.

You can also configure SFRP on a logical routed interface. See Configuring SFRP for more information.

Note that disabling the ICMP Enable Responses option for logical routed interfaces does not prevent ICMP responses in all scenarios. You can add rules to an access control policy to drop packets where the destination IP is the routed interface’s IP and the protocol is ICMP; see Controlling Traffic with Network-Based Rules.

If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets before they reach the host, thereby preventing any response. For more information about inspecting local router traffic, see Understanding Advanced Device Settings.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To add a logical LAG interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 From the Add drop-down menu, select Add Logical Interface.

The Add Interface pop-up window appears.

Step 4 Click Switched to display the switched interface options, or select Routed to display the routed interface options.

When you create a logical interface for a LAG, you select an available LAG from the Interface drop-down list. The aggregate interface is identified by the lagn label, where n is an integer from 0 to 13.

See Adding Logical Switched Interfaces for more information on adding a logical interface to a switched interface.

See Adding Logical Routed Interfaces for more information on adding a logical interface to a routed interface.

Note When an aggregate interface is disabled, the logical interface associated with the aggregate interface is also disabled.

Viewing Aggregate Interface Statistics

License: Control

Supported Devices: Series 3

You can view protocol and traffic statistics for each aggregate interface. The statistics show LACP protocol information such as LACP key and partner information, packets received, packets transmitter, and packets dropped. Statistics are further refined per member interface to show traffic and link information on a per-port basis.

Aggregate interface information is also presented to the dashboard via predefined dashboard widgets. The Current Interface Status widget shows the status of all interfaces on the appliance, enabled or unused. The Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s interfaces over the dashboard time range. See Understanding the Predefined Widgets.

To view aggregate interface statistics:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The Statistics pop-up window appears.

Step 4 Click OK to close the window.

Deleting Aggregate Interfaces

License: Control

Supported Devices: Series 3

The following procedure explains how to delete an aggregate interface.

To delete an aggregate interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

The aggregate interface can be identified by the lagn label, where n can be an integer from 0 to 13.

Step 4 When prompted, confirm that you want to delete the aggregate interface.

The interface is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Setting Up Hybrid Interfaces

You can configure logical hybrid interfaces on managed devices that allow the FireSIGHT System to bridge traffic between virtual routers and virtual switches. If IP traffic received on interfaces in a virtual switch is addressed to the MAC address of an associated hybrid logical interface, the system handles it as Layer 3 traffic and either routes or responds to the traffic depending on the destination IP address. If the system receives any other traffic, it handles it as Layer 2 traffic and switches it appropriately. You cannot configure logical hybrid interfaces on a virtual managed device or Cisco NGIPS for Blue Coat X-Series.

For more information about setting up hybrid interfaces, see Adding Logical Hybrid Interfaces.

Adding Logical Hybrid Interfaces

License: Control

Supported Devices: Series 3

You must associate a logical hybrid interface with a virtual router and virtual switch to bridge traffic between Layer 2 and Layer 3. You can only associate a single hybrid interface with a virtual switch. However, you can associate multiple hybrid interfaces with a virtual router.

You can also configure SFRP on a logical hybrid interface. See Configuring SFRP for more information.

Note that disabling the ICMP Enable Responses option for hybrid interfaces does not prevent ICMP responses in all scenarios. You can add rules to an access control policy to drop packets where the destination IP is the hybrid interface’s IP and the protocol is ICMP; see Controlling Traffic with Network-Based Rules.

If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets before they reach the host, thereby preventing any response. For more information about inspecting local router traffic, see Understanding Advanced Device Settings.

Caution Changing any (Series 2) or the highest (Series 3) MTU value for a sensing interface or inline set temporarily interrupts traffic inspection on all sensing interfaces on the device, not just the interface you changed, when you apply your changes. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and the interface type. See How Snort Restarts Affect Traffic.

) next to the interface.

To add a logical hybrid interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab appears.

Step 3 From the Add drop-down menu, select Add Logical Interface.

The Add Interface pop-up window appears.

Step 4 Click Hybrid to display the hybrid interface options.

Step 5 In the Name field, type a name for the interface. You can use alphanumeric characters and spaces.

Step 6 From the Virtual Router drop-down list, select an existing virtual router, select None, or select New to add a new virtual router.

Note that if you add a new virtual router, you must configure it on the Device Management page (Devices > Device Management> Virtual Routers) after you finish setting up the hybrid interface. See Adding Virtual Routers.

Step 7 From the Virtual Switch drop-down list, select an existing virtual switch, select None, or select New to add a new virtual switch.

Note that if you add a new virtual switch, you must configure it on the Device Management page (Devices > Device Management> Virtual Switches) after you finish setting up the hybrid interface. See Adding Virtual Switches.

Step 8 Select the Enabled check box to allow the hybrid interface to handle traffic.

If you clear the check box, the interface becomes disabled and administratively taken down.

Step 9 In the MTU field, type a maximum transmission unit (MTU), which designates the largest size packet allowed.

The range within which you can set the MTU can vary depending on the FireSIGHT System device model and the interface type. See MTU Ranges for Managed Devices for more information.

Step 10 Next to ICMP, select the Enable Responses check box to allow the interface to respond to ICMP traffic such as pings and traceroute.

Step 11 Next to IPv6 NDP, select the Enable Router Advertisement check box to enable the interface to broadcast router advertisements.

You can only select this option if you added IPv6 addresses.

Step 12 To add an IP address, click Add.

The Add IP Address pop-up window appears.

Step 13 In the Address field, type the IP address and subnet mask. Note the following:

- You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF.

- You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 14 Optionally if you have IPv6 addresses, next to the IPv6 field, select the Address Autoconfiguration check box to set the IP address of the interface automatically.

Step 15 For Type, select either Normal or SFRP.

For SFRP options, see Configuring SFRP for more information.

Step 16 Click OK.

The IP address is added.

Step 17 Click Save.

The logical hybrid interface is added. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Deleting Logical Hybrid Interfaces

License: Control

Supported Devices: Series 3

The following procedure explains how to delete a logical hybrid interface.

To delete a hybrid interface:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

).

Step 4 When prompted, confirm that you want to delete the interface.

The interface is deleted. Note that your changes do not take effect until you apply the device configuration; see Applying Changes to Devices.

Using Gateway VPNs

A virtual private network (VPN) is a network connection that establishes a secure tunnel between endpoints via a public source, such as the Internet or other network. You can configure the FireSIGHT System to build secure VPN tunnels between the virtual routers of Cisco managed devices. The system builds tunnels using the Internet Protocol Security (IPSec) protocol suite.

Only Cisco managed devices can be used as endpoints in Cisco VPN deployments. Third-party endpoints are not supported.

After the VPN connection is established, the hosts behind the local gateway can connect to the hosts behind the remote gateway through the secure VPN tunnel. A connection consists of the IP addresses and host names of the two gateways, the subnets behind them, and the shared secrets for the two gateways to authenticate to each other.

The VPN endpoints authenticate to each other with either the Internet Key Exchange (IKE) version 1 or version 2 protocol to create a security association for the tunnel. The system uses either the IPSec authentication header (AH) protocol or the IPSec encapsulating security payload (ESP) protocol to authenticate the data entering the tunnel. The ESP protocol encrypts the data as well as providing the same functionality as AH.

If you have access control policies in your deployment, the system does not send VPN traffic until it has passed through access control. In addition, the system does not send tunnel traffic to the public source when the tunnel is down.

To configure and apply VPN deployments, you must have a VPN license enabled on each of your target managed devices. Additionally, VPN features are only available on Series 3 devices.

See the following sections for more information on creating and managing VPN deployments:

- Understanding IPSec

- Understanding VPN Deployments

- Managing VPN Deployments

Understanding IPSec

The IPSec protocol suite defines how IP packets across a VPN tunnel are hashed, encrypted, and encapsulated in the ESP or AH security protocol. The FireSIGHT System uses the hash algorithm and encryption key of the Security Association (SA), which becomes established between the two gateways by the Internet Key Exchange (IKE) protocol.

Security associations (SA) establish shared security attributes between two devices and allow VPN endpoints to support secure communication. An SA allows two VPN endpoints to handle the parameters for how the VPN tunnel is secured between them.

The system uses the Internet Security Association and Key Management Protocol (ISAKMP) during the initial phase of negotiating the IPSec connection to establish the VPN between endpoints and the authenticated key exchange. The IKE protocol resides within ISAKMP. See Understanding IKE for more information about the IKE protocol.

The AH security protocol provides protection for packet headers and data, but it cannot encrypt them. ESP provides encryption and protection for packets, but it cannot secure the outermost IP header. In many cases, this protection is not required, and most VPN deployments use ESP more frequently than AH because of its encryption capabilities. Since VPN only operates in tunnel mode, the system encrypts and authenticates the entire packet from Layer 3 and up in the ESP protocol. ESP in tunnel mode encrypts the data as well as providing the latter’s encryption capabilities.

Understanding IKE

The FireSIGHT System uses the IKE protocol to mutually authenticate the two gateways against each other as well as to negotiate the SA for the tunnel. The process consists of two phases.

IKE phase 1 establishes a secure authenticated communication channel by using the Diffie-Hellman key exchange to generate a pre-shared key to encrypt further IKE communications. This negotiation results in a bidirectional ISAKMP security association. The system allows you to perform the authentication using a pre-shared key. Phase 1 operates in main mode, which seeks to protect all data during the negotiation, while also protecting the identity of the peers.

During IKE phase 2, the IKE peers use the secure channel established in phase 1 to negotiate security associations on behalf of IPSec. The negotiation results in a minimum of two unidirectional security associations, one inbound and one outbound.

Understanding VPN Deployments

A VPN deployment specifies the endpoints and networks that are included in a VPN and how they connect to each other. After you configure a VPN deployment, you can then apply it to your managed devices or devices managed by another Defense Center.

The system supports three types of VPN deployments: point-to-point, star, and mesh. See the following sections for more information about these VPN deployments:

- Understanding Point-to-Point VPN Deployments

- Understanding Star VPN Deployments

- Understanding Mesh VPN Deployments

Understanding Point-to-Point VPN Deployments

In a point-to-point VPN deployment, two endpoints communicate directly with each other. You configure the two endpoints as peer devices, and either device can initiate the secured connection. Each of the devices in this configuration must be a VPN-enabled managed device.

The following diagram displays a typical point-to-point VPN deployment.

See Configuring Point-to-Point VPN Deployments for more information.

Understanding Star VPN Deployments

In a star VPN deployment, a central endpoint (hub node) establishes a secure connection with multiple remote endpoints (leaf nodes). Each connection between the hub node and an individual leaf node is a separate VPN tunnel. The hosts behind any of the leaf nodes can communicate with each other through the hub node.

Star deployments commonly represent a VPN that connects an organization’s main and branch office locations using secure connections over the Internet or other third-party network. Star VPN deployments provide all employees with controlled access to the organization’s network.

In a typical star deployment, the hub node is located at the main office. Leaf nodes are located at branch offices and initiate most of the traffic. Each of the nodes must be a VPN-enabled managed device.

Note that star deployments only support IKE version 2.

The following diagram displays a typical star VPN deployment.

See Configuring Star VPN Deployments for more information.

Understanding Mesh VPN Deployments

In a mesh VPN deployment, all endpoints can communicate with every other endpoint by means of an individual VPN tunnel. The mesh deployment offers redundancy so that when one endpoint fails, the remaining endpoints can still communicate with each other. This type of deployment commonly represents a VPN that connects a group of decentralized branch office locations. The number of VPN-enabled managed devices you deploy in this configuration depends on the level of redundancy you require. Each of the endpoints must be a VPN-enabled managed device.

See Configuring Mesh VPN Deployments for more information.

Managing VPN Deployments

License: VPN

Supported Devices: Series 3

On the VPN page (Devices > VPN) you can view all of your current VPN deployments by name and the endpoints contained in the deployment. Options on this page allow you to view the status of a VPN deployment, create a new deployment, apply a deployment, and edit or delete a deployment.

Caution If you select the default access control policy when registering a device to your Defense Center, the default access control rule blocks all traffic. If you configure a VPN deployment on the device, the deployment fails.

Note that when you register a device to a Defense Center, applied VPN deployments sync to the Defense Center during registration.

The following table describes the actions you can take to manage your deployments on the VPN page.

Configuring VPN Deployments

Applying a VPN Deployment

Table 10-1 VPN Deployment Management Actions

To...

You can...

create a new VPN deployment

click Add. See Configuring VPN Deployments for more information.

modify the settings in an existing VPN deployment

). See for more information.

view the status of an existing VPN deployment

click the status icon. See Viewing VPN Deployment Status for more information.

apply a VPN deployment to all devices targeted in the deployment

). See for more information.

delete a VPN deployment

if you decide not to delete the deployment.

Configuring VPN Deployments

License: VPN

Supported Devices: Series 3

When you create a new VPN deployment you must, at minimum, give it a unique name, specify a deployment type, and designate a pre-shared key. You can select from three types of deployment, each containing a group of VPN tunnels:

- Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.

- Star deployments establish a group of VPN tunnels connecting a hub endpoint to a group of leaf endpoints.

- Mesh deployments establish a group of VPN tunnels among a set of endpoints.

Only Cisco managed devices can be used as endpoints in Cisco VPN deployments. Third-party endpoints are not supported.

You must define a pre-shared key for VPN authentication. You can specify a default key to use in all of the VPN connections you generate in a deployment. For point-to-point deployments, you can specify a pre-shared key for each endpoint pair.

See the following sections for more information on creating each type of VPN deployment:

- Configuring Point-to-Point VPN Deployments

- Configuring Star VPN Deployments

- Configuring Mesh VPN Deployments

Configuring Point-to-Point VPN Deployments

License: VPN

Supported Devices: Series 3

When configuring a point-to-point VPN deployment, you define a group of endpoint pairs and then create a VPN between the two nodes in each pair. For more information, see Understanding Point-to-Point VPN Deployments.

The following list describes the options you can specify in your deployment.

Name

Give the deployment a unique name.

Type

Click PTP to specify that you are configuring a point-to-point deployment.

Pre-shared Key

Define a unique pre-shared key for authentication. The system uses this key for all the VPNs in your deployment, unless you specify a pre-shared key for each endpoint pair.

Device

You can select a managed device, including a device stack or cluster, as an endpoint for your deployment. For Cisco managed devices not managed by the Defense Center you are using, select Other and then specify an IP address for the endpoint.

Virtual Router

If you selected a managed device as your endpoint, select a virtual router that is currently applied to the selected device. You cannot select the same virtual router for more than one endpoint.

Interface

If you selected a managed device as your endpoint, select a routed interface that is assigned to the selected virtual router.

IP Address

– If you selected a managed device as an endpoint, select an IP address that is assigned to the selected routed interface.

– If the managed device is a device cluster, you can only select from a list SFRP IP addresses.

– If you selected a managed device not managed by the Defense Center, specify an IP address for the endpoint.

Protected Networks

Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each network. IKE version 1 only supports a single protected network.

Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6 entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4 or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128 CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.

Internal IP

Select the check box if the endpoint resides behind a firewall with network address translation.

Public IP

If you selected Internal IP, specify a public IP address for the firewall. If the endpoint is a responder, you must specify this value.

Public IKE Port

If you selected Internal IP, specify a single numerical value from 1 to 65535 for the UDP port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.

Use Deployment Key

Select the check box to use the pre-shared key defined for the deployment. Clear the check box to specify a pre-shared key for VPN authentication for this endpoint pair.

Pre-shared Key

If you cleared the Use Deployment Key check box, specify a pre-shared key in this field.

To configure a point-to-point VPN deployment:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears.

Step 2 Click Add.

The Create New VPN Deployment pop-up window appears.

Step 3 Give the deployment a unique Name.

You can use all printable characters, including spaces and special characters.

Step 4 Ensure that PTP is selected as the Type.

Step 5 Give the deployment a unique Pre-shared Key.

).

The Add New Endpoint Pair pop-up window appears.

Step 7 Configure the VPN deployment, as described earlier in this section.

).

The Add Network pop-up window appears.

Step 9 Type a CIDR block for the protected network.

Step 10 Click OK.

The protected network is added.

Step 11 Repeat step 8 through step 10 for Node B.

Step 12 Click Save.

The endpoint pair is added to your deployment and the Create New VPN Deployment pop-up window appears again.

Step 13 Click Save to finish configuring your deployment and the VPN page appears again.

Note that you must apply the deployment for it to take effect; see Applying a VPN Deployment.

Configuring Star VPN Deployments

License: VPN

Supported Devices: Series 3

When configuring a star VPN deployment, you define a single hub node endpoint and a group of leaf node endpoints. You must define the hub node endpoint and at least one leaf node endpoint to configure the deployment. For more information, see Understanding Star VPN Deployments.

The following list describes the options you can specify in your deployment.

Name

Give the deployment a unique name.

Type

Click Star to specify that you are configuring a star deployment.

Pre-shared Key

Define a unique pre-shared key for authentication.

Device

You can select a managed device, including a device stack or cluster, as an endpoint for your deployment. For Cisco managed devices not managed by the Defense Center you are using, select Other and then specify an IP address for the endpoint.

Virtual Router

If you selected a managed device as your endpoint, select a virtual router that is currently applied to the selected device. You cannot select the same virtual router for more than one endpoint.

Interface

If you selected a managed device as your endpoint, select a routed interface that is assigned to the selected virtual router.

IP Address

– If you selected a managed device as an endpoint, select an IP address that is assigned to the selected routed interface.

– If the managed device is a device cluster, you can only select from a list SFRP IP addresses.

– If you selected a managed device not managed by the Defense Center, specify an IP address for the endpoint.

Protected Networks

Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each network.

Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6 entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4 or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128 CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.

Internal IP

Select the check box if the endpoint resides behind a firewall with network address translation.

Public IP

If you selected Internal IP, specify a public IP address for the firewall. If the endpoint is a responder, you must specify this value.

Public IKE Port

If you selected Internal IP, specify a single numerical value from 1 to 65535 for the UDP port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.

To configure a star deployment:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears

Step 2 Click Add.

The Create New VPN Deployment pop-up window appears.

Step 3 Give the deployment a unique Name.

You can use all printable characters, including spaces and special characters.

Step 4 Click Star to specify the Type.

Step 5 Give the deployment a unique Pre-shared Key.

).

The Add Hub Node pop-up window appears.

Step 7 Configure the VPN deployment, as described earlier in this section.

).

The Add Network pop-up window appears.

Step 9 Type an IP address for the protected network.

Step 10 Click OK.

The protected network is added.

Step 11 Click Save.

The hub node is added to your deployment and the Create New VPN Deployment pop-up window appears again.

).

The Add Leaf Node pop-up window appears.

Step 13 Repeat step 7 through step 10 to complete the leaf node, which has the same options as the hub node.

Step 14 Click Save.

The leaf node is added to your deployment and the Create New VPN Deployment pop-up window appears again.

Step 15 Click Save to finish configuring your deployment and the VPN page appears again.

Note that you must apply the deployment for it to take effect; see Applying a VPN Deployment.

Configuring Mesh VPN Deployments

License: VPN

Supported Devices: Series 3

When configuring a mesh VPN deployment, you define a group of VPNs to link any two points for a given set of endpoints. For more information, see Understanding Mesh VPN Deployments.

The following list describes the options you can specify in your deployment.

Name

Give the deployment a unique name.

Type

Click Mesh to specify that you are configuring a mesh deployment.

Pre-shared Key

Define a unique pre-shared key for authentication.

Device

You can select a managed device, including a device stack or cluster, as an endpoint for your deployment. For Cisco managed devices not managed by the Defense Center you are using, select Other and then specify an IP address for the endpoint.

Virtual Router

If you selected a managed device as your endpoint, select a virtual router that is currently applied to the selected device. You cannot select the same virtual router for more than one endpoint.

Interface

If you selected a managed device as your endpoint, select a routed interface that is assigned to the selected virtual router.

IP Address

– If you selected a managed device as an endpoint, select an IP address that is assigned to the selected routed interface.

– If the managed device is a device cluster, you can only select from a list SFRP IP addresses.

– If you selected a managed device not managed by the Defense Center, specify an IP address for the endpoint.

Protected Networks

Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each network. IKE version 1 only supports a single protected network.

Note that VPN endpoints cannot have the same IP address and that protected networks in a VPN endpoint pair cannot overlap. If a list of protected networks for an endpoint contains one or more IPv4 or IPv6 entry, the other endpoint's protected network must have at least one entry of the same type (i.e., IPv4 or IPv6). If it does not, then the other endpoint's IP address must be of the same type and must not overlap with the entries in the protected network. (Use /32 CIDR address blocks for IPv4 and /128 CIDR address blocks for IPv6). If both of these checks fail, the endpoint pair is invalid.

Internal IP

Select the check box if the endpoint resides behind a firewall with network address translation.

Public IP

If you selected Internal IP, specify a public IP address for the firewall. If the endpoint is a responder, you must specify this value.

Public IKE Port

If you selected Internal IP, specify a single numerical value from 1 to 65535 for the UDP port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.

To configure a mesh VPN deployment:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears

Step 2 Click Add.

The Create New VPN Deployment pop-up window appears.

Step 3 Give the deployment a unique Name.

You can use all printable characters, including spaces and special characters.

Step 4 Click Mesh to specify the Type.

Step 5 Give the deployment a unique Pre-shared Key.

).

The Add Endpoint pop-up window appears.

Step 7 Configure the VPN deployment, as described earlier in this section.

).

The Add Network pop-up window appears.

Step 9 Type a CIDR block for the protected network.

Step 10 Click OK.

The protected network is added.

Step 11 Click Save.

The endpoint is added to your deployment and the Create New VPN Deployment pop-up window appears again.

Step 12 Repeat step 6 through step 11 to add more endpoints.

Step 13 Click Save to complete your deployment and the VPN page appears again.

Note that you must apply the deployment for it to take effect; see Applying a VPN Deployment.

Configuring Advanced VPN Deployment Settings

License: VPN

Supported Devices: Series 3

VPN deployments contain some common settings that can be shared among the VPNs in a deployment. Each VPN can use the default settings or you can override the default settings. Advanced settings typically require little or no modification and are not common to every deployment.

The following list describes the advanced options you can specify in your deployment.

Other Algorithm Allowed

Select the check box to enable auto negotiation to an algorithm not listed in the Algorithm list, but proposed by the remote peer.

Algorithm

Specify the phase one and phase two algorithm proposals to secure data in your deployment. Select Cipher, Hash, and Diffie-Hellman (DH) group authentication messages for both phases.

IKE Life Time

Specify a numerical value and select a time unit for the maximum IKE SA renegotiation interval. You can specify a minimum of 15 minutes and a maximum of 30 days.

IKE v2

Select the check box to specify that the system uses IKE version 2. This version supports the star deployment and multiple protected networks.

Life Time

Specify a numerical value and select a time unit for the maximum SA renegotiation interval. You can specify a minimum of 5 minutes and a maximum of 24 hours.

Life Packets

Specify the number of packets that can be transmitted over an IPsec SA before it expires. You can use any integer between 0 and 18446744073709551615.

Life Bytes

Specify the number of bytes that can be transmitted over an IPsec SA before it expires. You can use any integer between 0 and 18446744073709551615.

AH

Select the check box to specify that the system uses the authentication header security protocol for the data to be protected. Clear the check box to use encryption service payload (ESP) protocol. See Understanding IPSec for guidance on when to use each protocol.

To configure advanced VPN deployment settings:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears.

Step 2 Click Add.

The Create New VPN Deployment pop-up window appears.

Step 3 Click the Advanced tab.

Step 4 Configure the advanced settings, as described earlier in this section.

).

The Add IKE Algorithm Proposal pop-up window appears.

Step 6 Select Cipher, Hash, and Diffie-Hellman (DH) group authentication messages for both phases.

Step 7 Click OK.

The IKE algorithm proposal is added.

Step 8 Click Save.

Your changes are saved and the VPN page appears.

Note that you must apply the deployment for it to take effect; see Applying a VPN Deployment.

Applying a VPN Deployment

License: VPN

Supported Devices: Series 3

After configuring or making any changes to a VPN deployment, you must apply the deployment to one or more devices to implement the settings you designated for the deployment.

Caution Adding or removing a VPN on a Series 3 device restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To apply a VPN deployment:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears.

) next to the VPN deployment that you want to apply.

Step 3 When prompted, click Yes.

The VPN deployment is applied.

Tip Optionally, from the Apply VPN deployment dialog box, click View Changes. The VPN Comparison View page appears in a new browser window. For more information, see Using the VPN Deployment Comparison View.

Step 4 Click OK.

You are returned to the VPN page.

Viewing VPN Deployment Status

License: VPN

Supported Devices: Series 3

After you configure a VPN deployment, you can view the status of your configured VPN tunnels. The VPN page displays a status icon for each applied VPN deployment:

- The (

) icon designates that all VPN endpoints are up.

- The (

) icon designates that all VPN endpoints are down.

- The (

) icon designates that some endpoints are up, while others are down.

You can click a status icon to view the deployment status along with basic information about the endpoints in the deployment, such as endpoint name and IP address. The VPN status updates every minute or when a status change occurs, such as an endpoint going down or coming up.

To view VPN status:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears.

Step 2 Click the VPN status icon next to the deployment where you want to view the status.

The VPN Status pop-up window appears.

Step 3 Click OK to return to the VPN page.

Viewing VPN Statistics and Logs

License: VPN

Supported Devices: Series 3

After you configure a VPN deployment, you can view statistics about the data traversing your configured VPN tunnels. In addition, you can view the latest VPN system and IKE logs for each endpoint.

The system displays the following statistics.

Endpoint

The device path to the routed interface and IP address designated as the VPN endpoint.

Status

Whether the VPN connection is up or down.

Protocol

The protocol used for encryption, either ESP or AH.

Packets Received

The number of packets per interface the VPN tunnel receives during an IPsec SA negotiation.

Packets Forwarded

The number of packets per interface the VPN tunnel transmits during an IPsec SA negotiation.

Bytes Received

The number of bytes per interface the VPN tunnel receives during an IPsec SA negotiation.

Bytes Forwarded

The number of bytes per interface the VPN tunnel transmits during an IPsec SA negotiation.

Time Created

The date and time the VPN connection was created.

Time Last Used

The last time a user initiated a VPN connection.

NAT Traversal

If Yes is displayed, at least one of the VPN endpoints resides behind a device with network address translation.

IKE State

The state of the IKE SA: connecting, established, deleting, or destroying.

IKE Event

The IKE SA event: reauthentication or rekeying.

IKE Event Time

The time in seconds the next event should occur.

IKE Algorithm

The IKE algorithm being used by the VPN deployment.

IPSec State

The state of the IPSec SA: installing, installed, updating, rekeying, deleting, and destroying.

IPSec Event

Notification of when the IPSec SA event is rekeying.

IPSec Event Time

The time in seconds until the next event should occur.

IPSec Algorithm

IPSec algorithm being used by the VPN deployment.

To view VPN statistics:

Access: Admin/Network Admin

Step 1 Select Devices > VPN.

The VPN page appears.

Step 2 Click the VPN status icon next to the deployment where you want to view the VPN statistics.

The VPN Status pop-up window appears.

).

The VPN Statistics pop-up window appears.

Step 4 Optionally, click Refresh to update the VPN statistics.

Step 5 Optionally, click View Recent Log to view the latest data log for each endpoint.

To view the log for clustered devices and stacked devices, you can select the link for either the active/primary or backup/secondary device.

Using the VPN Deployment Comparison View

License: VPN

Supported Devices: Series 3

The VPN deployment comparison view allows you to view the changes you have made to a deployment before you apply them. The report displays all differences between the current deployment and the proposed deployment. This gives you an opportunity to discover any potential configuration errors.

The comparison view displays both deployments in a side-by-side format, with each deployment identified by name in the title bar on the left and right sides of the comparison view. The time of last modification and the last user to modify are displayed with the deployment name.

Differences between the two deployments are highlighted:

- Blue indicates that the highlighted setting is different in the two deployments, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one deployment but not the other.

You can perform any of the actions in the following table.

Table 10-2 VPN Deployment Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a deployment comparison report

click Comparison Report.

Using NAT Policies

A network address translation (NAT) policy determines how the system achieves routing with network address translation. You can configure one or more NAT policies, which you can then apply to one or more managed devices. Each device can have one currently applied policy.

You add NAT rules to a policy to control how the system handles network address translations. Each rule contains a set of conditions that identify the specific traffic you want to translate. You can create the following types of rules:

- static, which provide one-to-one translations on destination networks and optionally port and protocol

- dynamic IP, which translate many-to-many source networks, but maintain port and protocol

- dynamic IP and port, which translate many-to-one or many-to-many source networks and port and protocol

The system matches traffic to static translations before dynamic translations are inspected. The system then matches traffic to dynamic NAT rules in order; the first-matched rules handle the traffic. See Organizing Rules in a NAT Policy for more information.

If you have access control policies in your deployment, the system does not translate traffic until it has passed through access control.

To configure and apply NAT policies on your appliances, you must have a Control license enabled on each of your target managed devices. Additionally, you can only apply NAT policies to Series 3 devices with configured virtual routers or hybrid interfaces.

After you have configured and deployed NAT policies, you can use the command line interface (CLI) for managed device targets to troubleshoot the deployment. The CLI displays three types of NAT information: configuration, rule definitions, and active translations. See Command Line Reference for more information.

See the following sections for more information on creating and managing NAT policies:

- Planning and Implementing a NAT Policy

- Configuring NAT Policies

- Organizing Rules in a NAT Policy

- Managing NAT Policies

- Creating and Editing NAT Rules

- Understanding NAT Rule Types

- Understanding NAT Rule Conditions and Condition Mechanics

- Working with Different Types of Conditions in NAT Rules

Planning and Implementing a NAT Policy

License: Any

You can configure NAT policies in different ways to manage specific network needs. This section provides information for some of the ways you can deploy NAT policies.

Caution In clustered configurations, only select an individual peer interface for a static NAT rule on a clustered device if all networks affected by the NAT translations are private. Do not use this configuration for static NAT rules affecting traffic between public and private networks.

You can configure NAT to expose an internal server to an external network. In this configuration, you define a static translation from an external IP address to an internal IP address so the system can access an internal server from outside the network. Traffic sent to the server targets the external IP address or IP address and port, and is translated into the internal IP address or IP address and port. Return traffic from the server is translated back to the external address.

You can configure NAT to allow an internal host or server to connect to an external application. In this configuration, you define a static translation from an internal address to an external address. This definition allows the internal host or server to initiate a connection to an external application that is expecting the internal host or server to have a specific IP address and port. Therefore, the system cannot dynamically allocate the address of the internal host or server.

You can configure NAT to hide private network addresses from an external network by using a block of IP addresses. This becomes useful if you want to obscure your internal network addresses and have sufficient external IP addresses to satisfy your internal network needs. In this configuration, you create a dynamic translation that automatically converts the source IP address of any outgoing traffic to an unused IP address from your externally facing IP addresses.

You can configure NAT to hide private network addresses from an external network using a limited block of IP addresses and port translation. This becomes useful if you want to obscure your internal network addresses, but have an insufficient number of external IP addresses to satisfy your internal network needs. In this configuration, you create a dynamic translation that automatically converts the source IP address and port of outgoing traffic to an unused IP address and port from your externally facing IP addresses.

Configuring NAT Policies

License: Control

Supported Devices: Series 3

To configure a NAT policy, you must give the policy a unique name and identify the devices, or targets, where you want to apply the policy. You can also add, edit, delete, enable, and disable NAT rules. After you create or modify a NAT policy, you can apply the policy to all or some targeted devices.

You can apply NAT policies to a device cluster, including clustered stacks, as you would a standalone device. However, you can define static NAT rules for interfaces on individual clustered devices or the entire cluster and use the interfaces in source zones. For dynamic rules, you can use only the interfaces on the entire cluster in source or destination zones.

Caution In clustered configurations, only select an individual peer interface for a static NAT rule on a clustered device if all networks affected by the NAT translations are private. Do not use this configuration for static NAT rules affecting traffic between public and private networks.

If you configure dynamic NAT on a device cluster without HA link interfaces established, both clustered devices independently allocate dynamic NAT entries, and the system cannot synchronize the entries between devices. See Configuring HA Link Interfaces for more information.

You can apply NAT policies to a device stack as you would a standalone device. If you establish a device stack from devices that were included in a NAT policy and had rules associated with interfaces from the secondary device that was a member of the stack, the interfaces from the secondary device remain in the NAT policy. You can save and apply policies with the interfaces, but the rules do not provide any translation. See Managing Stacked Devices for more information.

The following table summarizes the configuration actions you can take on the NAT policy Edit page.

Creating and Editing NAT Rules

Table 11-1 NAT Policy Configuration Actions

To...

You can...

modify the policy name or description

click the Name or Description field, delete any characters as needed, then type the new name or description.

manage policy targets

find more information at Managing NAT Policy Targets.

save your policy changes

click Save.

save and apply your policy

click Save and Apply. See Applying a NAT Policy for more information.

cancel your policy changes

click Cancel, then, if you have made changes, click OK.

add a rule to a policy

click Add Rule. See Creating and Editing NAT Rules for more information.
.

edit an existing rule

) next to the rule. See for more information. .

delete a rule

. .

enable or disable an existing rule

right-click a selected rule, select State, then select Disable or Enable. Disabled rules are grayed and marked (disabled) beneath the rule name.

display the configuration page for a specific rule attribute

click the name, value, or icon in the column for the condition on the row for the rule. For example, click the name or value in the Source Networks column to display the Source Network page for the selected rule. See Working with Different Types of Conditions in NAT Rules for more information.

Managing NAT Policy Targets

License: Control

Supported Devices: Series 3

Before you can apply a NAT policy, you must identify the managed devices, including device stacks, clusters, or groups, where you want to apply the policy. You can identify the managed devices you want to target with your policy while creating or editing a policy. You can search a list of available devices, stacks, and clusters, and add them to a list of selected devices. You can also drag and drop selected devices, or add devices using the button between the two lists.

Note that you cannot target stacked devices running different versions of the FireSIGHT System (for example, if an upgrade on one of the devices fails). See Managing Stacked Devices for more information.

Table 11-2 Targeted Device Management Actions

To...

You can...

search a list of available devices, stacks, and clusters

click inside the search field, then type a search string. The list of devices updates as you type to display matching device names.

clear a search for available devices

) in the search field.

select available devices, stacks, or clusters to add to the list of selected targets

click the device name; use the Ctrl and Shift keys to select multiple devices.
.

add selected devices, stacks, or clusters

click Add to Policy.

Tip You can also drag and drop into the list of selected devices.

delete a single device, stack, or cluster from the Selected Devices list

) next to the device. .

delete multiple devices from the Selected Devices list

use the Ctrl and Shift keys to select multiple devices, right-click to highlight the row for a selected device, then click Delete Selected.

save your configuration

click Save.

discard your configuration without saving your changes

click Cancel.

The following procedure explains how to configure a NAT policy to manage targeted devices. See Editing a NAT Policy for the complete procedure for editing a NAT policy.

To manage targeted devices in a NAT policy:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy you want to configure.

The NAT Policy Editor page appears.

Step 3 Click the Targets tab.

The Targets page appears.

Step 4 Optionally, click the Search prompt above the Available Devices list, then type a name.

) to clear the list.

Step 5 Click the device, stack, cluster, or device group you want to add. Use Ctrl and Shift to select multiple devices.

Tip You can also right-click an available device, then click Select All.

Step 6 Click Add to Policy.

Selected devices are added.

Tip You can also drag and drop to add devices.

.

Step 8 Click Save to save your configuration, or click Cancel to discard it.

Organizing Rules in a NAT Policy

License: Any

The Edit page for the NAT policy lists static NAT rules and dynamic NAT rules separately. The system sorts static rules alphabetically by name, and you cannot change the display order. You cannot create static rules with identical matching values. The system inspects static translations for a match before it inspects any dynamic translations.

Dynamic rules are processed in numerical order. The numeric position of each dynamic rule appears on the left side of the page next to the rule. You can move or insert dynamic rules and otherwise change the rule order. For example, if you move dynamic rule 10 under dynamic rule 3, rule 10 becomes rule 4 and all subsequent numbers increment accordingly.

A dynamic rule’s position is important because the system compares packets to dynamic rules in the rules' numeric order on the policy Edit page. When a packet meets all the conditions of a dynamic rule, the system applies the conditions of that rule to the packet and ignores all subsequent rules for that packet.

Optionally, you can specify a dynamic rule’s numeric position when you add or edit a dynamic rule. You can also highlight a dynamic rule before adding a new dynamic rule to insert the new rule below the rule you highlighted. See Creating and Editing NAT Rules.

You can select one or more dynamic rules by clicking a blank space in the row for the rule. You can drag and drop selected dynamic rules into a new location, thereby changing the position of the rules you moved and all subsequent rules.

You can cut or copy selected rules and paste them above or below an existing rule. You can only paste static rules in the Static Translations list and only dynamic rules in the Dynamic Translations list. You can also delete selected rules and insert new rules into any location in the list of existing rules.

Note You can copy, but not cut static rules.

You can display explanatory warnings to identify rules that will never match because they are preempted by preceding rules.

If you have access control policies in your deployment, the system does not translate traffic until it has passed through access control.

Table 11-3 NAT Rule Organization Actions

To...

You can...

select a rule

click a blank area in the row for a rule. Use the Ctrl or Shift key to select multiple rules. Rules you select are highlighted.

clear rule selections

) on the lower right side of the page. To clear individual rules, click a blank area in a rule's row while holding the Ctrl key.

cut or copy selected rules

right-click a blank area in the row for a selected rule, then select Cut or Copy.

Tip You can copy, but not cut static rules.

paste rules you have cut or copied into the rule list

right-click a blank area in the row for a rule where you want to paste selected rules, then select Paste above or Paste below.

Tip You can only paste static rules in the Static Translations list and only dynamic rules in the Dynamic Translations list.

move selected rules

drag and drop selected rules beneath a new location, indicated by a horizontal blue line that appears above your pointer as you drag.

delete a rule

. to delete one or more selected rules.

show warnings

click Show Warnings; see Working with NAT Rule Warnings and Errors.

Working with NAT Rule Warnings and Errors

License: Any

The conditions of a NAT rule may preempt a subsequent rule from matching traffic. Any type of rule condition can preempt a subsequent rule.

A rule also preempts an identical subsequent rule where all configured conditions are the same. A subsequent rule would not be preempted if any condition were different.

The following table summarizes the actions you can take to show and clear warnings.

Table 11-4 Preempted Rule Warning Actions

To...

You can...

show warnings

) next to each preempted rule.

display the warning for a rule

) next to a rule. A message indicates which rule preempts the rule.

clear warnings

click Hide Warnings. The page refreshes and the warnings disappear.
), also clears warnings.

.

Managing NAT Policies

License: Control

Supported Devices: Series 3

On the NAT policy page (Devices > NAT), you can view all your current NAT policies by name with optional description and the following status information:

- when a policy is up to date on targeted devices, in green text

- when a policy is out of date on targeted devices, in red text

Options on this page allow you to compare policies, create a new policy, apply a policy to targeted devices, copy a policy, view a report that lists all of the most recently saved settings in each policy, and edit a policy.

Note After you have applied a NAT policy to a managed device, you cannot delete the policy, even if it is out of date. Instead, you must apply a NAT policy with no rules to remove the applied NAT rules from the managed device.

Editing a NAT Policy

Applying a NAT Policy

Copying a NAT Policy

Viewing a NAT Policy Report

Table 11-5 NAT Policy Management Actions

To...

You can...

create a new NAT policy

click New Policy. See Creating a NAT Policy for more information.

modify the settings in an existing NAT policy

). See for more information.

apply a NAT policy to all devices targeted for the policy

). See for more information.

copy a NAT policy

). See for more information.

view a PDF report that lists the current configuration settings in a NAT policy

). See for more information.

compare NAT policies

click Compare Policies. See Comparing Two NAT Policies for more information.

delete a NAT policy

if you decide not to delete the policy. When prompted whether to continue, you are also informed if another user has unsaved changes in the policy. Note After you have applied a NAT policy to a managed device, you cannot delete the policy from the device. Instead, you must apply a NAT policy with no rules to remove the applied NAT rules from the managed device. You also cannot delete a policy that is the last applied policy on any of its target devices, even if it is out of date. Before you can delete the policy completely, you must apply a different policy to those targets.

Creating a NAT Policy

License: Control

Supported Devices: Series 3

When you create a new NAT policy you must, at minimum, give it a unique name. Although you are not required to identify policy targets at policy creation time, you must perform this step before you can apply the policy; see Managing NAT Policy Targets. If you apply a NAT policy with no rules to a device, the system removes all NAT rules from that device.

To create a NAT policy:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

Step 2 Click New Policy.

The New NAT Policy pop-up window appears.

Step 3 Give the policy a unique Name and, optionally, a Description.

You can use all printable characters, including spaces and special characters.

Step 4 Select the Available Devices where you want to apply the policy.

).

Step 5 Add the Selected Devices. You can click and drag, or you can click Add to Policy.

Step 6 Click Save.

The NAT policy Edit page appears. For information on configuring your new policy, including adding rules, see Editing a NAT Policy. Note that you must apply the policy for it to take effect; see Applying a NAT Policy.

Editing a NAT Policy

License: Control

Supported Devices: Series 3

On the NAT policy Edit page, you can configure your policy. See Configuring NAT Policies and for more information.

When you change your configuration, a message indicates that you have unsaved changes. To retain your changes, you must save the policy before exiting the NAT policy Edit page. If you attempt to exit the policy Edit page without saving your changes, you are cautioned that you have unsaved changes; you can then discard your changes and exit the policy, or return to the policy Edit page.

To protect the privacy of your session, after 60 minutes of inactivity on the policy Edit page, changes to your policy are discarded and you are returned to the NAT page. After the first 30 minutes of inactivity, a message appears and updates periodically to provide the number of minutes remaining before changes are discarded. Any activity on the page resets the timer.

When you attempt to edit the same policy in two browser windows, you are prompted whether to resume your edit in the new window, discard your changes in the original window and continue editing in the new window, or cancel the second window and return to the policy Edit page.

When multiple users edit the same policy concurrently, a message for each user on the policy Edit page identifies other users who have unsaved changes. Any user who attempts to save changes is cautioned that saving changes will overwrite changes by other users. When multiple users save the same policy, the last saved changes are retained.

If you change the type of an interface to a type that is not valid for use with a NAT policy that targets a device with that interface, the policy labels the interface as deleted. Click Save in the NAT policy to automatically remove the interface from the policy.

To edit a NAT policy:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy you want to configure.

The NAT policy Edit page appears.

Step 3 To configure your policy, take any of the actions described in Configuring NAT Policies.

Step 4 Save or discard your configuration. You have the following choices:

- To save your changes and continue editing, click Save.

- To save your changes and apply your policy, click Save and Apply . See Applying a NAT Policy.

You must apply your policy to put your changes into effect.

- To discard your changes, click Cancel and, if prompted, click OK .

Your changes are discarded and the NAT page appears.

Copying a NAT Policy

License: Control

Supported Devices: Series 3

You can copy and rename a NAT policy. A policy you copy includes all policy rules and configurations.

To copy a NAT policy:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy you want to configure.

The Copy NAT Policy pop-up window appears.

Step 3 Enter a unique policy Name.

You can use any printable characters, including spaces and special characters.

Step 4 Click OK.

Your copy appears on the NAT page in alphabetical order by name.

Viewing a NAT Policy Report

License: Control

Supported Devices: Series 3

A NAT policy report is a record of the policy and rules configuration at a specific point in time. You can use the report for auditing purposes or to inspect the current configuration.

Tip You can also generate a NAT comparison report that compares a policy with the currently applied policy or with another policy. For more information, see Comparing Two NAT Policies.

Table 11-6 NAT Policy Report Sections

Section

Description

Title Page

Identifies the name of the policy report, the date and time the policy was last modified, and the name of the user who last modified it.

Table of Contents

Describes the contents of the report.

Policy Information

Provides the name and description of the policy, the name of the user who last modified the policy, and the date and time the policy was last modified. See Editing a NAT Policy.

Device Targets

Lists the managed devices targeted by the policy. See Managing NAT Policy Targets.

Rules

Provides the rule type and conditions for each rule in the policy. See Creating and Editing NAT Rules.

Referenced Objects

Provides the name and configuration of all individual objects and group objects used in the policy, by type of condition (Zones, Networks, and Ports) where the object is configured.

To view a NAT policy report:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the policy for which you want to generate a report. Remember to save any changes before you generate a NAT policy report; only saved changes appear in the report.

The system generates the report. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Comparing Two NAT Policies

License: Control

Supported Devices: Series 3

To review policy changes, you can examine the differences between two NAT policies. You can compare any two policies or the currently applied policy with another policy. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies.

There are two tools you can use to compare policies:

- The comparison view displays only the differences between two policies in a side-by-side format. The name of each policy appears in the title bar on the left and right sides of the comparison view except when you select Running Configuration , in which case a blank bar represents the currently active policy.

You can use this to view and navigate both policies on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two policies in a format similar to the policy report, but in PDF format.

You can use this to save, copy, print, and share your policy comparisons for further examination.

For more information on understanding and using policy comparison tools, see the following sections:

- Using the NAT Policy Comparison View

- Using the NAT Policy Comparison Report

Using the NAT Policy Comparison View

License: Control

Supported Devices: Series 3

The comparison view displays both policies in a side-by-side format, with each policy identified by name in the title bar on the left and right sides of the comparison view. When comparing two policies other than the running configuration, the time of last modification and the last user to modify are displayed with the policy name.

Differences between the two policies are highlighted:

- Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy but not the other.

You can perform any of the actions in the following table.

Table 11-7 NAT Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a new policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the NAT Policy Comparison Report for more information.

generate a policy comparison report

click Comparison Report.

The policy comparison report creates a PDF document that lists only the differences between the two policies.

Using the NAT Policy Comparison Report

License: Control

Supported Devices: Series 3

A NAT policy comparison report is a record of all differences between two NAT policies or a policy and the currently applied policy identified by the policy comparison view, presented in PDF format. You can use this report to further examine the differences between two policy configurations and to save and disseminate your findings.

You can generate a NAT policy comparison report from the comparison view for any policies to which you have access. Remember to save any changes before you generate a policy report; only saved changes appear in the report.

The format of the policy comparison report is the same as the policy report, with one exception: the policy report contains all configurations in the policy, while the policy comparison report lists only those configurations that differ between the policies. A NAT policy comparison report contains the sections described in the NAT Policy Report Sections table.

To compare two NAT policies:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

The page refreshes and the Policy A and Policy B drop-down lists appear.

- To compare two different revisions, select Other Revision .

The page refreshes and the Policy, Revision A and Revision B drop-down lists appear.

- To compare another policy to the currently active policy, select Running Configuration.

The page refreshes and the Target/Running Configuration A and Policy B drop-down lists appear.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing two different revisions, select the policy, then select the revisions you want to compare from the Revision A and Revision B drop-down lists.

- If you are comparing the running configuration to another policy, select the second policy from the Policy B drop-down list.

Step 5 Click OK to display the policy comparison view.

The comparison view appears.

Step 6 Optionally, click Comparison Report to generate the NAT policy comparison report.

The NAT policy comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Applying a NAT Policy

License: Control

Supported Devices: Series 3

After making any changes to a NAT policy, you must apply the policy to one or more devices to implement the configuration changes on the networks monitored by the devices. You must target devices where you want to apply the policy before you can apply the policy. See Managing NAT Policy Targets.

Keep the following points in mind when applying NAT policies:

- You can configure and maintain multiple NAT policies on a Defense Center, but only one policy can be applied to a device at a time.

- You can apply two different NAT policies to different devices, even though they are both targets for multiple policies.

- You cannot apply a NAT policy to stacked devices running different versions of the FireSIGHT System (for example, if an upgrade on one of the devices fails). See Managing Stacked Devices for more information.

- You cannot apply a new NAT policy with a policy apply already pending.

- If you apply a device configuration that affects the interfaces in a NAT policy, the system reapplies the NAT policy on the device, including the interface changes. However, the policy remains unchanged on the DC and the interface displays an error icon (

).

Note Applying an empty NAT policy removes all NAT rules from a device.

See the following sections for more information:

- Applying a Complete NAT Policy explains how to use the quick-apply option to apply the NAT policy.

- Applying Selected Policy Configurations explains how to select and apply configurations within the NAT policy.

Applying a Complete NAT Policy

License: Control

Supported Devices: Series 3

You can apply a NAT policy at any time. Applying a NAT policy also applies any associated rule configurations, objects, and policy changes to the devices targeted by the policy. A pop-up window allows you to apply all changes together as a single quick-apply action.

To quick-apply a complete NAT policy:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the policy you want to apply.

The Apply NAT Rules pop-up window appears.

Alternatively, you can click Save and Apply on the policy Edit page; see Editing a NAT Policy.

Step 3 Click Apply All.

Your policy apply task is queued. Click OK to return to the NAT page.

Tip You can monitor the progress of the policy apply task on the Task Status page (System > Monitoring > Task Status).

Applying Selected Policy Configurations

License: Control

Supported Devices: Series 3

You can use the detailed policy apply page to apply changes to your NAT policy and to any designated targeted devices. The detailed page lists each device targeted by the policy and provides a column for the NAT policy by device. You can specify whether to apply changes to a NAT policy for each targeted device that is out of date.

To apply selected NAT policy configurations:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the policy you want to apply.

The Apply NAT Rules pop-up window appears.

Alternatively, you can click Save and Apply on the policy Edit page; see Editing a NAT Policy.

Step 3 Click Details.

The detailed Apply NAT Rules pop-up window appears.

Tip You can also open the pop-up window from the NAT page (Devices > NAT) by clicking on an out-of-date message in the Status column for the policy.

Step 4 Select or clear the NAT policy check box next to the device name to specify whether to apply the NAT policy to a targeted device.

Step 5 Click Apply Selected Configurations.

Your policy apply task is queued. Click OK to return to the NAT page.

Tip You can monitor the progress of the policy apply task on the Task Status page (System > Monitoring > Task Status).

Creating and Editing NAT Rules

License: Control

Supported Devices: Series 3

A NAT rule is simply a set of configurations and conditions that:

- qualifies network traffic

- specifies how the traffic that matches those qualifications is translated

You create and edit NAT rules from within an existing NAT policy. Each rule belongs to only one policy.

The web interface for adding or editing a rule is similar. You specify the rule name, state, type, and position (if dynamic) at the top of the page. You build conditions using the tabs on the left side of the page; each condition type has its own tab.

The following list summarizes the configurable components of a NAT rule.

Name

Give each rule a unique name. For static NAT rules, use a maximum of 22 characters. For dynamic NAT rules, use a maximum of 30 characters. You can use printable characters, including spaces and special characters, with the exception of the colon (:).

Rule State

By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic for translation. When viewing the list of rules in a NAT policy, disabled rules are grayed out, although you can still modify them.

Type

A rule’s type determines how the system handles traffic that matches the rule’s conditions. When you create and edit NAT rules, the configurable components vary according to rule type.

For detailed information on rule types and how they affect translation and traffic flow, see Understanding NAT Rule Types.

Position (Dynamic Rules Only)

Dynamic rules in a NAT policy are numbered, starting at 1. The system matches traffic to NAT rules in top-down order by ascending rule number.

When you add a rule to a policy, you specify its position by placing it above or below a specific rule, using rule numbers as a reference point. When editing an existing rule, you can Move the rule in a similar fashion. For more information, see Organizing Rules in a NAT Policy.

Conditions

Rule conditions identify the specific traffic you want to translate. Conditions can match traffic by any combination of multiple attributes, including security zone, network, and transport protocol port.

For detailed information on adding conditions, see Understanding NAT Rule Conditions and Condition Mechanics and Working with Different Types of Conditions in NAT Rules.

To create or edit a NAT rule:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy where you want to add a rule.

The NAT policy Edit page appears.

Step 3 Add a new rule or edit an existing rule:

- To add a new rule, click Add Rule .

- To edit an existing rule, click the edit icon (

) next to the rule you want to edit.

Either the Add Rule or the Editing Rule page appears.

Tip You can use the right-click context menu to perform many rule creation and management actions; see Using the Context Menu. You can also drag and drop rules to change their order.

Step 4 Configure the rule components, as described earlier in this section. You can configure the following, or accept the defaults:

- You must provide a unique rule Name .

- Specify whether the rule is Enabled .

- Select a rule Type .

- Specify the rule position (dynamic rules only).

- Configure the rule’s conditions.

Static rules must include an original destination network.

Dynamic rules must include a translated source network.

Step 5 Click Add or Save.

Your changes are saved. You must apply the NAT policy for your changes to take effect; see Applying a NAT Policy.

Understanding NAT Rule Types

License: Any

Every NAT rule has an associated type that:

- qualifies network traffic

- specifies how the traffic that matches those qualifications is translated

The following list summarizes the NAT rule types.

Static

Static rules provide one-to-one translations on destination networks and optionally port and protocol. When configuring static translations, you can configure source zones, destination networks, and destination ports. You cannot configure destination zones or source networks.

You must specify an original destination network. For destination networks, you can only select network objects and groups containing a single IP address or enter literal IP addresses that represent a single IP address. You can only specify a single original destination network and a single translated destination network.

Optionally, you can specify a single original destination port and a single translated destination port. You must specify an original destination network before you can specify an original destination port. In addition, you cannot specify a translated destination port unless you also specify an original destination port, and the translated value must match the protocol of the original value.

Caution For static NAT rules on a a clustered device, only select an individual peer interface if all networks affected by the NAT translations are private. Do not use this configuration for static NAT rules affecting traffic between public and private networks.

Dynamic IP Only

Dynamic IP Only rules translate many-to-many source networks, but maintain port and protocol. When configuring dynamic IP only translations, you can configure zones, source networks, original destination networks, and original destination ports. You cannot configure translated destination networks or translated destination ports.

You must specify at least one translated source network. If the number of translated source network values is less than the number of original source networks, the system displays a warning on the rule that it is possible to run out of translated addresses before all original addresses are matched.

If there are multiple rules with conditions that match the same packet, the low priority rules become dead, meaning they can never be triggered. The system also displays warnings for dead rules. You can view tooltips to determine which rule supersedes the dead rule.

Note You can save and apply policies with dead rules, but the rules cannot provide any translation.

In some instances, you may want to create rules with limited scope preceding rules with a broader scope. For example:

Rule 1: Match on address A and port A/Translate to address B

Rule 2: Match on address A/Translate to Address C

In this example, rule 1 matches some packets that also match rule 2. Therefore, rule 2 is not completely dead.

Optionally, you can specify only original destination ports. You cannot specify translated destination ports.

Dynamic IP + Port

Dynamic IP and port rules translate many-to-one or many-to-many source networks and port and protocol. When configuring dynamic IP and port translations, you can configure zones, source networks, original destination networks, and original destination ports. You cannot configure translated destination networks or translated destination ports.

You must specify at least one translated source network. If there are multiple rules with conditions that match the same packet, the low priority rules become dead, meaning they can never be triggered. The system also displays warnings for dead rules. You can view tool tips to determine which rule supersedes the dead rule.

Note You can save and apply policies with dead rules, but the rules cannot provide any translation.

Optionally, you can specify only original destination ports. You cannot specify translated destination ports.

Note If you create a dynamic IP and port rule, and the system passes traffic that does not use a port, no translation occurs for the traffic. For example, a ping (ICMP) from an IP address that matches the source network does not map, because ICMP does not use a port.

The following table summarizes the NAT rule condition types that can be configured based on the specified NAT rule type:

Table 11-8 Available NAT Rule Condition Types per NAT Rule Type

Condition

Static

Dynamic (IP Only or IP + Port)

Source Zones

Optional

Optional

Destination Zones

Not allowed

Optional

Original Source Networks

Not allowed

Optional

Translated Source Networks

Not allowed

Required

Original Destination Networks

Required

Optional

Translated Destination Networks

Optional; single address only

Not allowed

Original Destination Ports

Optional; single port only, and only allowed if you define the original destination network

Optional

Translated Destination Ports

Optional; single port only, and only allowed if you define the original destination port

Not allowed

Understanding NAT Rule Conditions and Condition Mechanics

License: Any

You can add conditions to NAT rules to identify the type of traffic that matches the rule. For each condition type, you select conditions you want to add to a rule from a list of available conditions. When applicable, condition filters allow you to constrain available conditions. Lists of available and selected conditions may be as short as a single condition or many pages long. You can search available conditions and display only those matching a typed name or value in a list that updates as you type.

Depending on the type of condition, lists of available conditions may be comprised of a combination of conditions provided directly by Cisco or configured using other FireSIGHT System features, including objects created using the object manager (Objects > Object Management), objects created directly from individual conditions pages, and literal conditions.

See the following sections for information on specifying rule conditions:

- Understanding NAT Rule Conditions defines the different types of rule conditions.

- Adding Conditions to NAT Rules describes the controls used to select and add rule conditions.

- Searching NAT Rule Condition Lists explains how to search available conditions and display only those matching a typed name or value in a list that updates as you type.

- Adding Literal Conditions to NAT Rules explains how to add literal conditions to a rule.

- Using Objects in NAT Rule Conditions explains how to add individual objects to the system from the configuration pages for relevant condition types.

Understanding NAT Rule Conditions

License: Any

You can set a NAT rule to match traffic meeting any of the conditions described in the following table:

Table 11-9 NAT Rule Condition Types

Condition

Description

Supported Defense Centers

Supported Devices

Zones

A configuration of one or more routed interfaces where you can apply NAT policies. Zones provide a mechanism for classifying traffic on source and destination interfaces, and you can add source and destination zone conditions to rules. See Working with Security Zones for information on creating zones using the object manager.

Any

Series 3

Networks

Any combination of individual IP addresses, CIDR blocks, and prefix lengths, either specified explicitly or using network objects and groups (see Working with Network Objects). You can add source and destination network conditions to NAT rules.

Any

Series 3

Destination Ports

Transport protocol ports, including individual and group port objects you create based on transport protocols. See Working with Port Objects for information on creating individual and group transport protocol objects using the object manager.

Any

Series 3

Adding Conditions to NAT Rules

License: Any

Adding conditions to NAT rules is essentially the same for each type of condition. You select from a list of available conditions on the left, and add the selected conditions to one or two lists of selected conditions on the right.

For all condition types, you select one or more individual available conditions by clicking on them to highlight them. You can either click a button between the two types of lists to add available conditions that you select to your lists of selected conditions, or drag and drop available conditions that you select into the list of selected conditions.

You can add up to 50 conditions of each type to a list of selected conditions. For example, you can add up to 50 source zone conditions, up to 50 destination zone conditions, up to 50 source network conditions, and so on, until you reach the upper limit for the appliance.

The following table describes the actions you can take to select and add conditions to a rule.

Managing Reusable Objects

Table 11-10 Adding Conditions to NAT Rules

To...

You can...

select available conditions to add to a list of selected conditions

click the available condition; use the Ctrl and Shift keys to select multiple conditions.

select all listed available conditions

right-click the row for any available condition, then click Select All.

search a list of available conditions or filters

click inside the Search field and type a search string. See Searching NAT Rule Condition Lists for more information.

clear a search when searching available conditions or filters

) in the Search field.

add selected zone conditions from a list of available conditions to a list of selected source or destination conditions

click Add to Source or Add to Destination. See Adding Zone Conditions to NAT Rules for more information.

add selected network and port conditions from a list of available conditions to a list of selected original or translated conditions

click Add to Original or Add to Translated. See Adding Source Network Conditions to Dynamic NAT Rules, Adding Destination Network Conditions to NAT Rules, or Adding Port Conditions to NAT Rules for more information.

drag and drop selected available conditions into a list of selected conditions

click a selected condition, then drag and drop into the list of selected conditions.

add a literal condition to a list of selected conditions using a literal field

click to remove the prompt from the literal field, type the literal condition, then click Add. Network conditions provide a field for adding literal conditions.

add a literal condition to a list of selected conditions using a drop-down list

select a condition from the drop-down list, then click Add. Port conditions provide a drop-down list for adding literal conditions. See Adding Port Conditions to NAT Rules for more information.

add an individual object or condition filter so you can then select it from the list of available conditions

). See for information on adding objects using the object manager.

delete a single condition from a list of selected conditions

) next to the condition

delete a condition from a list of selected conditions

right-click to highlight the row for a selected condition, then click Delete.

delete multiple conditions from a list of selected conditions

use the Shift and Ctrl keys to select multiple conditions, or right-click and Select All; next, right-click to highlight the row for a selected condition, then click Delete Selected.

On the relevant condition page, and also on the policy Edit page, you can hover your pointer over an individual object to display the contents of the object, and over a group object to display the number of individual objects in the group.

The following basic procedure explains how to add conditions to a new rule. See Creating and Editing NAT Rules for complete instructions on adding and modifying rules.

To add available conditions to a list of selected conditions:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy you want to modify.

The policy Edit page appears.

Step 3 Click Add Rule.

The Add Rule page appears.

Step 4 Click the tab for the type of condition you want to add to the rule.

The conditions page appears for the type of condition you selected.

Step 5 Take any of the available actions in the Adding Conditions to NAT Rules table.

Step 6 Click Add to save your configuration.

Your rule is added and the policy Edit page appears.

Searching NAT Rule Condition Lists

License: Any

You can filter a list of available NAT rule conditions to limit the number of items displayed in the list. The list updates as you type to display matching items.

Optionally, you can search on object names and on the values configured for objects. For example, if you have an individual network object named Texas Office with the configured value 192.168.3.0/24, and the object is included in the group object US Offices, you can display both objects by typing a partial or complete search string such as Tex, or by typing a value such as 3.

The following basic procedure explains how to filter a list in a new rule. See Creating and Editing NAT Rules for complete instructions on adding and modifying rules.

To search a list of available conditions:

Access: Admin/Network Admin

Step 1 Select Devices > NAT.

The NAT page appears.

) next to the NAT policy you want to modify.

The policy Edit page appears.

Step 3 Click Add Rule.

The Add Rule page appears.

Step 4 To search a list, click inside the search field to clear the prompt, then type a search string.

) appears in the search field. The list updates and no items are listed when none match the search string.

field to clear the search string.

The complete list appears.

Step 6 Click Add to save your configuration.

Your rule is added and the policy Edit page appears.

Adding Literal Conditions to NAT Rules

License: Any

You can add a literal value to the list of original and translated conditions for the following condition types:

- Networks

- Ports

For network conditions, you type the literal value in a configuration field below the list of original or translated conditions.

In the case of port conditions, you select a protocol from a drop-down list. When the protocol is All and, optionally, when the protocol is TCP or UDP, you type a port number in a configuration field.

Each relevant conditions page provides the controls needed to add literal values. Values you type in a configuration field appear as red text if the value is invalid, or until it is recognized as valid. Typed values change to blue text as you type when they are recognized as valid. A grayed Add button activates when a valid value is recognized. Literal values you add appear immediately in the list of selected conditions.

See the following sections for specific details on adding each type of literal value:

- Adding Source Network Conditions to Dynamic NAT Rules

- Adding Destination Network Conditions to NAT Rules

- Adding Port Conditions to NAT Rules

Using Objects in NAT Rule Conditions

License: Any

Objects that you create in the object manager (Objects > Object Management) are immediately available for you to select from relevant lists of available NAT rule conditions. See Managing Reusable Objects for information.

You can also create objects on-the-fly from the NAT policy. A control on relevant conditions pages provides access to the same configuration controls that you use in the object manager.

Individual objects created on-the-fly appear immediately in the list of available objects. You can add them to the current rule, and to other existing and future rules. On the relevant conditions page, and also on the policy Edit page, you can hover your pointer over an individual object to display the contents of the object, and over a group object to display the number of individual objects in the group.

Working with Different Types of Conditions in NAT Rules

License: Any

You can match traffic with one or more rule conditions. See the following sections for more information:

- Adding Zone Conditions to NAT Rules explains how to match traffic by security zones that you create using the object manager.

- Adding Source Network Conditions to Dynamic NAT Rules and Adding Destination Network Conditions to NAT Rules explain how to match traffic by IP address or address block.

- Adding Port Conditions to NAT Rules explains how to match traffic by specified transport protocol ports.

Adding Zone Conditions to NAT Rules

License: Any

The security zones on your system are comprised of interfaces on your managed devices. Zones that you add to a NAT rule target the rule to devices on your network that have routed or hybrid interfaces in those zones. You can only add security zones with routed or hybrid interfaces as conditions for NAT rules. See Working with Security Zones for information on creating security zones using the object manager.

) next to a zone to collapse or expand the zone to hide or view its interfaces.

) to collapse or expand the clustered device interfaces to hide or view its interfaces.

Note You can save and apply policies with disabled interfaces, but the rules cannot provide any translation until the interfaces are enabled.

The two lists on the right are the source and destination zones used for matching purposes by the NAT rules. If the rule already has values configured, these lists display the existing values when you edit the rule. If the source zones list is empty, the rule matches traffic from any zone or interface. If the destination zones list is empty, the rule matches traffic to any zone or interface.

The system displays warnings for rules with zone combinations that never trigger on a targeted device.

Note You can save and apply policies with these zone combinations, but the rules will not provide any translation.

You can add individual interfaces by selecting an item in a zone or by selecting a standalone interface. You can only add interfaces in a zone if the zone it is assigned to has not already been added to a source zones or destination zones list. These individually selected interfaces are not affected by changes to zones, even if you remove them and add them to a different zone. If an interface is the primary member of a cluster and you are configuring a dynamic rule, you can add only the primary interface to the source zones or destination zones list. For static rules, you can add individual cluster member interfaces to the source zones list. You can only add a primary cluster interface to a list if none of its children have been added, and you can only add individual cluster interfaces if the primary has not been added.

If you add a zone, the rule uses all interfaces associated with the zone. If you add or remove an interface from the zone, the rule will not use the updated version of the zone until the device configuration has been reapplied to the devices where the interfaces reside.

Note In a static NAT rule, you can add only source zones. In a dynamic NAT rule, you can add both source and destination zones.

The following procedure explains how to add source and destination zone conditions while adding or editing a NAT rule. See Understanding NAT Rule Conditions and Condition Mechanics for more detailed information.

To add zone conditions to a NAT rule:

Access: Admin/Network Admin

Step 1 Select the Zones tab on the rule Edit page.

The Zones page appears.

Step 2 Optionally, click the Search by name prompt above the Available Zones list, then type a name or value.

The list updates as you type to display matching conditions. See Searching NAT Rule Condition Lists for more information.

Step 3 Click a zone or interface in the Available Zones list. Use the Shift and Ctrl keys to select multiple conditions, or right-click and then click Select All.

Conditions you select are highlighted.

Step 4 You have the following choices:

- To match traffic by source zone, click Add to Source .

- To match traffic by destination zone, click Add to Destination .

Optionally, you can drag and drop selected conditions into the Source Zones or Destination Zones lists.

Selected conditions are added. Note that while you can add disabled interfaces to a NAT rule, the rule does not provide any translation.

Note You can add only source zones to static NAT rules.

Step 5 Save or continue editing the rule.

You must apply the NAT policy for your changes to take effect; see Applying a NAT Policy.

Adding Source Network Conditions to Dynamic NAT Rules

License: Any

You configure the matching values and translation values of the source IP address for packets. If the original source network is not configured, then any source IP address matches the dynamic NAT rule. Note that you cannot configure source networks for static NAT rules. If a packet matches the NAT rule, the system uses the values in the translated source network to assign the new value for the source IP address. For dynamic rules, you must configure a translated source network with at least one value.

Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or group, it can cause the rule to become invalid.

You can add any of the following kinds of source network conditions to a dynamic NAT rule:

- individual and group network objects that you have created using the object manager

See Working with Network Objects for information on creating individual and group network objects using the object manager.

- individual network objects that you add from the Source Network conditions page, and can then add to your rule and to other existing and future rules

See Using Objects in NAT Rule Conditions for more information.

- literal, single IP addresses, ranges, or address blocks

See Adding Literal Conditions to NAT Rules for more information.

The following procedure explains how to add source network conditions while adding or editing a dynamic NAT rule. See Understanding NAT Rule Conditions and Condition Mechanics for more detailed information.

To add network conditions to a dynamic NAT rule:

Access: Admin/Network Admin

Step 1 Select the Source Networks tab on the rule Edit page.

The Source Network page appears.

Step 2 Optionally, click the Search by name or value prompt above the Available Networks list, then type a name or value.

The list updates as you type to display matching conditions. See Searching NAT Rule Condition Lists for more information.

Step 3 Click a condition in the Available Networks list. Use the Shift and Ctrl keys to select multiple conditions, or right-click and then click Select All.

Conditions you select are highlighted.

Step 4 You have the following choices:

- To match traffic by original source network, click Add to Original .

- To specify the translation value for traffic that matches the translated source network, click Add to Translated .

Alternatively, you can drag and drop selected conditions into the Original Source Network or Translated Source Network lists.

Conditions you selected are added.

list to add an individual network object.

You can add multiple IP addresses, CIDR blocks, and prefix lengths to each network object.

Optionally, you can then select the object you added. See Working with Network Objects and Using Objects in NAT Rule Conditions for more information.

Step 6 Optionally, click the Enter an IP address prompt below the Original Source Network or Translated Source Network list; then type an IP address, range, or address block and click Add.

You add ranges in the following format: lower IP address-upper IP address. For example: 179.13.1.1-179.13.1.10.

The list updates to display your entry. See Adding Literal Conditions to NAT Rules for more information.

Step 7 Save or continue editing the rule.

Note When you update the network conditions in a dynamic rule in use in an applied policy, the system drops any network sessions using the existing translated address pool.

You must apply the NAT policy for your changes to take effect; see Applying a NAT Policy.

Adding Destination Network Conditions to NAT Rules

License: Any

You configure the matching values and translation values of the destination IP address for packets. Note that you cannot configure translated destination networks for dynamic NAT rules.

Because static NAT rules are one-to-one translations, the Available Networks list contains only network objects and groups that contain only a single IP address. For static translations, you can add only a single object or literal value to both the Original Destination Network or Translated Destination Network lists.

Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or group, it can cause the rule to become invalid.

You can add any of the following kinds of destination network conditions to a NAT rule:

- individual and group network objects that you have created using the object manager

See Working with Network Objects for information on creating individual and group network objects using the object manager.

- individual network objects that you add from the Destination Network conditions page, and can then add to your rule and to other existing and future rules

See Using Objects in NAT Rule Conditions for more information.

- literal, single IP addresses, range, or address blocks

For static NAT rules, you can add only a CIDR with subnet mask /32, and only if there is not already a value in the list.

See Adding Literal Conditions to NAT Rules for more information.

The following procedure explains how to add destination network conditions while adding or editing a NAT rule. See Understanding NAT Rule Conditions and Condition Mechanics for more detailed information.

To add destination network conditions to a NAT rule:

Access: Admin/Network Admin

Step 1 Select the Destination Network tab on the rule Edit page.

The Destination Network page appears.

Step 2 Optionally, click the Search by name or value prompt above the Available Networks list, then type a name or value.

The list updates as you type to display matching conditions. See Searching NAT Rule Condition Lists for more information.

Step 3 Click a condition in the Available Networks list. Use the Shift and Ctrl keys to select multiple conditions, or right-click and then click Select All.

Conditions you select are highlighted.

Step 4 You have the following choices:

- To match traffic by original destination network, click Add to Original .

- To specify the translation value for traffic that matches the translated destination network, click Add to Translated .

Alternatively, you can drag and drop selected conditions into the Original Destination Network or Translated Destination Network lists.

Conditions you selected are added.

list to add an individual network object.

For dynamic rules, you can add multiple IP addresses, CIDR blocks, and prefix lengths to each network object. For static rules, you can add only a single IP address. Optionally, you can then select the object you added. See Working with Network Objects and Using Objects in NAT Rule Conditions for more information.

Step 6 Optionally, click the Enter an IP address prompt below the Original Destination Network or Translated Destination Network list, then type an IP address or address block and click Add.

The list updates to display your entry. See Adding Literal Conditions to NAT Rules for more information.

Step 7 Save or continue editing the rule.

Note When you update the network conditions in a dynamic rule in use in an applied policy, the system drops any network sessions using the existing translated address pool.

You must apply the NAT policy for your changes to take effect; see Applying a NAT Policy.

Adding Port Conditions to NAT Rules

License: Any

You can add a port condition to a rule to match network traffic based on the original and translated destination port and transport protocol for translation. If the original port is not configured, any destination port matches the rule. If a packet matches the NAT rule and a translated destination port is configured, the system translates the port into that value. Note that for dynamic rules, you can specify only the original destination port. For static rules, you can define a translated destination port, but only with an object with the same protocol as the original destination port object or literal value.

The system matches the destination port against the value of the port object or literal port in the original destination port list for static rules, or multiple values for dynamic rules.

Because static NAT rules are one-to-one translations, the Available Ports list contains only port objects and groups that contain only a single port. For static translations, you can add only a single object or literal value to both the Original Port or Translated Port lists.

For dynamic rules, you can add a range of ports. For example, when specifying the original destination port, you can add 1000-1100 as a literal value.

Caution If a port object or object group is being used by a NAT rule, and you change or delete the object or group, it can cause the rule to become invalid.

You can add any of the following kinds of port conditions to a NAT rule:

- individual and group port objects that you have created using the object manager

See Working with Port Objects for information on creating individual and group port objects using the object manager.

- individual port objects that you add from the Destination Ports conditions page, and can then add to your rule and to other existing and future rules

See Using Objects in NAT Rule Conditions for more information.

- literal port values, consisting of a TCP, UDP, or All (TCP and UDP) transport protocol and a port

See Adding Literal Conditions to NAT Rules for more information.

The following procedure explains how to add port conditions while adding or editing a NAT rule. See Understanding NAT Rule Conditions and Condition Mechanics for more detailed information.

To add destination port conditions to a NAT rule:

Access: Admin/Network Admin

Step 1 Select the Destination Port tab on the rule Edit page.

The Destination Port page appears.

Step 2 Optionally, click the Search by name or value prompt above the Available Ports list, then type a name or value.

The list updates as you type to display matching conditions. See Searching NAT Rule Condition Lists for more information.

Step 3 Click a condition in the Available Ports list. Use the Shift and Ctrl keys to select multiple conditions, or right-click to select all conditions. Note that you can add a maximum of 50 conditions.

Conditions you select are highlighted.

Step 4 You have the following choices:

- Click Add to Original to add the selected port to the Original Ports list.

- Click Add to Translated to add the selected port to the Translated Ports list.

- Drag and drop available ports into a list.

list.

You can identify a single port or a port range in each port object that you add. You can then select objects you added as conditions for your rule. See Using Objects in NAT Rule Conditions for more information.

For static rules, you can use only port objects with single ports.

Step 6 Optionally, to add a literal port select an entry from the Protocol drop-down list beneath the Original Port or Translated Port lists.

Enter a port, then click Add. You can specify a port number from 0 through 65535. For dynamic rules, you can specify a single port or a range.

The list updates to display your selection. See Adding Literal Conditions to NAT Rules for more information.

Conditions you selected are added

Step 7 Save or continue editing the rule.

You must apply the NAT policy for your changes to take effect; see Applying a NAT Policy.

Getting Started with Access Control Policies

An access control policy determines how the system handles non-fast-pathed traffic on your network. You can configure one or more access control policies, which you can then apply to one or more managed devices. Each device can have one currently applied policy.

The simplest access control policy directs its target devices to handle all traffic using its default action. You can set this default action to block or trust all traffic without further inspection, or to inspect traffic for intrusions and discovery data.

Note that only devices deployed inline can affect the flow of traffic. Applying an access control policy configured to block or alter traffic to passively deployed devices can have unexpected results. In some cases, the system prevents you from applying inline configurations to passively deployed devices.

This chapter explains how to create and apply a simple access control policy. It also contains basic information on managing access control policies: editing, updating, comparing, and so on. For more information, see:

- Access Control License and Role Requirements

- Creating a Basic Access Control Policy

- Managing Access Control Policies

- Editing Access Control Policies

- Understanding Out-of-Date Policy Warnings

- Applying an Access Control Policy

- IPS or Discovery-Only Performance Considerations

- Troubleshooting Access Control Policies and Rules

- Generating a Report of Current Access Control Settings

- Comparing Access Control Policies

A more complex access control policy can blacklist traffic based on Security Intelligence data, as well as use access control rules to exert granular control over network traffic logging and handling. These rules can be simple or complex, matching and inspecting traffic using multiple criteria. Advanced access control policy options control decryption, preprocessing, performance, and other general preferences.

After you create a basic access control policy, see the following chapters for more information on tailoring it to your deployment:

- Blacklisting Using Security Intelligence IP Address Reputation explains how to immediately blacklist (block) connections based on the latest reputation intelligence.

- Understanding Traffic Decryption explains how to use an SSL policy to block encrypted traffic without inspecting it, or to pass it on to access control rules, optionally after decrypting it.

- Understanding Network Analysis and Intrusion Policies explains how network analysis and intrusion policies preprocess and examine packets, as part of the system’s intrusion detection and prevention feature.

- Tuning Traffic Flow Using Access Control Rules explains how access control rules provide a granular method of handling network traffic across multiple managed devices.

- Controlling Traffic Using Intrusion and File Policies explains how intrusion and file policies provide the last line of defense before traffic is allowed to its destination, by detecting and optionally blocking intrusions, prohibited files, and malware.

Access Control License and Role Requirements

Although you can create access control policies regardless of the licenses on your Defense Center, many features require that you enable the appropriate licenses before you apply the policy. Additionally, some features are only available on certain models.

Also note that available access control-related features and actions depend on your user role. The system includes predefined user roles designed for a variety of administrators and analysts, and you can create custom user roles with specialized access privileges.

For more information, see:

- License and Model Requirements for Access Control

- Managing Your Deployment with Custom User Roles

License and Model Requirements for Access Control

Although you can create access control policies regardless of the licenses on your Defense Center, certain aspects of access control require that you enable specific licensed capabilities on target devices before you can apply the policy. Additionally, some features are only available on certain models.

Warning icons and confirmation dialog boxes designate unsupported features for your deployment. For details, hover your pointer over a warning icon and see Troubleshooting Access Control Policies and Rules.

The following table explains the license and appliance model requirements to apply access control policies. Note that Series 2 devices automatically have most Protection capabilities; you do not have to explicitly enable Protection on those devices.

Table 12-1 License and Model Requirements for Access Control

To apply an access control policy that...

License

Supported Defense Centers

Supported Devices

performs access control based on zone, network, VLAN, or port

performs URL filtering using literal URLs and URL objects

Any

Any

Any, except:

- Series 2 devices cannot perform URL filtering

- ASA FirePOWER devices cannot perform VLAN filtering

performs SSL inspection; see Table 12-2

Any

Any, except the DC500 is limited to network, application, and SSL-related control

Series 3

performs access control using geolocation data (source or destination country or continent)

FireSIGHT

Any except DC500

Series 3

Virtual

ASA FirePOWER

performs intrusion detection and prevention, file control, or Security Intelligence filtering

Protection

Any

Any, except Series 2 devices cannot perform Security Intelligence filtering

performs advanced malware protection, that is, network-based malware detection and blocking

Malware

Any except DC500

Any except Series 2 or X-Series

performs user or application control

Control

Any, except the DC500 cannot perform user control

Any except Series 2 or X-Series

performs URL filtering using category and reputation data

URL Filtering

Any except DC500

Any except Series 2

Table 12-2 License and Model Requirements for SSL Inspection

To apply an SSL policy that...

License

Supported Defense Centers

Supported Devices

handles encrypted traffic on the basis of zone, network, VLAN, port, or SSL-related criteria

Any

Any

Series 3

handles encrypted traffic using geolocation data

FireSIGHT

Any except DC500

Series 3

handles encrypted traffic using application or user criteria

Control

Any, except the DC500 cannot perform user control

Series 3

filters encrypted traffic using URL category and reputation data

URL Filtering

Any except DC500

Series 3

Managing Your Deployment with Custom User Roles

License: feature dependent

As described in Managing Custom User Roles, you can create custom user roles with specialized access privileges. Custom user roles can have any set of menu-based and system permissions, and may be completely original or based on a predefined user role. Custom roles for access control-related features determine whether users can view, modify, and apply access control, intrusion, and file policies, as well as insert or modify rules in the Administrator Rules or Root Rules categories.

The following table shows five example custom roles that determine how FireSIGHT System users interact with access control features. The table lists, in the order they appear when creating custom user roles, the privileges required for each custom role.

Table 12-3 Example Access Control Custom Roles

Custom Role Permission

Access Control & SSL Editor

Intrusion & Network Analysis Editor

File Policy Editor

Policy Applier (All)

Intrusion Policy Applier

Access Control

yes

no

no

yes

yes

Access Control List

yes

no

no

yes

yes

Modify Access Control Policy

yes

no

no

no

no

Apply Intrusion Policies

no

no

no

yes

yes

Apply Access Control Policies

no

no

no

yes

no

Intrusion (also grants network analysis privileges)

no

yes

no

no

no

Intrusion Policy

no

yes

no

no

no

Modify Intrusion Policy

no

yes

no

no

no

File Policy

no

no

yes

no

no

Modify File Policy

no

no

yes

no

no

SSL

yes

no

no

no

no

Modify SSL Policy

yes

no

no

no

no

Apply SSL Policy

no

no

no

yes

no

Note that you can create and edit network analysis as well as intrusion policies if your FireSIGHT System user account’s role is restricted to Intrusion Policy or Modify Intrusion Policy.

The system renders the web interface differently depending on whether a user can apply full access control policies (including intrusion policies), only intrusion policies, or neither. For example, Intrusion Policies Appliers in the table above can view access control policies and apply intrusion policies but cannot edit either. They also cannot apply access control policies, nor view file or SSL policies. In the web interface in this case:

- the edit icon (

) does not appear on the Access Control Policy page

- the delete icon (

) does not appear on the Access Control Policy page

- the quick-apply pop-up window applies only the intrusion policy

- access control policy check boxes in the detailed apply pop-up window are disabled

Creating a Basic Access Control Policy

License: Any

When you create a new access control policy you must give it a unique name and specify a default action. At this point, the default action determines how the policy’s target devices handles all non-fastpathed traffic; you will add other configurations that affect traffic flow later. Although you are not required to identify the policy targets at creation time, you must perform this step before you can apply the policy.

When you create a new policy, you can set the default action to block all traffic without further inspection, or to inspect traffic for intrusions and discovery data, as shown in the following diagram.

Tip When you first create an access control policy, you cannot choose to trust traffic as the default action. If you want to trust all traffic by default, change the default action after you create the policy.

Use the Access Control Policy page (Policies > Access Control) to create new and manage existing access control policies. Depending on whether and how you registered devices to the Defense Center, either of two predefined access control policies might appear and already be applied to your devices:

- The Default Access Control policy blocks all traffic without further inspection.

- The Default Intrusion Prevention policy allows all traffic, but also inspects with the Balanced Security and Connectivity intrusion policy and default intrusion variable set.

You can use and modify either of these access control policies. Note that neither of these default policies has logging enabled.

Caution Applying an access control policy for the first time restarts the Snort process, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To create an access control policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

Step 2 Click New Policy.

The New Access Control Policy pop-up window appears.

Step 3 Give the policy a unique Name and, optionally, a Description.

You can use all printable characters, including spaces and special characters, except for the pound sign (#), a semi-colon (;), or either brace ({}). The name must include at least one non-space character.

Step 4 Specify the initial Default Action:

- Block all traffic creates a policy with the Access Control: Block All Traffic default action.

- Intrusion Prevention creates a policy with the Intrusion Prevention: Balanced Security and Connectivity default action.

- Network Discovery creates a policy with the Network Discovery Only default action.

For guidance on choosing an initial default action, as well as how to change it later, see Setting Default Handling and Inspection for Network Traffic.

Step 5 Select the Available Devices where you want to apply the policy.

Use Ctrl and Shift to select multiple devices, or right-click to Select All. To narrow the devices that appear, type a search string in the Search field. If you skip adding target devices, see Setting Target Devices for an Access Control Policy for information on adding them later.

Step 6 Click Add to Policy to add the selected devices.

You can also drag and drop selected objects.

Step 7 Click Save.

The access control policy editor appears. For information on configuring your new policy, see Editing Access Control Policies. Note that you must apply the policy for it to take effect; see Applying an Access Control Policy.

Setting Default Handling and Inspection for Network Traffic

License: Any

When you create an access control policy, you must select a default action. The default action for an access control policy determines how the system handles traffic that:

- is not blacklisted by Security Intelligence

- is not blocked by SSL inspection (encrypted traffic only)

- matches none of the rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic)

The following table describes how the different default actions handle traffic, and lists the types of inspection you can perform on traffic handled by each default action. Note that you cannot perform file or malware inspection on traffic handled by the default action. For more information, see Controlling Traffic Using Intrusion and File Policies.

:

Table 12-4 Access Control Policy Default Actions

Default Action

Effect on Traffic

Inspection Type and Policy

Access Control: Block All Traffic

block without further inspection

none

Access Control: Trust All Traffic

trust (allow to its final destination without further inspection)

none

Intrusion Prevention

allow, as long as it is passed by the intrusion policy you specify (requires Protection)

intrusion, using the specified intrusion policy and associated variable set, and

discovery, using the network discovery policy

Network Discovery Only

allow

discovery only, using the network discovery policy

Tip The purpose of Network Discovery Only is to improve performance in a discovery-only deployment. Different configurations can disable discovery if you are only interested in intrusion detection and prevention. See IPS or Discovery-Only Performance Considerations for more information, including other guidelines you must follow.

When you first create an access control policy, logging connections that are handled by the default action is disabled by default. If you select a default action that performs intrusion inspection, the system automatically associates the default intrusion variable set with the intrusion policy you select. You can change either of these options, as well as the default action itself, after you create the policy.

To change an access control policy’s default action and related options:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select a Default Action.

- To block all traffic, select Access Control: Block All Traffic .

- To trust all traffic, select Access Control: Trust All Traffic .

- To allow all traffic and inspect it with network discovery, select Network Discovery Only .

- To inspect all traffic with both network discovery and intrusion policies, select an intrusion policy, all of which begin with the label Intrusion Prevention . Keep in mind that an intrusion policy can block traffic.

) to change the variable set associated with the intrusion policy you selected.

). If you do not change the variable set, the system uses a default set. For more information, see Working with Variable Sets.

) to change logging options for connections handled by the default action.

Depending on the default action, you can log a matching connection at its beginning, end, or both. You can log connections to the Defense Center database, external system log (syslog), or SNMP trap server. For more information, see Logging Connections Handled by the Access Control Default Action.

Setting Target Devices for an Access Control Policy

License: Any

Before you can apply an access control policy you must identify the managed devices where you want to apply the policy. You can identify the devices you want to target with your policy while creating a policy, or you can add them later.

Table 12-5 Targeted Device Management Actions

To...

You can...

search a list of available devices

click inside the search field, then type a search string. The list of devices updates as you type to display matching device names.

clear a search for available devices

) in the search field.

select available devices to add to the list of selected targets

click the device name; use the Ctrl and Shift keys to select multiple devices. You can also right-click an available device, then click Select All.

add selected devices

click Add to Policy or drag and drop into the list of selected devices.

delete a single device from the Selected Devices list

.

delete multiple devices from the Selected Devices list

use the Ctrl and Shift keys to select multiple devices, right-click to highlight the row for a selected device, then click Delete Selected.

Note that you cannot target stacked devices running different versions of the system (for example, if an upgrade on one of the devices fails). You can target a device stack, but not individual devices within the stack. See Managing Stacked Devices for more information.

To manage targeted devices in an access control policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Click the device targets link, then click Manage Targets.

The Manage Device Targets pop-up window appears.

Step 4 Build your target list.

Use the actions summarized in Table 12-5.

Step 5 Click OK.

Your configuration is added to the policy and the access control policy editor appears.

Managing Access Control Policies

License: Any

On the Access Control Policy page (Policies > Access Control) you can view your current custom access control policies, along with the following information, when appropriate:

- the number of devices using each access control policy to inspect traffic, including information on whether a policy is applied to only some of its targets, or is applied to a device not currently targeted by that policy

- the number of targeted devices where each policy is out of date, as well as information about who (if anyone) is currently editing each policy

In addition to custom policies that you create, the system can provide three custom policies: Default Access Control, Default Intrusion Prevention, and Default Network Discovery. The system creates these policies during initial device registration, depending on the detection modes you selected for your devices during their initial configuration. You can edit and use these system-provided custom policies. Note that a device’s detection mode is not a setting you can change later; it is simply an option you choose during setup that helps the system tailor that device’s initial configurations.

Options on the Access Control Policy page allow you to take the actions in the following table.

Table 12-6 Access Control Policy Management Actions

To...

You can...

See...

create a new access control policy

click New Policy.

Creating a Basic Access Control Policy

edit an existing access control policy

).

Editing Access Control Policies

reapply an access control policy to your managed devices

).

Applying an Access Control Policy

export an access control policy to import on another Defense Center

)

Exporting Configurations

view a PDF report that lists the current configuration settings in a access control policy

).

Generating a Report of Current Access Control Settings

compare access control policies

click Compare Policies.

Comparing Access Control Policies

delete an access control policy

), then confirm that you want to delete the policy. You cannot delete an applied access control policy or one that is currently applying.

Editing Access Control Policies

License: Any

When you first create a new access control policy, the access control policy editor appears, focused on the Rules tab. The following graphic shows a newly created policy. Because a new policy does not yet have rules or other configurations, the default action handles all traffic. In this case, the default action inspects unencrypted traffic with the system-provided Balanced Security and Connectivity intrusion policy before allowing it to its final destination. Note that by default, the system disables file and intrusion inspection on encrypted payloads.

Use the access control policy editor to add and organize rules, specify the devices that will use the policy, and so on. The following list provides information on the policy configurations you can change.

Name and Description

To change the policy’s name and description, click the appropriate field and type the new name or description.

Targets

Before you can apply an access control policy, use the Targets tab to identify the managed devices, including device groups, where you want to apply the policy. For more information, see Setting Target Devices for an Access Control Policy.

Security Intelligence

Security Intelligence is a first line of defense against malicious Internet content. This feature allows you to immediately blacklist (block) connections based on the latest reputation intelligence. To ensure continual access to vital resources, you can override blacklists with custom whitelists. This traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling, including rules and the default action. For more information, see Blacklisting Using Security Intelligence IP Address Reputation.

Rules

Rules provide a granular method of handling network traffic. Rules in an access control policy are numbered, starting at 1. The system matches traffic to access control rules in top-down order by ascending rule number.

In most cases, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. These conditions include security zone, network or geographical location, VLAN, port, application, requested URL, or user. Conditions can be simple or complex; their use often depends on certain licenses and appliance models.

Use the Rules tab to add, categorize, enable, disable, filter, and otherwise manage rules. For more information, see Tuning Traffic Flow Using Access Control Rules.

Default Action

The default action determines how the system handles traffic that is not blacklisted by Security Intelligence and does not match any access control rules. Using the default action, you can block or trust all traffic without further inspection, or inspect traffic for intrusions and discovery data. You can also select an custom variable set if you have created one, and enable or disable logging of connections handled by the default action.

For more information, see Setting Default Handling and Inspection for Network Traffic and Logging Connections Based on Access Control Handling.

HTTP Responses

You can specify what the user sees in a browser when the system blocks that user’s website request—either display a generic system-provided response page, or enter custom HTML. You can also display a page that warns users, but also allows them to click a button to continue or refresh the page to load the originally requested site. For more information, see Displaying a Custom Web Page for Blocked URLs.

Advanced Access Control Options

Advanced access control policy settings typically require little or no modification. The default settings are appropriate for most deployments. Advanced settings you can modify include:

– the number of characters you store in the Defense Center database for each URL requested by your users; see Logging URLs Detected in Connections

– the length of time before you re-block a website after a user bypasses an initial block; see Setting the User Bypass Timeout for a Blocked Website

– an SSL policy to monitor, decrypt, block, or allow application layer protocol traffic encrypted with Secure Socket Layer (SSL) or Transport Layer Security (TLS); see Applying Decryption Settings Using Access Control

– allow traffic inspection during policy apply or disable traffic inspection for secure connectivity; see Applying an Access Control Policy

– network analysis and intrusion policy settings that allow you to tailor many preprocessing options to networks, zones, and VLANs, as well as set default intrusion inspection behavior; see Customizing Traffic Preprocessing

– advanced transport and network preprocessor settings that apply globally to all networks, zones, and VLANs where you apply the access control policy; see Configuring Advanced Transport/Network Settings

– adaptive profiles to improve reassembly of packet fragments and TCP streams in passive deployments, based on your network’s host operating systems; see Tuning Preprocessing in Passive Deployments

– performance options for intrusion inspection, file control, file storage, dynamic analysis, and advanced malware protection; see Tuning Intrusion Prevention Performance and Tuning File and Malware Inspection Performance and Storage

When you edit an access control policy, a message indicates that you have unsaved changes. To retain your changes, you must save the policy before exiting the policy editor. If you attempt to exit the policy editor without saving your changes, you are cautioned that you have unsaved changes; you can then discard your changes and exit the policy, or return to the policy editor.

To protect the privacy of your session, after sixty minutes of inactivity on the policy editor, changes to your policy are discarded and you are returned to the Access Control Policy page. After the first thirty minutes of inactivity, a message appears and updates periodically to provide the number of minutes remaining before changes are discarded. Any activity on the page cancels the timer.

When you attempt to edit the same policy in two browser windows, you are prompted whether to resume your edit in the new window, discard your changes in the original window and continue editing in the new window, or cancel the second window and return to the policy editor.

When multiple users edit the same policy concurrently, a message for each on the policy editor identifies other users who have unsaved changes. Any user who attempts to save their changes is cautioned that their changes will overwrite changes by other users. When the same policy is saved by multiple users, the last saved changes are retained.

To edit an access control policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Edit your policy. Take any of the actions summarized above.

Step 4 Save or discard your configuration:

- To save your changes and continue editing, click Save.

- To save your changes and apply your policy, click Save and Apply . See Applying an Access Control Policy.

- To discard your changes, click Cancel and, if prompted, click OK .

Understanding Out-of-Date Policy Warnings

License: Any

On the Access Control Policy page (Policies > Access Control), out-of-date policies are marked with red status text that indicates how many of its targeted devices need a policy update.

In almost every case, whenever you change an access control policy, you must reapply it for the change to take effect. If the access control policy invokes other policies or relies on other configurations, changing those also requires that you reapply the access control policy (or, for intrusion policy changes, you can reapply just the intrusion policy).

Configuration changes that require a policy reapply include:

- Modifying the access control policy itself: any changes to access control rules, the default action, policy targets, Security Intelligence filtering, advanced options including NAP rules, and so on.

- Changing any of the policies that the access control policy invokes: the SSL policy, network analysis policies, intrusion policies, and file policies.

- Changing any reusable object or configuration used in the access control policy or the policies it invokes: network, port, VLAN tag, URL, and geolocation objects; Security Intelligence lists and feeds; application filters or detectors; intrusion policy variable sets; file lists; decryption-related objects, security zones, and so on.

- Updating the system software, intrusion rules, or the vulnerability database (VDB).

Keep in mind that you can change some of these configurations from multiple places in the web interface. For example, you can modify security zones using the object manager (Objects > Object Management), but modifying an interface type in a device’s configuration (Devices > Device Management) can also change a zone and require a policy reapply.

Note that the following updates do not require policy reapply:

- automatic updates to Security Intelligence feeds and additions to the Security Intelligence global blacklist or whitelist using the context menu

- automatic updates to URL filtering data

- scheduled geolocation database (GeoDB) updates

To determine why an access control or intrusion policy is out of date, use the comparison viewer.

To determine why an access control policy is out of date:

Access: Admin/Security Approver

Step 1 Select Policies > Access Control.

The Access Control Policy page appears. Policies that are out of date are marked with red status text that indicates how many of its targeted devices need a policy update.

Step 2 Click the policy status for an out-of-date policy.

The detailed Apply Access Control Policy pop-up window appears.

Step 3 Click Out-of-date next to the changed component you are interested in.

A policy comparison report appears in a new window. For more information, see Comparing Access Control Policies and Comparing Two Intrusion Policies or Revisions.

Step 4 Optionally, reapply the policy.

See the next section, Applying an Access Control Policy.

Applying an Access Control Policy

License: Any

After you change an access control policy, you must apply the policy to one or more target devices to implement the change on the networks monitored by the devices. Although you can apply any combination of an access control policy and its associated intrusion policies, applying an access control policy automatically applies all associated SSL, network analysis, and file policies. You cannot apply these policies independently.

Caution When you apply an access control policy, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic.

Tip If you are using Cisco NGIPS for Blue Coat X-Series deployed inline and you configure a multi-VAP VAP group for load-balancing and redundancy, you can avoid processing pauses by removing the affected VAP from the load-balanced list until the device restarts, then reinstate it.

Note that only devices deployed inline can affect the flow of traffic. Applying an access control policy configured to block or alter traffic to passively deployed devices can have unexpected results. For example, because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.

In some cases, the system prevents you from applying inline configurations to passively deployed devices, including inline devices in tap mode. For example, in an passive deployment, you cannot apply an access control policy that references an SSL policy that blocks encrypted traffic, or that is configured to re-sign decrypted traffic. Also, passive deployments do not support decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve Diffie-Hellman (ECDHE) cipher suites.

Keep the following additional points in mind when applying access control policies:

- Some features require specific licenses, minimum versions of the system, or specific device models. For more information, see License and Model Requirements for Access Control, as well as the release notes for the version of the system you are running on your managed devices. If an access control policy requires licenses enabled through recently applied device configurations, the system queues the access control policy apply until the device configurations finish applying.

- You cannot apply an access control policy to stacked devices running different versions of the system (for example, if an upgrade on one of the devices fails).

- When you apply an access control policy, the system evaluates all the rules together and creates an expanded set of criteria that target devices use to evaluate network traffic. A pop-up window may warn that you have exceeded the maximum number of access control rules or intrusion policies supported by a target device. This maximum depends on a number of factors, including the physical memory and the number of processors on the device. On devices with less computing resources, note that limited memory may require that you select as few as three intrusion policies across an entire access control policy. For more information, see Simplifying Rules to Improve Performance.

- If you are performing application control, at least one detector must be enabled for each application used as a criterion in either an access control or SSL rule. If no detector is enabled for an application, the system automatically enables all system-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

- When you import an intrusion rule update, you can automatically reapply access control and intrusion policies after the import completes. This allows you to use the most up-to-date intrusion rules and advanced settings, as well as preprocessor rules and preprocessor settings. This is especially useful if you allow rule updates to modify system-provided base policies. Note that rule updates can also modify default values for the advanced preprocessing and performance options in your access control policies. For more information, see Importing Rule Updates and Local Rule Files.

- On devices with limited memory, the number of intrusion policies may not be paired with more than one variable set. In the case where you can apply an access control policy that references only one intrusion policy, verify every reference to the intrusion policy is paired with the same variable set.

See the following sections for more information:

- Applying a Complete Policy explains how to use the quick-apply option to apply the access control policy along with all associated SSL, network analysis, intrusion, and file policies.

- Applying Selected Policy Configurations explains how to apply specific access control policy configurations, including individual intrusion policies.

Applying a Complete Policy

License: Any

Supported Devices:

You can apply an access control policy to its target devices at any time. Applying an access control policy also applies any associated policies that are different from those currently running:

- SSL policy

- network analysis policies

- intrusion policies

- file policies

A pop-up window allows you to apply all together as a single quick-apply action. Unchanged policies are not applied when you use the quick-apply option.

The label for the apply button on the quick-apply pop-up window can differ depending on whether you are permitted to apply an access control policy, intrusion policy, or both; see Managing Your Deployment with Custom User Roles.

To quick-apply a complete access control policy:

Access: Admin/Security Approver

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the policy you want to apply.

The Apply Access Control Policy pop-up window appears.

Alternatively, you can click Save and Apply while editing a policy; see Editing Access Control Policies.

Step 3 Click Apply All.

Your policy apply task is queued. Click OK to return to the Access Control Policy page. You can monitor the progress of the policy apply task on the Task Status page (System > Monitoring > Task Status).

Applying Selected Policy Configurations

License: Any

You can use the detailed policy apply page to apply changes to your access control policy and to any associated intrusion policies. The detailed page lists each device targeted by the policy and provides a column for the access control policy by device, and a column for associated intrusion policies by device. You can specify whether to apply changes to an access control policy, to associated intrusion policies individually or in combination, or both, for each targeted device.

You must apply both an access control policy and an associated intrusion policy in either of the following cases:

- when the access control policy is being applied to the device for the first time

- when an intrusion policy has been newly added to the access control policy

In both cases, the states of the access control policy and the intrusion policies are linked; that is, you must apply both or neither.

Note that regardless of the intrusion policies you apply, applying an access control policy automatically applies all associated SSL, network analysis, and file policies that are different from those currently running on devices targeted by the policy. You cannot apply these policies independently.

The Access Control Policy Column

The Access Control Policy column provides a check box for indicating whether to apply the access control policy.

Tip Although you can reapply a policy while it is still in the task queue, that is, while the apply task has not yet completed, there is no benefit in doing this.

A status message indicates whether the policy is currently up to date or out of date. When the policy is out of date, you can conveniently display a comparison of the policy to the currently running policy in a new browser window. The comparison does not include differences in an intrusion policy associated with the access control policy.

The Intrusion Policies Column

The Intrusion Policies column provides one or more check boxes for indicating whether to apply intrusion policies associated with the access control policy to a device. A single grayed check box indicates that all associated intrusion policies are identical to currently running policies, in which case the check box is cleared and cannot be selected. You cannot apply an unchanged intrusion policy; only changed intrusion policies are listed, and can be selected individually. When the same intrusion policy is associated with multiple rules in a policy, the intrusion policy is listed only once for each device.

The check box for an intrusion policy is selected and the check box is grayed and cannot be changed when the access control policy and the intrusion policy must be applied together, as described above, in either of the following cases:

- when the access control policy is being applied to the device for the first time

- when an intrusion policy has been newly added to the access control policy

Status messages indicate whether intrusion policies are currently up to date or out of date. An intrusion policy is out of date when it is not identical to an intrusion policy currently running on the listed device. An identical intrusion policy on the device is up to date. When the policy is out of date, you can conveniently display a comparison of the policy to the currently running policy in a new browser window.

To apply selected access control policy configurations:

Access: Admin/Security Approver

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the policy you want to apply.

The Apply Access Control Policy pop-up window appears.

Alternatively, you can click Save and Apply while editing a policy; see Editing Access Control Policies.

Step 3 Click Details.

The detailed Apply Access Control Policy pop-up window appears. Note that you can also open the pop-up window from the Access Control Policy page (Policies > Access Control) by clicking on an out-of-date message in the Status column for the policy.

Step 4 Select or clear the access control policy check box next to the device name to specify whether to apply the access control policy to a targeted device.

Step 5 Select or clear the intrusion policy check box next to the device name to specify whether to apply an intrusion policy to a targeted device.

Step 6 Click Apply Selected Configurations.

Your policy apply task is queued. Click OK to return to the Access Control Policy page.

Note that a pop-up window may warn that you have exceeded the maximum number of intrusion policies supported by the device. You must reevaluate your access control policy and consolidate intrusion policies. You cannot apply the access control policy until the number of associated intrusion policies (including the default action) falls within the maximum.

You can monitor the progress of the policy apply task on the Task Status page (System > Monitoring > Task Status).

Traffic Inspection During Access Control Policy Apply

- When you enable Inspect traffic during policy apply :

– Certain configurations can require the Snort process to restart.

– When the configurations you apply do not require a Snort restart, the system initially uses the currently applied access control policy to inspect traffic, and switches during the application process to the policy you are applying

- When you disable Inspect traffic during policy apply , the Snort process always restarts when you apply the policy.

- How a Snort restart affects traffic depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic.

IPS or Discovery-Only Performance Considerations

License: FireSIGHT or Protection

A FireSIGHT license is included with your Defense Center and allows you to perform host, application, and user discovery. Discovery data allows the system to create a complete, up-to-the-minute profile of your network. With Protection licenses applied to your managed devices, the system can act as an intrusion detection and prevention system (IPS). You can analyze network traffic for intrusions and exploits and, optionally, drop offending packets.

Combining discovery and IPS gives context to your network activity and allows you to take advantage of many features, including:

- impact flags and indications of compromise, which can tell you which of your hosts are vulnerable to a particular exploit, attack, or piece of malware

- adaptive profiles and FireSIGHT recommendations, which allow you to examine traffic differently depending on the destination host

- correlation, which allows you to respond to intrusions (and other events) differently depending on the affected host

However, if your organization is interested in performing only IPS, or only discovery, there are a few configurations that can optimize the performance of the system, as described in the following sections:

- Optimizing a Network Discovery-Only Deployment

- Performing Intrusion Detection and Prevention without Discovery

Optimizing a Network Discovery-Only Deployment

License: FireSIGHT

The discovery feature allows you to monitor network traffic and determine the number and types of hosts (including network devices) on your network, as well as the operating systems, active applications, and open ports on those hosts. You can also configure managed devices and User Agents to monitor user activity on your network. You can use discovery data to perform traffic profiling, assess network compliance, and respond to policy violations.

In a basic deployment (discovery and simple, network-based access control only), you can improve a device’s performance by following a few important guidelines when configuring its access control policy.

Note You must apply an access control policy, even if it simply allows all traffic. The network discovery policy can only examine traffic that the access control policy allows to pass.

First, make sure your access control policy does not require complex processing and uses only simple, network-based criteria to handle network traffic. You must implement all of the following guidelines; misconfiguring any one of these options eliminates the performance benefit:

- Do not use the Security Intelligence feature. Remove any populated global whitelist or blacklist from the policy’s Security Intelligence configuration.

- Do not include access control rules with Monitor or Interactive Block actions. Use only Allow, Trust, and Block rules. Keep in mind that allowed traffic can be inspected by discovery; trusted and blocked traffic cannot.

- Do not include access control rules with application, user, URL, or geolocation-based network conditions, even if your devices are appropriately licensed. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.

- Do not include access control rules that perform file, malware, or intrusion inspection, even if your devices are appropriately licensed. In other words, do not associate a file policy or intrusion policy with any access control rule.

- Make sure that the default intrusion policy for the access control policy is set to No Rules Active ; see Setting the Default Intrusion Policy for Access Control.

- Select Network Discovery Only as the policy’s default action. Do not choose a default action for the policy that performs intrusion inspection.

Note that with the exception of geolocation-based access control, the options described above require at least a Protection license. If you have only a FireSIGHT license, the system prevents you from applying an access control policy using these features.

After you configure and apply the access control policy, you can configure and apply the network discovery policy, which specifies the network segments, ports, and zones that the system examines for discovery data, as well as whether hosts, applications, and users are discovered on the segments, ports, and zones.

Performing Intrusion Detection and Prevention without Discovery

License: Protection

The intrusion detection and prevention feature allows you to analyze network traffic for intrusions and exploits and, optionally, drop offending packets. If you want to perform intrusion inspection but do not need to take advantage of discovery data, you can improve a device’s performance by disabling discovery.

Note If you are performing application, user, or URL control, you cannot disable discovery for a performance benefit. Although you can prevent the system from storing it, the system must collect and examine discovery data to implement those features.

To disable discovery, implement all of the following guidelines; misconfiguring any eliminates the performance benefit:

- In your access control policy, do not include rules with application, user, URL, or geolocation-based network conditions, even if your devices are appropriately licensed. Use only simple network-based conditions: zone, IP address, VLAN tag, and port.

- Delete all rules from your network discovery policy.

After you apply the access control policy and then the network discovery policy, new discovery halts on target devices. The system gradually deletes information in your network map according to the timeout periods you specified in the network discovery policy. Or, you can purge all discovery data immediately, see Purging Discovery Data from the Database.

Troubleshooting Access Control Policies and Rules

License: Any

Properly configuring access control policies, especially creating and ordering access control rules, is a complex task. However, it is a task that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules or contain invalid configurations. Both rules and other policy settings can require additional licenses.

To help ensure that the system handles traffic as you expect, the access control policy interface has a robust feedback system. Icons in the access control policy and rule editors mark warnings and errors, as described in the Access Control Error Icons table. Hover your pointer over an icon to read the warning, error, or informational text.

Tip In the access control policy editor, click Show Warnings to display a pop-up window that lists all the warnings for the policy.

Table 12-7 Access Control Error Icons

Icon

Description

Details

error

If a rule or configuration has an error, you cannot apply the policy until you correct the issue, even if you disable any affected rules.

warning

You can apply an access control policy that displays rule or other warnings. However, misconfigurations marked with warnings have no effect.

For example, you can apply a policy that contains preempted rules or rules that cannot match traffic due to misconfiguration—conditions using empty object groups, application filters that match no applications, configuring URL conditions without having enabled cloud communications, and so on. These rules do not evaluate traffic. If you disable a rule with a warning, the warning icon disappears. It reappears if you enable the rule without correcting the underlying issue.

As another example, many features require a specific license or device model. An access control policy successfully applies only to eligible target devices.

information

Information icons convey helpful information about configurations that may affect the flow of traffic. These issues do not prevent you from applying the policy.

For example, if you are performing application control or URL filtering, the system may skip matching the first few packets of a connection against some access control rules, until the system identifies the application or web traffic in that connection. This allows connections to be established so that applications and HTTP requests can be identified. For more information, see Limitations to Application Control and Limitations to URL Detection and Blocking.

Properly configuring access control policies and rules can also reduce the resources required to process network traffic. Creating complex rules, invoking many different intrusion policies, and mis-ordering rules can all affect performance.

For more information, see:

- Access Control License and Role Requirements

- Simplifying Rules to Improve Performance

- Understanding Rule Preemption and Invalid Configuration Warnings

- Ordering Rules to Improve Performance and Avoid Preemption

Simplifying Rules to Improve Performance

Complex access control policies and rules can command significant resources. When you apply an access control policy, the system evaluates all the rules together and creates an expanded set of criteria that target devices use to evaluate network traffic. A pop-up window may warn that you have exceeded the maximum number of access control rules or intrusion policies supported by a target device. This maximum depends on a number of factors, including the physical memory and the number of processors on the device.

Simplifying Access Control Rules

The following guidelines can help you simplify access control rules and improve performance:

- When constructing a rule, use as few individual elements in your conditions as possible. For example, in network conditions, use IP address blocks rather than individual IP addresses. In port conditions, use port ranges. Use application filters and URL categories and reputations to perform application control and URL filtering, and LDAP user groups to perform user control.

Note that combining elements into objects that you then use in access control rule conditions does not improve performance. For example, using a network object that contains 50 individual IP addresses gives you only an organizational—not a performance—benefit over including those IP addresses in the condition individually.

- Restrict rules by security zones whenever possible. If a device’s interfaces are not in one of the zones in a zone-restricted rule, the rule does not affect performance on that device.

- Do not overconfigure rules. If one condition is enough to match the traffic you want to handle, do not use two.

Avoiding Intrusion Policy and Variable Set Proliferation

The number of unique intrusion policies you can use to inspect traffic in an access control policy depends on the resources on your device and the complexity of your policies: you can associate one intrusion policy with each Allow and Interactive Block rule, as well as with the default action. Every unique pair of intrusion policy and variable set counts as one policy.

If you exceed the number of intrusion policies supported by your device, reevaluate your access control policy. You may want to consolidate intrusion policies or variable sets so you can associate a single intrusion policy-variable set pair with multiple access control rules.

Check to see how many policies you select and how many variable sets those policies use in each of the following locations in your access control policy: the Intrusion Policy used before Access Control rule is determined option in the Advanced access control policy settings, the default action for the access control policy, and the inspection settings for any access control rules in the policy.

Understanding Rule Preemption and Invalid Configuration Warnings

License: Any

Properly configuring and ordering access control rules (and, in advanced deployments, network analysis rules) is essential to building an effective deployment. Within an access control policy, access control rules can preempt other rules or contain invalid configurations. Similarly, network analysis rules, which you configure using the access control policy’s advanced settings, can have the same issues. The system uses warning and error icons to mark these.

Understanding Rule Preemption Warnings

The conditions of an access control rule may preempt a subsequent rule from matching traffic. For example:

Rule 1: allow Admin users

Rule 2: block Admin users

The second rule above will never block traffic because the first rule will have already allowed the traffic.

Any type of rule condition can preempt a subsequent rule. For example, the VLAN range in the first rule below includes the VLAN in the second rule, so the first rule preempts the second rule:

Rule 1: allow VLAN 22-33

Rule 2: block VLAN 27

In the following example, Rule 1 matches any VLAN because no VLANs are configured, so Rule 1 preempts Rule 2, which attempts to match VLAN 2:

Rule 1: allow Source Network 10.4.0.0/16

Rule 2: allow Source Network 10.4.0.0/16, VLAN 2

A rule also preempts an identical subsequent rule where all configured conditions are the same. For example:

Rule 1: allow VLAN 1 URL www.example.com

Rule 2: allow VLAN 1 URL www.example.com

A subsequent rule would not be preempted if any condition is different. For example:

Rule 1: allow VLAN 1 URL www.example.com

Rule 2: allow VLAN 2 URL www.example.com

Understanding Invalid Configuration Warnings

Because outside settings that the access control policy depends on may change, an access control policy setting that was valid may become invalid. Consider the following examples:

- A rule that performs URL filtering might be valid until you target a device that does not have a URL Filtering license. At that point, an error icon appears next to the rule, and you cannot apply the policy to that device until you edit or delete the rule, retarget the policy, or enable the appropriate license.

- If you add a port group to the source ports in a rule, then change the port group to include an ICMP port, the rule becomes invalid and a warning icon appears next to it. You can still apply the policy, but the rule will have no effect on network traffic.

- If you add a user to a rule, then change your LDAP user awareness settings to exclude that user, the rule will have no effect because the user is no longer an access controlled user.

Ordering Rules to Improve Performance and Avoid Preemption

License: Any

Rules in an access control policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Proper access control rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs.

Order Rules from Most to Least Critical

First, you must order rules to suit your organization's needs. Place priority rules that must apply to all traffic near the top of the policy. For example, if you want to inspect traffic from a single user for intrusions (using an Allow rule), but trust all other users in the department (using a Trust rule), place two access control rules in that order.

Order Rules from Specific to General

You can improve performance by placing specific rules earlier, that is, rules that narrowly define the traffic they handle. This is also important because rules with broad conditions can match many different types of traffic, and can preempt later, more specific rules.

Consider a scenario where you want to block most social networking sites, but allow access to certain others. For example, you may want your graphic designers to be able to access Creative Commons Flickr and deviantART content, but not access other sites such as Facebook or Google+. You should order your rules as follows:

Rule 1: Allow Flickr, deviantART for the “Design” LDAP user group

Rule 2: Block social networking

If you reverse the rules:

Rule 1: Block social networking

Rule 2: Allow Flickr, deviantART for the “Design” LDAP user group

the first rule blocks all social networking traffic, including Flickr and deviantART. Because no traffic will ever match the second rule, your designers cannot access the content you wanted to make available.

Place Rules that Inspect Traffic Later

Because discovery, intrusion, file, and malware inspection require processing resources, placing rules that do not inspect traffic (Trust, Block) before rules that do (Allow, Interactive Block) can improve performance. This is because Trust and Block rules can divert traffic that the system might otherwise have inspected. All other factors being equal, that is, given a set of rules where none is more critical and preemption is not an issue, consider placing them in the following order:

- Monitor rules that log matching connections, but take no other action on traffic

- Trust and Block rules that handle traffic without further inspection

- Allow and Interactive Block rules that do not inspect traffic further

- Allow and Interactive Block rules that optionally inspect traffic for malware, intrusions, or both

Generating a Report of Current Access Control Settings

License: Any

Table 12-8 Access Control Policy Report Sections

Section

Description

Policy Information

Provides the name and description of the policy, the name of the user who last modified the policy, and the date and time the policy was last modified.

Device Targets

Lists the managed devices targeted by the policy.

HTTP Block Response

HTTP Interactive Block Response

Provides details on the pages you display to users when you block a website using the policy.

Security Intelligence

Provides details on the policy’s Security Intelligence whitelist and blacklist.

Default Action

Lists the default action and associated variable set, if any.

Rules

Lists each access control rule in the policy, and provides details about its configuration.

Advanced Settings

Detailed information on the policy’s advanced settings, including:

- network analysis policies used to preprocess traffic for the access control policy, as well as global preprocessing options

- adaptive profile settings for passive deployments

- performance settings for detecting files, malware, and intrusions

- other policy-wide settings

Referenced Objects

Provides details on the reusable objects referenced by the access control policy, including intrusion policy variable sets and objects used by the SSL policy.

You can also generate an access control comparison report that compares a policy with the currently applied policy or with another policy. For more information, see Comparing Access Control Policies.

To view an access control policy report:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the policy for which you want to generate a report. Remember to save any changes before you generate an access control policy report; only saved changes appear in the report.

The system generates the report. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Comparing Access Control Policies

License: Any

To review policy changes for compliance with your organization’s standards or to optimize system performance, you can examine the differences between two access control policies. You can compare any two policies or the currently applied policy with another policy. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies.

There are two tools you can use to compare policies:

- The comparison view displays only the differences between two policies in a side-by-side format. The name of each policy appears in the title bar on the left and right sides of the comparison view except when you select Running Configuration , in which case a blank bar represents the currently active policy.

You can use this to view and navigate both policies on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two policies in a format similar to the policy report, but in PDF format.

You can use this to save, copy, print, and share your policy comparisons for further examination.

For more information on understanding and using the policy comparison tools, see:

- Using the Access Control Policy Comparison View

- Using the Access Control Policy Comparison Report

Using the Access Control Policy Comparison View

License: Any

The comparison view displays both policies in a side-by-side format, with each policy identified by name in the title bar on the left and right sides of the comparison view. When comparing two policies other than the running configuration, the time of last modification and the last user to modify are displayed with the policy name.

Differences between the two policies are highlighted:

- Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy but not the other.

You can perform any of the actions in the following table.

Table 12-9 Access Control Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a new policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the Access Control Policy Comparison Report for more information.

generate a policy comparison report

click Comparison Report.

The policy comparison report creates a PDF document that lists only the differences between the two policies.

Using the Access Control Policy Comparison Report

License: Any

An access control policy comparison report is a record of all differences between two access control policies or a policy and the currently applied policy identified by the policy comparison view, presented in PDF format. You can use this report to further examine the differences between two policy configurations and to save and disseminate your findings.

You can generate an access control policy comparison report from the comparison view for any policies to which you have access. Remember to save any changes before you generate a policy report; only saved changes appear in the report.

The format of the policy comparison report is the same as the policy report with one exception: the policy report contains all configurations in the policy, and the policy comparison report lists only those configurations that differ between the policies. An access control policy comparison report contains the sections described in Table 12-8.

Tip You can use a similar procedure to compare SSL, network analysis, intrusion, file, system, or health policies.

To compare two access control policies:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

The page refreshes and the Policy A and Policy B drop-down lists appear.

- To compare another policy to the currently active policy, select Running Configuration.

The page refreshes and the Target/Running Configuration A and Policy B drop-down lists appear.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing the running configuration to another policy, select the second policy from the Policy B drop-down list.

Step 5 Click OK to display the policy comparison view.

The comparison view appears.

Step 6 Optionally, click Comparison Report to generate the access control policy comparison report.

The access control policy comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Blacklisting Using Security Intelligence IP Address Reputation

As a first line of defense against malicious Internet content, the FireSIGHT System includes the Security Intelligence feature, which allows you to immediately blacklist (block) connections based on the latest reputation intelligence, removing the need for a more resource-intensive, in-depth analysis. Security Intelligence filtering requires a Protection license and is supported on all managed devices with the exception of Series 2.

Security Intelligence works by blocking traffic to or from IP addresses that have a known bad reputation. This traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling (although it does occur after hardware-level handling, such as fast-pathing).

Note that you could create access control rules that perform a similar function to Security Intelligence filtering by manually restricting traffic by IP address. However, access control rules are wider in scope, more complex to configure, and cannot automatically update using dynamic feeds.

Traffic blacklisted by Security Intelligence is immediately blocked and therefore is not subject to any further inspection—not for intrusions, exploits, malware, and so on, but also not for network discovery. Optionally, and recommended in passive deployments, you can use a “monitor-only” setting for Security Intelligence filtering. This allows the system to analyze connections that would have been blacklisted, but also logs the match to the blacklist and generates an end-of-connection security intelligence event.

Caution For traffic handled by Series 3 devices, the system processes certain Trust rules before an access control policy’s Security Intelligence blacklist, which can allow blacklisted traffic to pass uninspected. For more information, see Limitations to Trusting or Blocking Traffic with Series 3 Devices.

For your convenience, Cisco provides the Intelligence Feed (sometimes called the Sourcefire Intelligence Feed), which is comprised of several regularly updated collections of IP addresses determined by the VRT to have a poor reputation. The Intelligence Feed tracks open relays, known attackers, bogus IP addresses (bogon), and so on. You can also customize the feature to suit the unique needs of your organization, for example:

- third-party feeds —you can supplement the Intelligence Feed with third-party reputation feeds, which the system can automatically update just as it does the Cisco feed

- custom blacklists —the system allows you to manually blacklist specific IP addresses in many ways depending on your needs

- enforcing blacklisting by security zone —to improve performance, you may want to target enforcement, for example, restricting spam blacklisting to a zone that handles email traffic

- monitoring instead of blacklisting —especially useful in passive deployments and for testing feeds before you implement them; you can merely monitor the violating sessions instead of blocking them, generating end-of-connection events

- whitelisting to eliminate false positives — when a blacklist is too broad in scope, or incorrectly blocks traffic that you want to allow (for example, to vital resources), you can override a blacklist with a custom whitelist

For detailed information on configuring your access control policy to perform Security Intelligence filtering and viewing the event data that this filtering produces, see the following sections:

- Choosing a Security Intelligence Strategy

- Building the Security Intelligence Whitelist and Blacklist

- Logging Security Intelligence (Blacklisting) Decisions

- Working with Connection & Security Intelligence Data

Choosing a Security Intelligence Strategy

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

The easiest way to construct a blacklist is to use the Intelligence Feed, which tracks IP addresses known to be open relays, known attackers, bogus IP addresses (bogon), and so on. Because the Intelligence Feed is regularly updated, using it ensures that the system uses up-to-date information to filter your network traffic. Malicious IP addresses that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and apply new policies.

To augment the Intelligence Feed, you can perform Security Intelligence filtering using custom or third-party IP address lists and feeds, where:

- a list is a static list of IP addresses that you upload to the Defense Center

- a feed is a dynamic list of IP addresses that the Defense Center downloads from the Internet on a regular basis; the Intelligence Feed is a special kind of feed

For detailed information on configuring Security Intelligence lists and feeds, including high availability and Internet access requirements, see Working with Security Intelligence Lists and Feeds.

Using the Security Intelligence Global Blacklist

In the course of your analysis, you can build a global blacklist by selecting any IP address in an event view, the Context Explorer, or a dashboard. For example, if you notice a set of routable IP addresses in intrusion events associated with exploit attempts, you can immediately blacklist those IP addresses. The Defense Center uses this global blacklist (and a related global whitelist) to perform Security Intelligence filtering in all access control policies. For information on managing these global lists, see Working with the Global Whitelist and Blacklist.

Note Although feed updates and additions to the global blacklist (or global whitelist; see below) automatically implement changes throughout your deployment, any other change to a Security Intelligence object requires you to reapply the access control policy. For more information, see Table 3-1.

Using Network Objects

Finally, a simple way to construct a blacklist is to use network objects or network object groups that represent an IP address, IP address block, or collection of IP addresses. For information on creating and modifying network objects, see Working with Network Objects.

Using Security Intelligence Whitelists

In addition to a blacklist, each access control policy has an associated whitelist, which you can also populate with Security Intelligence objects. A policy’s whitelist overrides its blacklist. That is, the system evaluates traffic with a whitelisted source or destination IP address using access control rules, even if the IP address is also blacklisted. In general, use the whitelist if a blacklist is still useful, but is too broad in scope and incorrectly blocks traffic that you want to inspect.

For example, if a reputable feed improperly blocks your access to vital resources but is overall useful to your organization, you can whitelist only the improperly classified IP addresses, rather than removing the whole feed from the blacklist.

Enforcing Security Intelligence Filtering by Security Zone

For added granularity, you can enforce Security Intelligence filtering based on whether the source or destination IP address in a connection resides in a particular security zone.

To extend the whitelist example above, you could whitelist the improperly classified IP addresses, but then restrict the whitelist object using a security zone used by those in your organization who need to access those IP addresses. That way, only those with a business need can access the whitelisted IP addresses. As another example, you could use a third-party spam feed to blacklist traffic on an email server security zone.

Monitoring—Rather than Blacklisting—Connections

If you are not sure whether you want to blacklist a particular IP address or set of addresses, you can use a “monitor-only” setting, which allows the system to pass the matching connection to access control rules, but also logs the match to the blacklist and generates an end-of-connection Security Intelligence event. Note that you cannot set the global blacklist to monitor-only. For more information, see

Consider a scenario where you want to test a third-party feed before you implement blocking using that feed. When you set the feed to monitor-only, the system allows connections that would have been blocked to be further analyzed by the system, but also logs a record of each of those connections for your evaluation.

In passive deployments, to optimize performance, Cisco recommends that you always use monitor-only settings. Managed devices that are deployed passively cannot affect traffic flow; there is no advantage to configuring the system to block traffic. Additionally, because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.

Building the Security Intelligence Whitelist and Blacklist

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

To build a whitelist and blacklist, you populate them with any combination of network objects and groups, as well as Security Intelligence feeds and lists, all of which you can constrain by security zone.

Caution Changing a Security Intelligence list, except via the Whitelist Now or Blacklist Now options from the right-click menu, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

By default, access control policies use the Defense Center’s global whitelist and blacklist, which apply to any zone. These lists are populated by your analysts, who can quickly add individual IP addresses using the context menu. You can opt not to use these global lists on a per-policy basis.

Note You cannot apply an access control policy that uses a populated global whitelist or blacklist to Series 2 devices (or to other devices not licensed for Protection). If you added IP addresses to either global list, you must remove the non-empty list from the policy’s Security Intelligence configuration before you can apply the policy. For more information, see Working with the Global Whitelist and Blacklist.

After you build your whitelist and blacklist, you can log blacklisted connections. You can also set individual blacklisted objects, including feeds and lists, to monitor-only. This allows the system to handle connections involving blacklisted IP addresses using access control, but also logs the connection’s match to the blacklist.

) represent the different categories in the Intelligence Feed.

Active scanners and blacklisted hosts known for outbound malicious activity

Malware

Sites that host malware binaries or exploit kits

Phishing

Sites that host phishing pages

Spam

Mail hosts that are known for sending spam

Bots

Sites that host binary malware droppers

CnC

Sites that host command and control servers for botnets

OpenProxy

Open proxies that allow anonymous web browsing

OpenRelay

Open mail relays that are known to be used for spam

TorExitNode

Tor exit nodes

Bogon

Bogon networks and unallocated IP addresses

). Because the whitelist overrides the blacklist, if you add the same object to both lists, the system displays the blacklisted object with a strikethrough.

You can add up to a total of 255 objects to the whitelist and the blacklist. That is, the number of objects in the whitelist plus the number in the blacklist cannot exceed 255.

Note that although you can add network objects with a netmask of /0 to the whitelist or blacklist, address blocks using a /0 netmask in those objects will be ignored and whitelist and blacklist filtering will not occur based on those addresses. Address blocks with a /0 netmask from Security Intelligence feeds are also ignored. If you want to monitor or block all traffic targeted by a policy, use an access control rule with the Monitor or Block rule action, respectively, and a default value of any for the Source Networks and Destination Networks, instead of Security Intelligence filtering.

To build the Security Intelligence whitelist and blacklist for an access control policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select the Security Intelligence tab.

Security Intelligence settings for the access control policy appear.

) to log blacklisted connections.

You must enable logging before you can set blacklisted objects to monitor-only. For details, see Logging Security Intelligence (Blacklisting) Decisions.

Step 5 Begin building your whitelist and blacklist by selecting one or more Available Objects.

Use Shift and Ctrl to select multiple objects, or right-click and Select All.

Tip You can search for existing objects to include, or create objects on the fly if no existing objects meet the needs of your organization. For more information, see Searching for Objects to Whitelist or Blacklist and Creating Objects to Whitelist or Blacklist.

Step 6 Optionally, constrain the selected objects by zone by selecting an Available Zone.

By default, objects are not constrained, that is, they have a zone of Any. Note that other than using Any, you can constrain by only one zone. To enforce Security Intelligence filtering for an object on multiple zones, you must add the object to the whitelist or blacklist separately for each zone. Also, the global whitelist or blacklist cannot be constrained by zone.

Step 7 Click Add to Whitelist or Add to Blacklist.

You can also click and drag the selected objects to either list.

The objects you selected are added to the whitelist or blacklist.

Step 8 Repeat steps 5 through 7 until you are finished adding objects to your whitelist and blacklist.

Step 9 Optionally, set blacklisted objects to monitor-only by right-clicking the object under Blacklist, then selecting Monitor-only (do not block).

In passive deployments, Cisco recommends you set all blacklisted objects to monitor-only. Note, however, that you cannot set the global blacklist to monitor-only.

Step 10 Click Save.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Searching for Objects to Whitelist or Blacklist

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

If you have multiple network objects, groups, feeds, and lists, use the search feature to narrow the objects you want to blacklist or whitelist.

To search for objects to whitelist or blacklist:

Access: Admin/Access Admin/Network Admin

Step 1 Type your query in the Search by name or value field.

) in the search field.

You can search on network object names and on the values configured for those objects. For example, if you have an individual network object named Texas Office with the configured value 192.168.3.0/24, and the object is included in the group object US Offices, you can display both objects by typing a partial or complete search string such as Tex, or by typing a value such as 3.

Creating Objects to Whitelist or Blacklist

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

While editing an access control policy, you can create an object on-the-fly to use in its whitelist and blacklist: either a network object or a Security Intelligence list or feed. Note that to group network objects or create network object groups, you must use the object manager.

To create objects to whitelist or blacklist:

Access: Admin/Access Admin/Network Admin

), then select the type of object you want to create:

- Select Add IP List to create a Security Intelligence list or feed; see Working with Security Intelligence Lists and Feeds.

- Select Add Network Object to add a network object; see Working with Network Objects.

Tuning Traffic Flow Using Access Control Rules

Within an access control policy, access control rules provide a granular method of handling network traffic across multiple managed devices.

Note Hardware-based fast-path rules, Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network traffic is evaluated by access control rules. You can also configure the SSL inspection feature to block or decrypt encrypted traffic before access control rules evaluate it.

The system matches traffic to access control rules in the order you specify. In most cases, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, and user.

Each rule also has an action, which determines whether you monitor, trust, block, or allow matching traffic. When you allow traffic, you can specify that the system first inspect it with intrusion or file policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network. However, after the system trusts or blocks traffic, it does not perform further inspection.

In this scenario, traffic is evaluated as follows:

- Rule 1: Monitor evaluates traffic first. Monitor rules track and log network traffic but do not affect traffic flow. The system continues to match traffic against additional rules to determine whether to permit or deny it.

- Rule 2: Trust evaluates traffic next. Matching traffic is allowed to pass to its destination without further inspection. Traffic that does not match continues to the next rule.

- Rule 3: Block evaluates traffic third. Matching traffic is blocked without further inspection. Traffic that does not match continues to the final rule.

- Rule 4: Allow is the final rule. For this rule, matching traffic is allowed; however, prohibited files, malware, intrusions, and exploits within that traffic are detected and blocked. Remaining non-prohibited, non-malicious traffic is allowed to its destination. Note that you might have additional Allow rules that perform only file inspection, or only intrusion inspection, or neither.

- Default Action handles all traffic that does not match any of the rules. In this scenario, the default action performs intrusion prevention before allowing non-malicious traffic to pass. In a different deployment, you might have a default action that trusts or blocks all traffic, without further inspection. (You cannot perform file or malware inspection on traffic handled by the default action.)

Traffic you allow, whether with an access control rule or the default action, is automatically eligible for inspection for host, application, and user data by the network discovery policy. You do not explicitly enable discovery, although you can enhance or disable it. However, allowing traffic does not automatically guarantee discovery data collection. The system performs discovery only for connections involving IP addresses that are explicitly monitored by your network discovery policy; additionally, application discovery is limited for encrypted sessions. For more information, see Introduction to Network Discovery.

Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to pass, or if you do not configure SSL inspection. However, some access control rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Understanding Traffic Decryption and Using the SSL Preprocessor.

For more information on access control rules, see:

- Creating and Editing Access Control Rules

- Managing Access Control Rules in a Policy

- Troubleshooting Access Control Policies and Rules

Creating and Editing Access Control Rules

License: Any

Within an access control policy, access control rules provide a granular method of handling network traffic across multiple managed devices. In addition to its unique name, each access control rule has the following basic components:

State

By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and stops generating warnings and errors for that rule.

Position

Rules in an access control policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Conditions

Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network or geographical location, VLAN, port, application, requested URL, or user. Conditions can be simple or complex; their use often depends on target device license and model.

Action

A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow (with or without further inspection) matching traffic. Note that the system does not perform inspection on trusted or blocked traffic.

Inspection

Inspection options for an access control rule govern how the system inspects and blocks malicious traffic you would otherwise allow. When you allow traffic with a rule, you can specify that the system first inspect it with intrusion or file policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network.

Logging

A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record of traffic that matches a rule. In general, you can log sessions at the beginning or end of a connection, or both. You can log connections to the Defense Center database, as well as to the system log (syslog) or to an SNMP trap server.

Comments

Each time you save changes to an access control rule, you can add a comment.

Use the access control rule editor to add and edit access control rules; access the rule editor from the Rules tab of the access control policy editor. In the rule editor, you:

- Configure basic properties such as the rule’s name, state, position, and action in the upper portion of the editor.

- Add conditions using the tabs on the left side of the lower portion of the editor.

- Use the tabs on the right side of the lower portion to configure inspection and logging options, and also to add comments to the rule. For your convenience, the editor lists the rule’s inspection and logging options regardless of which tab you are viewing.

Note Properly creating and ordering access control rules is a complex task, but one that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the access control policy interface has a robust warning and error feedback system for rules. For more information, see Troubleshooting Access Control Policies and Rules.

To create or modify an access control rule:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy where you want to add a rule.

The policy page appears, focused on the Rules tab.

Step 3 You have the following options:

- To add a new rule, click Add Rule .

- To edit an existing rule, click the edit icon (

) next to the rule you want to edit.

The access control rule editor appears.

Step 4 Type a Name for the rule.

Each rule must have a unique name. You can use up to thirty printable characters, including spaces and special characters, with the exception of the colon (:).

Step 5 Configure the rule components, as summarized above. You can configure the following, or accept the defaults:

- Specify whether the rule is Enabled .

- Specify the rule position; see Specifying a Rule's Order of Evaluation.

- Select a rule Action ; see Using Rule Actions to Determine Traffic Handling and Inspection.

- Configure the rule’s conditions; see Using Conditions to Specify the Traffic a Rule Handles.

- For Allow and Interactive Block rules, configure the rule’s Inspection options; see Controlling Traffic Using Intrusion and File Policies.

- Specify Logging options; see Logging Connections in Network Traffic.

- Add Comments ; see Adding Comments to a Rule.

Step 6 Click Save to save the rule.

) to delete the rule. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Specifying a Rule's Order of Evaluation

License: Any

When you first create an access control rule, you specify its position using the Insert drop-down list in the rule editor. Rules in an access control policy are numbered, starting at 1. The system matches traffic to access control rules in top-down order by ascending rule number.

In most cases, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. Except in the case of Monitor rules (which log traffic but do not affect traffic flow), the system does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule.

Tip Proper access control rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs. For more information, see Ordering Rules to Improve Performance and Avoid Preemption.

In addition to ordering rules by number, you can group rules by category. By default the system provides three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete the Cisco-provided categories or change their order. For information on changing the position or category of an existing rule, see Changing a Rule's Position or Category.

To add a rule to a category while editing or creating a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control rule editor, from the Insert drop-down list, select Into Category, then select the category you want to use.

When you save the rule, it is placed last in that category.

To position a rule by number while editing or creating a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate rule number.

When you save the rule, it is placed where you specified.

Using Conditions to Specify the Traffic a Rule Handles

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

An access control rule’s conditions identify the type of traffic that rule handles. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, and user.

When adding conditions to access control rules, keep the following points in mind:

- You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the rule to apply to traffic. For example, you can use a single rule to perform URL filtering (URL condition) for specific hosts (zone or network condition).

- For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition’s criteria satisfies the condition. For example, you can use a single rule to perform user control for up to 50 users and groups.

Note that you can constrain zone and network conditions by source and destination, using up to 50 source and up to 50 destination criteria. If you add both source and destination criteria to a zone or network condition, matching traffic must originate from one of the specified source zones/networks and egress through one of the destination zones/networks. In other words, the system links multiple condition criteria of the same type with an OR operation, and links multiple condition types with an AND operation. For example, if your rule conditions are:

Source Networks: 10.0.0.0/8, 192.168.0.0/16

Application Category: peer to peer

the rule would match peer-to-peer application traffic from a host on one of your private IPv4 networks—a packet must originate from either one OR the other source network, AND represent peer-to-peer application traffic. Both of the following connections trigger the rule:

10.42.0.105 to anywhere, using LimeWire

192.168.42.105 to anywhere, using Kazaa

If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a network condition but no application condition evaluates traffic based on its source or destination, regardless of the application used in the session.

Note When you apply an access control policy, the system evaluates all its rules and creates an expanded set of criteria that target devices use to evaluate network traffic. Complex access control policies and rules can command significant resources. For tips on simplifying access control rules and other ways to improve performance, see Troubleshooting Access Control Policies and Rules.

These Conditions...

Match Traffic...

Details

Zones

entering or leaving a device via an interface in a specific security zone

A security zone is a logical grouping of one or more interfaces according to your deployment and security policies. Interfaces in a zone may be located across multiple devices. To build a zone condition, see Controlling Traffic by Security Zone.

Networks

by its source or destination IP address, country, or continent

You can explicitly specify IP addresses or address blocks. The geolocation feature also allows you to control traffic based on its source or destination country or continent. To build a network condition, see Controlling Traffic by Network or Geographical Location.

VLAN Tags

tagged by VLAN

The system uses the innermost VLAN tag to identify a packet by VLAN. To build a VLAN condition, see Controlling VLAN Traffic.

Ports

by its source or destination port

For TCP and UDP, you can control traffic based on the transport layer protocol. For ICMP and ICMPv6 (IPv6-ICMP), you can control traffic based on its Internet layer protocol plus an optional type and code. Using port conditions, you can also control traffic using other protocols that do not use ports. To build a port condition, see Controlling Traffic by Port and ICMP Codes.

Applications

by the application detected in a session

You can control access to individual applications, or filter access according to basic characteristics: type, risk, business relevance, categories, and tags. To build an application condition, see Controlling Application Traffic.

URLs

by the URL requested in the session

You can limit the websites that users on your network can access either individually or based on the URL’s general classification and risk level. To build a URL condition, see Blocking URLs.

Users

by the user involved in the session

You can control traffic based on the LDAP user logged into a host involved in a monitored session. You can control traffic based on individual users or groups retrieved from a Microsoft Active Directory server. To build a user condition, see Controlling Traffic Based on Users.

Note that although you can create access control rules with any license, certain rule conditions require that you enable specific licensed capabilities on the access control policy’s targeted devices before you can apply the policy. For more information, see License and Model Requirements for Access Control.

Using Rule Actions to Determine Traffic Handling and Inspection

License: Any

Every access control rule has an action that determines the following for matching traffic:

- handling—foremost, the rule action governs whether the system will monitor, trust, block, or allow traffic that matches the rule’s conditions

- inspection—certain rule actions allow you, when properly licensed, to further inspect matching traffic before allowing it to pass

- logging—the rule action determines when and how you can log details about matching traffic

The access control policy’s default action handles traffic that does not meet the conditions of any non-Monitor access control rule; see Setting Default Handling and Inspection for Network Traffic.

Keep in mind that only devices deployed inline can block or modify traffic. Devices deployed passively or in tap mode can analyze and log, but not affect, the flow of traffic. For detailed information on rule actions and how they affect traffic handling, inspection, and logging, see the following sections:

- Monitor Action: Postponing Action and Ensuring Logging

- Trust Action: Passing Traffic Without Inspection

- Blocking Actions: Blocking Traffic Without Inspection

- Interactive Blocking Actions: Allowing Users to Bypass Website Blocks

- Allow Action: Allowing and Inspecting Traffic

- Limitations to Trusting or Blocking Traffic with Series 3 Devices

- Controlling Traffic Using Intrusion and File Policies

- Logging Connections Based on Access Control Handling

Monitor Action: Postponing Action and Ensuring Logging

License: Any

The Monitor action does not affect traffic flow; matching traffic is neither immediately permitted nor denied. Rather, traffic is matched against additional rules to determine whether to permit or deny it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching rules, the system uses the default action.

Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of connection events for monitored traffic. That is, connections are logged even if the traffic matches no other rules and you do not enable logging on the default action. For more information, see Understanding Logging for Monitored Connections.

Note If locally-bound traffic matches a Monitor rule in a Layer 3 deployment, that traffic may bypass inspection. To ensure inspection of the traffic, enable Inspect Local Router Traffic in the advanced device settings for the managed device routing the traffic. For more information, see Understanding Advanced Device Settings.

Trust Action: Passing Traffic Without Inspection

License: Any

The Trust action allows traffic to pass without further inspection of any kind.

You can log trusted network traffic at both the beginning and end of connections. Note that the system logs TCP connections handled by a Trust rule differently depending on the model of the device that detected the connection. For more information, see Understanding Logging for Trusted Connections.

Caution For traffic handled by Series 3 devices, the system processes certain Trust rules before an access control policy’s Security Intelligence blacklist, which can allow blacklisted traffic to pass uninspected. For more information, see Limitations to Trusting or Blocking Traffic with Series 3 Devices.

Blocking Actions: Blocking Traffic Without Inspection

License: Any

For unencrypted HTTP traffic, when the system blocks a web request, you can override the default browser or server page with a custom page that explains that the connection was denied. The system calls this custom page an HTTP response page; see Displaying a Custom Web Page for Blocked URLs.

For decrypted and encrypted (HTTPS) traffic, Interactive Block rules block matching connections without interaction and the system does not display a response page.

Note that the system does not display the configured response page for some successfully blocked traffic handled by Series 3 devices. Instead, users requesting prohibited URLs have their connection either reset or time out. For more information, see Limitations to Trusting or Blocking Traffic with Series 3 Devices.

You can log blocked network traffic only at the beginning of connections. Note that only devices deployed inline can block traffic. Because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection. For more information, see Understanding Logging for Blocked and Interactively Blocked Connections.

Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for an Block rule, consider whether the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.

Interactive Blocking Actions: Allowing Users to Bypass Website Blocks

License: Any

For unencrypted HTTP traffic, the Interactive Block and Interactive Block with reset actions give users a chance to bypass a website block by clicking through a customizable warning page, called an HTTP response page. Interactive Block with reset rules also reset the connection.

Note For decrypted and encrypted (HTTPS) traffic, Interactive Block rules block matching connections without interaction and the system does not display a response page. See Understanding Traffic Decryption for information on configuring the SSL inspection feature to decrypt traffic.

Allow Action: Allowing and Inspecting Traffic

License: Any

The Allow action allows matching traffic to pass. When you allow traffic, you can use an associated intrusion or file policy (or both) to further inspect and block unencrypted or decrypted network traffic:

- With a Protection license, you can use an intrusion policy to analyze network traffic according to intrusion detection and prevention configurations and, optionally, drop offending packets.

- Also with a Protection license, you can perform file control using a file policy. File control allows you to detect and block your users from uploading (sending) or downloading (receiving) files of specific types over specific application protocols.

- With a Malware license, you can perform network-based advanced malware protection (AMP), also using a file policy. Network-based AMP can inspect files for malware, and optionally block detected malware.

For instructions on how to associate an intrusion or file policy with an access control rule, see Controlling Traffic Using Intrusion and File Policies.

The diagram below illustrates the types of inspection performed on traffic that meets the conditions of an Allow rule (or a user-bypassed Interactive Block rule; see Interactive Blocking Actions: Allowing Users to Bypass Website Blocks). Notice that file inspection occurs before intrusion inspection; blocked files are not inspected for intrusion-related exploits.

For simplicity, the diagram displays traffic flow for situations where both (or neither) an intrusion and a file policy are associated with an access control rule. You can, however, configure one without the other. Without a file policy, traffic flow is determined by the intrusion policy; without an intrusion policy, traffic flow is determined by the file policy.

Regardless of whether the traffic is inspected or dropped by an intrusion or file policy, the system can inspect it using network discovery. However, allowing traffic does not automatically guarantee discovery inspection. The system performs discovery only for connections involving IP addresses that are explicitly monitored by your network discovery policy; additionally, application discovery is limited for encrypted sessions. For more information, see Introduction to Network Discovery.

You can log allowed network traffic at both the beginning and end of connections.

Limitations to Trusting or Blocking Traffic with Series 3 Devices

License: Any

Supported Devices: Series 3

When you apply an access control policy to a Series 3 device, the system may promote access control rules that meet specific criteria. Promoted rules take advantage of specialized hardware in Series 3 devices to immediately divert or block traffic that does not require deep packet inspection. Their advantage is the speed at which they determine the correct path for the traffic.

Because this evaluation takes place at the hardware level, the system can only use limited information to quickly handle connections by promoting rules. Series 3 devices promote rules that meet all of the following criteria:

- have the Trust , Block , or Block with reset action

- use only simple, network-based conditions: security zone, IP address, VLAN tag, and port

- are placed above all other access control rules (regardless of action) that perform deep packet inspection, that is, that have application, URL, user, or geolocation-based conditions

- are also placed above all Monitor rules

Therefore, rules promoted to improve performance are most likely simple Trust or Block rules that are placed either near the top of an access control policy (rules with a low number), or anywhere in a policy that uses only simple, network-based rules. However, the performance benefits realized from rule promotion can cause some unexpected behavior.

Preempting Security Intelligence

The system processes promoted rules before an access control policy’s Security Intelligence blacklist. This means that promoted Trust rules can allow blacklisted traffic to pass uninspected through a Series 3 device. For more information on Security Intelligence, see Blacklisting Using Security Intelligence IP Address Reputation.

Preventing HTTP Response Page Display

Web traffic blocked by a promoted Block rule does not cause the system to display the configured HTTP response page to your users, even though the system successfully blocks the traffic. Instead, users requesting prohibited URLs have their connection either reset or time out. For more information on configuring a response page, see Displaying a Custom Web Page for Blocked URLs.

IPv6 Traffic Handling

The system can inspect both IPv4 and IPv6 traffic. IPv6 inspection includes the 4in6, 6in4, 6to4, and 6in6 tunneling schemes, and also includes Teredo tunneling when the UDP header specifies port 3544. When evaluating traffic using access control rules with IP address conditions, in most cases Series 3 devices match the IP address you specify against the IP address in the innermost packet header.

However, promoted rules use the IP address in the outermost header to evaluate IPv6 traffic, regardless of whether that traffic is tunneled, and regardless of where the IPv6 header is: innermost or outermost. In other words, when promoted rules evaluate tunneled traffic, only 4in4 traffic uses the innermost header to match against access control rule criteria.

For example, consider a scenario where you are using Series 3 devices to examine 6in4 tunneled traffic sent over an IPv4 network. You create a simple, network-based access control rule that blocks traffic to or from a specific IPv6 address. If the system promotes the rule as a result of its position in the access control policy, the rule has no effect. This is because the system matches the outermost IPv4 header of a tunneled packet to the IPv6 rule condition, which can never trigger. The system handles the traffic as if the rule did not exist, using either a subsequent access control rule or the policy’s default action.

Adding Comments to a Rule

License: Any

When you create or edit an access control rule, you can add a comment. For example, you might summarize the overall configuration for the benefit of other users, or note when you change a rule and the reason for the change. You can display a list of all comments for a rule along with the user who added each comment and the date the comment was added.

Tip To prompt (or force) FireSIGHT System users to enter a comment when saving an access control rule, see Configuring Access Control Policy Preferences.

When you save a rule, all comments made since the last save become read-only.

To add a comment to a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control rule editor, select the Comments tab.

The Comments page appears.

Step 2 Click New Comment.

The New Comment pop-up window appears.

Step 3 Type your comment and click OK.

Your comment is saved. You can edit or delete this comment until you save the rule.

Step 4 Save or continue editing the rule.

Managing Access Control Rules in a Policy

License: Any

The Rules tab of the access control policy editor, shown in the following graphic, allows you to add, edit, search, move, enable, disable, delete, and otherwise manage access control rules within your policy.

Table 14-2 Understanding the Access Control Policy Editor

Icon

Description

You can...

Click an active (yellow) inspection icon to edit the inspection options for the rule; see Controlling Traffic Using Intrusion and File Policies. If the icon is inactive (white), no policy of that type is selected for the rule.

file and malware inspection

logging

Click an active (blue) logging icon to edit the logging options for the rule; see Logging Connections Based on Access Control Handling. If the icon is inactive (white), connection logging is disabled for the rule.

comment

Click the number in the comment column to add a comment to a rule; see Adding Comments to a Rule. The number indicates how many comments the rule already contains.

warning

Hover your pointer over the icon to read the warning, error, or informational text; see Troubleshooting Access Control Policies and Rules.

error

information

For information on managing access control rules, see:

- Creating and Editing Access Control Rules

- Searching Access Control Rules

- Displaying Rules by Affected Device

- Enabling and Disabling Rules

- Changing a Rule's Position or Category

Searching Access Control Rules

License: Any

You can search the list of access control rules for matching values using an alphanumeric string, including spaces and printable, special characters. The search inspects the rule name and any rule condition you have added to the rule. For rule conditions, the search matches any name or value you can add for each condition type (zone, network, application, and so on). This includes individual object names or values, group object names, individual object names or values within a group, and literal values.

You can use complete or partial search strings. The column for matching values is highlighted for each matching rule. For example, if you search on all or part of the string 100Bao, at a minimum, the Applications column is highlighted for each rule where you have added the 100Bao application. If you also have a rule named 100Bao, both the Name and Applications columns are highlighted.

You can navigate to each previous or next matching rule. A status message displays the current match and the total number of matches.

Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the page where the first match occurs is displayed. Selecting the next match when you are at the last match takes you to the first match, and selecting the previous match when you are at the first match takes you to the last match.

To search for rules:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy editor for the policy you want to search, click the Search Rules prompt, type a search string, then press Enter. You can also use the Tab key or click a blank page area to initiate the search.

Columns for rules with matching values are highlighted, with differentiated highlighting for the indicated (first) match.

Step 2 Find the rules you are interested in:

- To navigate between matching rules, click the next-match (

) or previous-match ( ) icon.

- To refresh the page and clear the search string and any highlighting, click the clear icon (

).

Displaying Rules by Affected Device

License: Any

You can filter the access control rules listed in your access control policy to display only the rules that govern traffic for one or more specified devices.

To determine the rules that affect a device, the system uses the access control rules’ zone conditions. A security zone is a logical grouping of interfaces, so, if a zone condition includes an interface, the device that handles traffic where that interface is located is affected by that rule. Rules with no zone condition apply to any zone, and therefore every device.

Note that filters are cleared if you add a new rule, or if you edit and save an existing rule.

To filter rules by device or device group:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy editor for the policy whose rules you want to filter, click Filter by Device above the list of rules.

The Filter by Device pop-up window appears. If you have added devices or device groups to your policy, a list of targeted devices and device groups appears.

Step 2 Select one or more of the check boxes to display only the rules that apply to those devices or groups. Alternatively, select the All check box to reset and display all of the rules.

Step 3 Click OK.

The page updates to display rules for devices and device groups that you selected and hide rules for devices and device groups that you did not select.

Enabling and Disabling Rules

License: Any

When you create an access control rule, it is enabled by default. If you disable a rule, the system does not use it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules in an access control policy, disabled rules are grayed out, although you can still modify them. Note that you can also enable or disable an access control rule using the rule editor; see Creating and Editing Access Control Rules.

To change an access control rule’s state:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy editor for the policy that contains the rule you want to enable or disable, right-click the rule and choose a rule state:

- To enable an inactive rule, select State > Enable .

- To disable an active rule, select State > Disable .

Step 2 Click Save to save the policy.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Changing a Rule's Position or Category

License: Any

To help you organize access control rules, every access control policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories.

By default, any predefined user role that allows you to modify access control policies also allows you to move and modify access control rules within and among rules categories. You can, however, create custom roles that restrict users from moving and modifying rules.

For more information, see:

- Moving a Rule

- Adding a New Rule Category

Moving a Rule

License: Any

Proper access control rule order reduces the resources required to process network traffic, and prevents rule preemption. By default, any predefined user role that allows you to modify access control policies also allows you to move access control rules within and among rules categories. You can, however, create custom roles that restrict users from moving rules in the system-provided categories.

The following procedure explains how to move one or more rules at a time using the access control policy editor. You can also move individual access control rules using the rule editor; see Creating and Editing Access Control Rules.

To move a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy editor for the policy that contains the rules you want to move, select the rules by clicking in a blank area for each rule. Use the Ctrl and Shift keys to select multiple rules.

The rules you selected are highlighted.

Step 2 Move the rules. You can cut and paste or drag and drop.

To cut and paste rules into a new location, right-click a selected rule and select Cut. Then, right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or Paste below. Note that you cannot copy and paste access control rules between two different access control policies.

Step 3 Click Save to save the policy.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Adding a New Rule Category

License: Any

To help you organize access control rules, every access control policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories between the Standard Rules and Root Rules.

Adding custom categories allows you to further organize your rules without having to create additional policies. You can rename and delete categories that you add. You cannot move these categories, but you can move rules into, within, and out of them.

Although you can create custom roles that restrict users from moving and modifying rules in the system-provided categories, any user who is allowed to modify access control policies can add rules to custom categories and modify rules in them without restriction.

To add a new category:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy editor for the policy where you want to add a rule category, click Add Category.

Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to set the position of the new category before you add it. You can also right-click an existing rule and select Insert new category.

The Add Category pop-up window appears.

Step 2 Type a unique category Name.

You can enter an alphanumeric name, including spaces and special printable characters, with up to 30 characters.

Step 3 You have the following choices:

- To position the new category immediately above an existing category, select above Category from the first Insert drop-down list, then select the category above which you want to position the rule from the second drop-down list.

- To position the new category rule below an existing rule, select below rule from the drop-down list, then enter an existing rule number. This option is valid only when at least one rule exists in the policy.

- To position the rule above an existing rule, select above rule from the drop-down list, then, enter an existing rule number. This option is valid only when at least one rule exists in the policy.

Step 4 Click OK.

) to delete the category. Rules in a category you delete are added to the category above.

Step 5 Click Save to save the policy.

Controlling Traffic with Network-Based Rules

Access control rules within access control policies exert granular control over network traffic logging and handling. Network-based conditions allow you to manage which traffic can traverse your network, using one or more of the following criteria:

- source and destination security zones

- source and destination IP addresses or geographical locations

- a packet’s innermost VLAN tag

- source and destination port, which also includes transport layer protocol and ICMP code options

You can combine network-based conditions with each other and with other types of conditions to create an access control rule. These access control rules can be simple or complex, matching and inspecting traffic using multiple conditions. For detailed information on access control rules, see Tuning Traffic Flow Using Access Control Rules.

Note Hardware-based fast-path rules, Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network traffic is evaluated by access control rules. You can also configure the SSL inspection feature to block or decrypt encrypted traffic before access control rules evaluate it.

Table 15-1 License and Model Requirements for Network-Based Access Control Rules

Requirement

VLAN Tag

Geolocation Control

All Other Network-Based Control

license

Any

FireSIGHT

Any

devices

Any except ASA FirePOWER

Series 3

virtual

ASA FirePOWER

Any

Defense Centers

Any

Any except DC500

Any

For information on building network-based access control rules, see:

- Controlling Traffic by Security Zone

- Controlling Traffic by Network or Geographical Location

- Controlling VLAN Traffic

- Controlling Traffic by Port and ICMP Codes

Controlling Traffic by Security Zone

License: Any

Zone conditions in access control rules allow you to control traffic by its source and destination security zones. A security zone is a grouping of one or more interfaces, which may be located across multiple devices. An option you choose during a device’s initial setup, called its detection mode, determines how the system initially configures the device’s interfaces, and whether those interfaces belong to a security zone.

As a simple example, when you register device with an Inline detection mode, the Defense Center creates two zones: Internal and External, and assigns the first pair of interfaces on the device to those zones. Hosts connected to the network on the Internal side represent your protected assets.

To extend this scenario, you could deploy additional identically configured devices—managed by the same Defense Center—to protect similar resources in several different locations. Like the first device, each of these devices protects the assets in its Internal security zone.

Tip You are not required to group all internal (or external) interfaces into a single zone. Choose the grouping that makes sense for your deployment and security policies. For more information on creating zones, see Working with Security Zones.

In this deployment, you may decide that although you want these hosts to have unrestricted access to the Internet, you nevertheless want to protect them by inspecting incoming traffic for intrusions and malware.

To accomplish this using access control, configure an access control rule with a zone condition where the Destination Zone is set to Internal. This simple access control rule matches traffic that leaves the device from any interface in the Internal zone.

To ensure that the system inspects matching traffic for intrusions and malware, choose a rule action of Allow, then associate this rule with an intrusion and a file policy. For more information, see Using Rule Actions to Determine Traffic Handling and Inspection and Controlling Traffic Using Intrusion and File Policies.

If you want to build a more complex rule, you can add a maximum of 50 zones to each of the Source Zones and Destination Zones in a single zone condition:

- To match traffic leaving the device from an interface in the zone, add that zone to the Destination Zones .

Because devices deployed passively do not transmit traffic, you cannot use a zone comprised of passive interfaces in a Destination Zone condition.

- To match traffic entering the device from an interface in the zone, add that zone to the Source Zones .

- If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.

Note that just as all interfaces in a zone must be of the same type (all inline, all passive, all switched, or all routed), all zones used in a zone condition for an access control rule must be of the same type. That is, you cannot write a single rule that matches traffic to or from zones of different types.

When building a zone condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control traffic by zone:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by zone, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the Zones tab.

The Zones tab appears.

Step 3 Find and select the zones you want to add from the Available Zones.

To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone name. The list updates as you type to display matching zones.

Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.

You can also drag and drop selected zones.

Step 5 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Traffic by Network or Geographical Location

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Network conditions in access control rules allow you to control traffic by its source and destination IP address. You can either:

- explicitly specify the source and destination IP addresses for the traffic you want to control, or

- use the geolocation feature, which associates IP addresses with geographical locations, to control traffic based on its source or destination country or continent

When you build a network-based access control rule condition, you can manually specify IP address and geographical locations. Alternately, you can configure network conditions with network and geolocation objects, which are reusable and associate a name with one or more IP addresses, address blocks, countries, continents, and so on.

Tip After you create a network or geolocation object, you can use it not only to build access control rules, but also to represent IP addresses in various other places in the system’s web interface. You can create these objects using the object manager; you can also create network objects on-the-fly while you are configuring access control rules. For more information, see Managing Reusable Objects.

Note that if you want to write rules to control traffic by geographical location, to ensure you are using up-to-date geolocation data to filter your traffic, Cisco strongly recommends you regularly update the geolocation database (GeoDB) on your Defense Center; see Updating the Geolocation Database.

Additionally, note that while you can perform simple IP address-based access control using any FireSIGHT System appliance and any license, geolocation-based access control requires a FireSIGHT license and is not supported on many Series 2 appliances, nor on Cisco NGIPS for Blue Coat X-Series.

Table 15-2 License and Model Requirements for Network Conditions

Requirement

Geolocation Control

IP Address Control

license

FireSIGHT

Any

devices

Series 3, virtual, ASA FirePOWER

Any

Defense Centers

Any except DC500

Any

In this example, a network object group called Private Networks (that comprises the IPv4 and IPv6 Private Networks network objects, not shown) represents your internal networks. The example also manually specifies the example.com IP address, and uses a system-provided North Korea geolocation object to represent North Korea IP addresses.

You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single network condition, and you can mix network and geolocation-based configurations:

- To match traffic from an IP address or geographical location, configure the Source Networks .

- To match traffic to an IP address or geographical location, configure the Destination Networks .

If you add both source and destination network conditions to a rule, matching traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.

When building a network condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control traffic by network or geographical location:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by network, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the Networks tab.

The Networks tab appears.

Step 3 Find and select the networks you want to add from the Available Networks, as follows:

- Click the Networks tab to display network objects and groups to add; click the Geolocation tab to display geolocation objects.

- To add a network object on the fly, which you can then add to the condition, click the add icon (

) above the Available Networks list; see Working with Network Objects.

- To search for network or geolocation objects to add, select the appropriate tab, click the Search by name or value prompt above the Available Networks list, then type an object name or the value of one of the object’s components. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.

You can also drag and drop selected objects.

Step 5 Add any source or destination IP addresses or address blocks that you want to specify manually.

Click the Enter an IP address prompt below the Source Networks or Destination Networks list; then type an IP address or address block and click Add.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Controlling VLAN Traffic

License: Any

Supported Devices: Any except ASA FirePOWER

VLAN conditions in access control rules allow you to control VLAN-tagged traffic. The system uses the innermost VLAN tag to identify a packet by VLAN.

When you build a VLAN-based access control rule condition, you can manually specify VLAN tags. Alternately, you can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one or more VLAN tags.

Tip After you create a VLAN tag object, you can use it not only to build access control rules, but also to represent VLAN tags in various other places in the system’s web interface. You can create VLAN tag objects either using the object manager or on-the-fly while you are configuring access control rules. For more information, see Working with VLAN Tag Objects.

You can add a maximum of 50 items to the Selected VLAN Tags in a single VLAN tag condition. When building a VLAN tag condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control traffic by VLAN tag:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by VLAN tag, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the VLAN Tags tab.

The VLAN Tags tab appears.

Step 3 Find and select the VLANs you want to add from the Available VLAN Tags, as follows:

- To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon (

) above the Available VLAN Tags list; see Working with VLAN Tag Objects.

- To search for VLAN tag objects and groups to add, click the Search by name or value prompt above the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule or to add the selected objects to the Selected VLAN Tags list.

You can also drag and drop selected objects.

Step 5 Add any VLAN tags that you want to specify manually.

Click the Enter a VLAN Tag prompt below the Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag from 1 to 4094; use a hyphen to specify a range of VLAN tags.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Traffic by Port and ICMP Codes

License: Any

Network conditions in access control rules allow you to control traffic by its source and destination port. In this context, “port” refers to one of the following:

- For TCP and UDP, you can control traffic based on the transport layer protocol. The system represents this configuration using the protocol number in parentheses, plus an optional associated port or port range. For example: TCP(6)/22.

- For ICMP and ICMPv6 (IPv6-ICMP), you can control traffic based on its Internet layer protocol plus an optional type and code. For example: ICMP(1):3:3.

- You can control traffic using other protocols that do not use ports.

When you build a port-based access control rule condition, you can manually specify ports. Alternately, you can configure port conditions with port objects, which are reusable and associate a name with one or more ports.

Tip After you create a port object, you can use it not only to build access control rules, but also to represent ports in various other places in the system’s web interface. You can create port objects either using the object manager or on-the-fly while you are configuring access control rules. For more information, see Working with Port Objects.

You can add a maximum of 50 items to each of the Selected Source Ports and Selected Destination Ports lists in a single network condition:

- To match traffic from a port, configure the Selected Source Ports .

If you add only source ports to a condition, you can add ports that use different transport protocols. For example, you can add both DNS over TCP and DNS over UDP as source port conditions in a single access control rule.

- To match traffic to a port, configure the Selected Destination Ports .

If you add only destination ports to a condition, you can add ports that use different transport protocols.

- To match traffic both originating from specific Selected Source Ports and destined for specific Selected Destination Ports , configure both.

If you add both source and destination ports to a condition, you can only add ports that share a single transport protocol (TCP or UDP). For example, if you add DNS over TCP as a source port, you can add Yahoo Messenger Voice Chat (TCP) as a destination port but not Yahoo Messenger Voice Chat (UDP).

Keep the following points in mind when building a port condition:

- When you add a destination ICMP port with the type set to 0 or a destination ICMPv6 port with the type set to 129, the access control rule only matches unsolicited echo replies. ICMP echo replies sent in response to ICMP echo requests are ignored. For a rule to match on any ICMP echo, use ICMP type 8 or ICMPv6 type 128.

- When you use the GRE (47) protocol as a destination port condition, you can only add other network-based conditions to the access control rule, that is, zone, network, and VLAN tag conditions. You cannot save the rule if you add reputation or user-based conditions.

When building a port condition, warning icons indicate invalid configurations. For example, you can use the object manager to edit in-use port objects so that the rules that use those object groups become invalid. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control traffic by port:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by port, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the Ports tab.

The Ports tab appears.

Step 3 Find and select the ports you want to add from the Available Ports, as follows:

- To add a port object on the fly, which you can then add to the condition, click the add icon (

) above the Available Ports list; see Working with Port Objects.

- To search for port objects and groups to add, click the Search by name or value prompt above the Available Ports list, then type either the name of the object, or the value of a port in the object. The list updates as you type to display matching objects. For example, if you type 80, the Defense Center displays the Cisco-provided HTTP port object.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.

You can also drag and drop selected objects.

Step 5 Add any source or destination ports that you want to specify manually.

- For source ports, select either TCP or UDP from the Protocol drop-down list under the Selected Source Ports list. Then, enter a Port . You can specify a single port with a value from 0 to 65535.

- For destination ports, select a protocol (including All for all protocols) from the Protocol drop down list under the Selected Destination Ports list. You can also type the number of an unassigned protocol that does not appear in the list.

If you select ICMP or IPv6-ICMP, a pop-up window appears where you can select a type and a related code. For more information on ICMP types and codes, see http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml and http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml.

If you do not want to specify a protocol, or optionally if you specified TCP or UDP, enter a Port. You can specify a single port with a value from 0 to 65535.

Click Add. Note that the Defense Center will not add a port to a rule condition that results in an invalid configuration.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Traffic with Reputation-Based Rules

Access control rules within access control policies exert granular control over network traffic logging and handling. Reputation-based conditions in access control rules allow you to manage which traffic can traverse your network, by contextualizing your network traffic and limiting it where appropriate. Access control rules govern the following types of reputation-based control:

- Application conditions allow you to perform application control , which controls application traffic based on not only individual applications, but also applications’ basic characteristics: type, risk, business relevance, categories, and tags.

- URL conditions allow you to perform URL filtering , which controls web traffic based on individual websites, as well as websites’ system-assigned category and reputation.

You can combine reputation-based conditions with each other and with other types of conditions to create an access control rule. These access control rules can be simple or complex, matching and inspecting traffic using multiple conditions. For detailed information on access control rules, see Tuning Traffic Flow Using Access Control Rules.

Note Hardware-based fast-path rules, Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network traffic is evaluated by access control rules. You can also configure the SSL inspection feature to block or decrypt encrypted traffic before access control rules evaluate it.

Table 16-1 License and Model Requirements for Reputation-Based Access Control Rules

Requirement

Application Control

URL Filtering (cat. & rep.)

URL Filtering (manual)

license

Control

URL Filtering

Any

devices

Any except Series 2 or X-Series

Any except Series 2

Any except Series 2

Defense Centers

Any

Any except DC500

Any

For information on adding reputation-based conditions to access control rules, see:

- Controlling Application Traffic

- Blocking URLs

The FireSIGHT System can perform other types of reputation-based control, but you do not configure these using access control rules. For more information, see:

- Blacklisting Using Security Intelligence IP Address Reputation explains how to limit traffic based on the reputation of a connection’s origin or destination as a first line of defense.

- Tuning Intrusion Prevention Performance explains how to detect, track, store, analyze, and block the transmission of malware and other types of prohibited files.

Controlling Application Traffic

License: Control

Supported Devices: Any except Series 2 or X-Series

When the FireSIGHT System analyzes IP traffic, it can identify and classify the commonly used applications on your network. The system uses this discovery-based application awareness feature to allow you to control application traffic on your network.

Understanding Application Control

Application conditions in access control rules allow you to perform this application control. Within a single access control rule, there are a few ways you can specify applications whose traffic you want to control:

- You can select individual applications, including custom applications.

- You can use system-provided application filters , which are named sets of applications organized according to the applications’ basic characteristics: type, risk, business relevance, categories, and tags.

- You can create and use custom application filters, which group applications (including custom applications) in any way you choose.

Application filters allow you to quickly create application conditions for access control rules. They simplify policy creation and administration, and grant you assurance that the system will control web traffic as expected. For example, you could create an access control rule that identifies and blocks all high risk, low business relevance applications. If a user attempts to use one of those applications, the session is blocked.

In addition, Cisco frequently updates and adds additional detectors via system and vulnerability database (VDB) updates. You can also create your own detectors and assign characteristics (risk, relevance, and so on) to the applications they detect. By using filters based on application characteristics, you can ensure that the system uses the most up-to-date detectors to monitor application traffic.

Building Application Conditions

For traffic to match an access control rule with an application condition, the traffic must match one of the filters or applications that you add to a Selected Applications and Filters list.

The following graphic shows the application condition for an access control rule that blocks: a custom group of applications for MyCompany, all applications with high risk and low business relevance, gaming applications, and some individually selected applications.

In a single application condition, you can add a maximum of 50 items to the Selected Applications and Filters list. Each of the following counts as an item:

- One or more filters from the Application Filters list, individually or in custom combination. This item represents set of applications, grouped by characteristic.

- A filter created by saving an application search in the Available Applications list. This item represents a set of applications, grouped by substring match.

- An individual application from the Available Applications list.

In the web interface, filters added to a condition are listed above and separately from individually added applications.

Note that when you apply an access control policy, for each rule with an application condition, the system generates a list of unique applications to match. In other words, you may use overlapping filters and individually specified applications to ensure complete coverage.

Note For encrypted traffic, the system can identify and filter traffic using only the applications tagged SSL Protocol. Applications without this tag can only be detected in unencrypted or decrypted traffic. Also, the system assigns the decrypted traffic tag to applications that the system can detect in decrypted traffic only—not encrypted or unencrypted. For information on using the SSL inspection feature to decrypt or block encrypted traffic before the system matches it against access control rules, see Understanding Traffic Decryption.

For more information, see the following sections:

- Matching Traffic with Application Filters

- Matching Traffic from Individual Applications

- Adding an Application Condition to an Access Control Rule

- Limitations to Application Control

Matching Traffic with Application Filters

License: Control

Supported Devices: Any except Series 2 or X-Series

When building an application condition in an access control rule, use the Application Filters list to create a set of applications, grouped by characteristic, whose traffic you want to match.

For your convenience, the system characterizes each application that it detects using the criteria described in Table 45-2. You can use these criteria as filters or create custom combinations of filters to perform application control.

Note that the mechanism for filtering applications within an access control rule is the same as that for creating reusable, custom application filters using the object manager; see Working with Application Filters. You can also save many filters you create on-the-fly in access control rules as new, reusable filters. You cannot save a filter that includes another user-created filter because you cannot nest user-created filters.

Understanding How Filters Are Combined

When you select filters, singly or in combination, the Available Applications list updates to display only the applications that meet your criteria. You can select system-provided filters in combination, but not custom filters.

The system links multiple filters of the same filter type with an OR operation. For example, if you select the Medium and High filters under the Risks type, the resulting filter is:

Risk: Medium OR High

If the Medium filter contains 110 applications and the High filter contains 82 applications, the system displays all 192 applications in the Available Applications list.

The system links different types of filters with an AND operation. For example, if you select the Medium and High filters under the Risks type, and the Medium and High filters under the Business Relevance type, the resulting filter is:

Risk: Medium OR High

AND

Business Relevance: Medium OR High

In this case, the system displays only those applications that are included in both the Medium or High Risk type AND the Medium or High Business Relevance type.

Finding and Selecting Filters

To select filters, click the arrow next to a filter type to expand it, then select or clear the check box next to each filter whose applications you want to display or hide. You can also right-click a system-provided filter type (Risks, Business Relevance, Types, Categories, or Tags) and select Check All or Uncheck All.

To search for filters, click the Search by name prompt above the Available Filters list, then type a name. The list updates as you type to display matching filters.

After you are done selecting filters, use the Available Applications list to add those filters to the rule; see Matching Traffic from Individual Applications.

Matching Traffic from Individual Applications

License: Control

Supported Devices: Any except Series 2 or X-Series

When building an application condition in an access control rule, use the Available Applications list to select the applications whose traffic you want to match.

Browsing the List of Applications

When you first start to build the condition the list is unconstrained, and displays every application the system detects, 100 at a time:

- To page through the applications, click the arrows underneath the list.

- To display a pop-up window with summary information about the application’s characteristics, as well as Internet search links that you can follow, click the information icon (

) next to an application.

Finding Applications to Match

To help you find the applications you want to match, you can constrain the Available Applications list in the following ways:

- To search for applications, click the Search by name prompt above the list, then type a name. The list updates as you type to display matching applications.

- To constrain the applications by applying a filter, use the Application Filters list (see Matching Traffic with Application Filters). The Available Applications list updates as you apply filters. For your convenience, the system uses an unlock icon (

) to mark applications that the system can identify only in decrypted traffic—not encrypted or unencrypted.

Once constrained, an All apps matching the filter option appears at the top of the Available Applications list. This option allows you to add all the applications in the constrained list to the Selected Applications and Filters list, all at once.

Note If you select one or more filters in the Application Filters list and also search the Available Applications list, your selections and the search-filtered Available Applications list are combined using an AND operation. That is, the All apps matching the filter condition includes all the individual conditions currently displayed in the Available Applications list as well as the search string entered above the Available Applications list.

Selecting Single Applications to Match in a Condition

After you find an application you want to match, click to select it. To select multiple applications, use the Shift and Ctrl keys, or right-click and select Select All to select all applications in the current constrained view.

In a single application condition, you can match a maximum of 50 applications by selecting them individually; to add more than 50 you must either create multiple access control rules or use filters to group applications.

Selecting All Applications Matching a Filter for a Condition

Once constrained by either searching or using the filters in the Application Filters list, the All apps matching the filter option appears at the top of the Available Applications list.

This option allows you to add the entire set of applications in the constrained Available Applications list to the Selected Applications and Filters list, at once. In contrast to adding applications individually, adding this set of applications counts as only one item against the maximum of 50, regardless of the number of individual applications that comprise it.

When you build an application condition this way, the name of the filter you add to the Selected Applications and Filters list is a concatenation of the filter types represented in the filter plus the names of up to three filters for each type. More than three filters of the same type are followed by an ellipsis (...). For example, the following filter name includes two filters under the Risks type and four under Business Relevance:

Risks: Medium, High Business Relevance: Low, Medium, High,...

Filter types that are not represented in a filter you add with All apps matching the filter are not included in the name of the filter you add. The instructional text that is displayed when you hover your pointer over the filter name in the Selected Applications and Filters list indicates that these filter types are set to any; that is, these filter types do not constrain the filter, so any value is allowed for these.

You can add multiple instances of All apps matching the filter to an application condition, with each instance counting as a separate item in the Selected Applications and Filters list. For example, you could add all high risk applications as one item, clear your selections, then add all low business relevance applications as another item. This application condition matches applications that are high risk OR have low business relevance.

Adding an Application Condition to an Access Control Rule

License: Control

Supported Devices: Any except Series 2 or X-Series

For traffic to match an access control rule with an application condition, the traffic must match one of the filters or applications that you add to a Selected Applications and Filters list.

You can add a maximum of 50 items per condition, and filters added to a condition are listed above and separately from individually added applications. When building an application condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control application traffic:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by application, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the Applications tab.

The Applications tab appears.

Step 3 Optionally, use filters to constrain the list of applications displayed in the Available Applications list.

Select one or more filters in the Application Filters list. For more information, see Matching Traffic with Application Filters.

Step 4 Find and select the applications you want to add from the Available Applications list.

) marks applications that the system can identify only in decrypted traffic—not encrypted or unencrypted. For more information, see Matching Traffic from Individual Applications.

Step 5 Click Add to Rule to add the selected applications to the Selected Applications and Filters list.

You can also drag and drop selected applications and filters. Filters appear under the heading Filters, and applications appear under the heading Applications.

Tip Before you add another filter to this application condition, click Clear All Filters to clear your existing selections.

list to save a custom filter comprised of all the individual applications and filters currently in the list.

Use the object manager to manage this on-the-fly-created filter; see Working with Application Filters. Note that you cannot save a filter that includes another user-created filter; you cannot nest user-created filters.

Step 7 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Limitations to Application Control

License: Control

Supported Devices: Any except Series 2 or X-Series

Keep the following points in mind when performing application control.

Speed of Application Identification

The system cannot perform application control before:

- a monitored connection is established between a client and server, and

- the system identifies the application in the session

).

The allowed packets are inspected by the access control policy’s default intrusion policy (not the default action intrusion policy nor the almost-matched rule’s intrusion policy). For more information, see Setting the Default Intrusion Policy for Access Control.

After the system completes its identification, the system applies the access control rule action, as well as any associated intrusion and file policy, to the remaining session traffic that matches its application condition.

Handling Encrypted Traffic

The system can identify and filter unencrypted application traffic that becomes encrypted using StartTLS, such as SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS client hello message, or the server certificate subject distinguished name value.

These applications are tagged SSL Protocol. Applications without this tag can only be detected in unencrypted or decrypted traffic. For information on using the SSL inspection feature to decrypt or block encrypted traffic before the system matches it against access control rules, see Understanding Traffic Decryption.

Handling Application Traffic Packets Without Payloads

The system applies the default policy action to packets that do not have a payload in a connection where an application is identified.

Handling Referred Traffic

To create a rule to act on traffic referred by a web server, such as advertisement traffic, add a condition for the referred application rather than the referring application. For more information, see Special Considerations: Referred Web Applications.

Automatically Enabling Application Detectors

At least one detector must be enabled (see Activating and Deactivating Detectors) for each application rule condition in the policy. If no detector is enabled for an application, the system automatically enables all system-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

Controlling Application Traffic That Uses Multiple Protocols (Skype)

The system can detect multiple types of Skype application traffic. When building an application condition to control Skype traffic, select the Skype tag from the Application Filters list rather than selecting individual applications. This ensures that the system can detect and control all Skype traffic the same way. For more information, see Matching Traffic with Application Filters.

Blocking URLs

License: feature dependent

Supported Devices: Any except Series 2

Supported Defense Centers: feature dependent

URL conditions in access control rules allow you to limit the websites that users on your network can access. This feature is called URL filtering. There are two ways you can use access control to specify URLs you want to block (or, conversely, allow):

- With any license, you can manually specify individual URLs or groups of URLs to achieve granular, custom control over web traffic.

- With a URL Filtering license, you can also control access to websites based on the URL’s general classification, or category , and risk level, or reputation . The system displays this category and reputation data in connection logs, intrusion events, and application details.

Note To see URL category and reputation information in events, you must create at least one access control rule with a URL condition.

When you block a website, you can either allow the user’s browser its default behavior, or you can display a generic system-provided or custom page. You can also give users a chance to bypass a website block by clicking through a warning page.

Due to memory resources, the ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5512-X, ASA5515-X, ASA5516-X, ASA5525-X, and 71xx Family devices use a smaller URL category database than the database used by other models, including the ASA5545-X, ASA5555-X, and the ASA5585-X.

The smaller database does not contain entries for some popular sub-domains of popular domains. As an example, mail.google.com is not in the smaller database and as a result mail.google.com is categorized as a search engine and not web-based mail as expected.

Handling Encrypted Web Traffic

If you configure SSL inspection (see Understanding Traffic Decryption) to decrypt encrypted traffic, access control rules evaluate the decrypted traffic as if it were unencrypted. However, if your SSL inspection configuration allows encrypted connections to pass undecrypted, or if you do not configure SSL inspection, access control rules evaluate encrypted traffic.

When evaluating web traffic using access control rules with URL conditions, the system matches HTTPS traffic based on the subject common name in the public key certificate used to encrypt the traffic. Also, the system disregards subdomains within the subject common name, so do not include subdomain information when manually filtering HTTPS URLs. For example, use example.com rather than www.example.com.

Also, the system disregards the encryption protocol (HTTP vs HTTPS). This occurs for both manual and reputation-based URL conditions. In other words, access control rules treat traffic to the following websites identically:

- http://example.com/

- https://example.com/

To configure an access control rule that matches only HTTP or HTTPS traffic, add an application condition to the rule. For example, you could allow HTTPS access to a site while disallowing HTTP access by constructing two access control rules, each with an application and URL condition.

Action: Block

Application: HTTP

URL: example.com

Note By default, the system disables intrusion and file inspection of encrypted payloads as soon as it detects an attempt to encrypt the session. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Using the SSL Preprocessor.

Table 16-2 License and Model Requirements for URL Filtering

Requirement

Category & Reputation-Based

Manual

license

URL Filtering

Any

devices

Any except Series 2

Any except Series 2

Defense Centers

Any except DC500

Any

For more information, see:

- Performing Reputation-Based URL Blocking

- Performing Manual URL Blocking

- Limitations to URL Detection and Blocking

- Allowing Users to Bypass URL Blocks

- Displaying a Custom Web Page for Blocked URLs

Performing Reputation-Based URL Blocking

License: URL Filtering

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

With a URL Filtering license, you can control your users’ access to websites based on the category and reputation of requested URLs, which the FireSIGHT System obtains from the Cisco cloud:

- The URL category is a general classification for the URL. For example, ebay.com belongs to the Auctions category, and monster.com belongs to the Job Search category. A URL can belong to more than one category.

- The URL reputation represents how likely the URL is to be used for purposes that might be against your organization’s security policy. A URL’s risk can range from High Risk (level 1) to Well Known (level 5).

Note Before access control rules with category and reputation-based URL conditions can take effect, you must enable communications with the Cisco cloud. This allows the Defense Center to retrieve URL data. For more information, see Enabling Cloud Communications.

Advantages to Reputation-Based URL Blocking

URL categories and reputations allow you to quickly create URL conditions for access control rules. For example, you could create an access control rule that identifies and blocks all High Risk URLs in the Abused Drugs category. If a user attempts to browse to any URL with that category and reputation combination, the session is blocked.

Using category and reputation data from the Cisco cloud also simplifies policy creation and administration. It grants you assurance that the system will control web traffic as expected. Finally, because the cloud is continually updated with new URLs, as well as new categories and risks for existing URLs, you can ensure that the system uses up-to-date information to filter requested URLs. Malicious sites that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and apply new policies.

Some examples include:

- If a rule blocks all gaming sites, as new domains get registered and classified as Gaming , the system can block those sites automatically.

- If a rule blocks all malware sites, and a blog page gets infected with malware, the cloud can recategorize the URL from Blog to Malware and the system can block that site.

- If a rule blocks high-risk social networking sites, and somebody posts a link on their profile page that contains links to malicious payloads, the cloud can change the reputation of that page from Benign sites to High Risk so the system can block it.

Note that if the cloud does not know the category or reputation of a URL, or if the Defense Center cannot contact the cloud, that URL does not trigger access control rules with category or reputation-based URL conditions. You cannot assign categories or reputations to URLs manually.

Building URL Conditions

You can add a maximum of 50 items to the Selected URLs to match in a single URL condition. Each URL category, optionally qualified by reputation, counts as a single item. Note that you can also use literal URLs and URL objects in URL conditions, but you cannot qualify these items with a reputation. For more information, see Performing Manual URL Blocking.

The following table summarizes how you build the condition shown above. Note that you cannot qualify a literal URL or URL object with a reputation.

Table 16-3 Example: Building A URL Condition

To block...

Select this Category or URL Object...

And this Reputation...

malware sites, regardless of reputation

Malware Sites

Any

any URL with a high risk (level 1)

Any

1 - High Risk

social networking sites with a risk greater than benign (levels 1 through 3)

Social Network

3 - Benign sites with security risks

example.com

the URL object named example.com

none

When building a URL condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

Caution Adding o r removing a URL category or reputation condition in an access control rule restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To control traffic by requested URL using category and reputation data:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by URL, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the URLs tab.

The URLs tab appears.

Step 3 Find and select the categories of URL you want to add from the Categories and URLs list. To match web traffic regardless of category, select Any category.

To search for categories to add, click the Search by name or value prompt above the Categories and URLs list, then type the category name. The list updates as you type to display matching categories.

To select a category, click it. To select multiple categories, use the Shift and Ctrl keys.

Tip Although you can right-click and Select All categories, adding all categories this way exceeds the 50-item maximum for an access control rule. Instead, use Any.

Step 4 Optionally, qualify your category selections by clicking a reputation level from the Reputations list. If you do not specify a reputation level, the system defaults to Any, meaning all levels.

You can only select one reputation level. When you choose a reputation level, the access control rule behaves differently depending on its purpose:

- If the rule blocks or monitors web access (the rule action is Block , Block with reset , Interactive Block , Interactive Block with reset , or Monitor ) selecting a reputation level also selects all reputations more severe than that level. For example, if you configure a rule to block or monitor Suspicious sites (level 2), it also automatically blocks or monitors High risk (level 1) sites.

- If the rule allows web access, whether to trust or further inspect it (the rule action is Allow or Trust ), selecting a reputation level also selects all reputations less severe than that level. For example, if you configure a rule to allow Benign sites (level 4), it also automatically allows Well known (level 5) sites.

If you change the rule action for a rule, the system automatically changes the reputation levels in URL conditions according to the above points.

Step 5 Click Add to Rule or drag and drop the selected items to add them to the Selected URLs list.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Performing Manual URL Blocking

License: Any

Supported Devices: Any except Series 2

To supplement or selectively override URL filtering by category and reputation, you can control web traffic by manually specifying individual URLs or groups of URLs. This allows you to achieve granular, custom control over allowed and blocked web traffic. You can also perform this type of URL filtering without a special license.

To manually specify URLs to allow or block in an access control rule, you can type in a single literal URL. Or, you can configure URL conditions using URL objects, which are reusable and associate a name with a URL or IP address.

Tip After you create a URL object, you can use it not only to build access control rules, but also to represent URLs in various other places in the system’s web interface. You can create these objects using the object manager; you can also create URL objects on-the-fly while you are configuring access control rules. For more information, see Working with URL Objects.

Manually Specifying URLs in URL Conditions

Although manual entry gives you precise control over allowed and blocked web traffic, you cannot qualify a manually specified URL with a reputation. Additionally, you must make sure that your rules do not have unintended consequences. To determine whether network traffic matches a URL condition, the system performs a simple substring match. If the value of a URL object or manually typed URL matches any part of a URL requested by a monitored host, the URL condition of the access control rule is satisfied.

Therefore, when manually specifying URLs in URL conditions, including in URL objects, carefully consider other traffic that might be affected. For example, if you allow all traffic to example.com, your users could browse to URLs including:

- http://example.com/

- http://example.com/newexample

- http://www.example.com/

As another example, consider a scenario where you want to explicitly block ign.com (a gaming site). However, substring matching means that blocking ign.com also blocks verisign.com, which might not be your intent.

Manually Blocking Encrypted Web Traffic

Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to pass, or if you do not configure SSL inspection; see Understanding Traffic Decryption. URL conditions in access control rules:

- disregard the encryption protocol of web traffic (HTTP vs HTTPS)

For example, access control rules treat traffic to http://example.com/ the same as traffic to https://example.com/. To configure an access control rule that matches only HTTP or HTTPS traffic, add an application condition to the rule. For more information, see Blocking URLs.

- match HTTPS traffic based on the subject common name in the public key certificate used to encrypt the traffic, and also disregard subdomains within the subject common name

Do not include subdomain information when manually filtering HTTPS traffic.

When building a URL condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control web traffic by manually specifying URLs to allow or block:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by URL, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the URLs tab.

The URLs tab appears.

Step 3 Find and select the URL objects and groups you want to add from the Categories and URLs list:

- To add a URL object on the fly, which you can then add to the condition, click the add icon (

) above the Categories and URLs list; see Working with URL Objects.

- To search for URL objects and groups to add, click the Search by name or value prompt above the Categories and URLs list, then type either the name of the object, or the value of a URL or IP address in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys. Although you can right-click and Select All URL objects and categories, adding URLs this way exceeds the 50-item maximum for an access control rule.

Step 4 Click Add to Rule or to add the selected items to the Selected URLs list.

You can also drag and drop selected items.

Step 5 Add any literal URLs that you want to specify manually. You cannot use wildcards (*) in this field.

Click the Enter URL prompt below the Selected URLs list; then type a URL or IP address and click Add.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Limitations to URL Detection and Blocking

License: Any

Supported Devices: Any except Series 2

Keep the following points in mind when performing URL detection and blocking.

Speed of URL Identification

The system cannot filter URLs before:

- a monitored connection is established between a client and server

- the system identifies the HTTP or HTTPS application in the session

- the system identifies the requested URL (for encrypted sessions, from either the client hello message or the server certificate)

).

The allowed packets are inspected by the access control policy’s default intrusion policy (not the default action intrusion policy nor the almost-matched rule’s intrusion policy). For more information, see Setting the Default Intrusion Policy for Access Control.

After the system completes its identification, the system applies the access control rule action, as well as any associated intrusion and file policy, to the remaining session traffic that matches its URL condition.

Handling Encrypted Web Traffic

When evaluating encrypted web traffic using access control rules with URL conditions, the system:

- disregards the encryption protocol; an access control rule matches both HTTPS and HTTP traffic if the rule has a URL condition but not an application condition that specifies the protocol

- matches HTTPS traffic based on the subject common name in the public key certificate used to encrypt the traffic, and disregards subdomains within the subject common name

- does not display an HTTP response page, even if you configured one

HTTP Response Pages

HTTP response pages do not appear when web traffic is blocked:

- and the session is or was encrypted

- by a Series 3 device as a result of a promoted access control rule

- in cases where the system does not identify the requested URL in the connection until after the connection has been established and allowed to flow for a few packets, as described above

For more information, see Displaying a Custom Web Page for Blocked URLs.

Search Query Parameters in URLs

The system does not use search query parameters in the URL to match URL conditions. For example, consider a scenario where you block all shopping traffic. In that case, using a web search to search for amazon.com is not blocked, but browsing to amazon.com is.

Allowing Users to Bypass URL Blocks

License: Any

Supported Devices: Any except Series 2

When you block a user’s HTTP web request using an access control rule, setting the rule action to Interactive Block or Interactive Block with reset gives that user a chance to bypass the block by clicking through a warning HTTP response page. You can display a generic system-provided response page or you can enter custom HTML.

By default, the system allows users to bypass blocks for 10 minutes (600 seconds) without displaying the warning page on subsequent visits. You can set the duration to as long as a year, or you can force the user to bypass the block every time.

If the user does not bypass the block, matching traffic is denied without further inspection; you can also reset the connection. On the other hand, if a user bypasses the block, the system allows the traffic. Allowing this traffic means that you can continue to inspect unencrypted payloads for intrusions, malware, prohibited files, and discovery data. Note that users may have to refresh after bypassing the block to load page elements that did not load.

Note that you configure the interactive HTTP response page separately from the response page you configure for Block rules. For example, you could display the system-provided page to users whose sessions are blocked without interaction, but a custom page to users who can click to continue. For more information, see Displaying a Custom Web Page for Blocked URLs.

Note that in the following situations, the response page does not appear and traffic is blocked without interaction, even if the session matches an Interactive Block rule:

- if the session was or is encrypted; this includes sessions decrypted by the system

- after a connection has been established and allowed to flow for a few packets so the system can inspect it for requested URLs and application details; see Troubleshooting Access Control Policies and Rules

Tip To quickly disable interactive blocking for all rules in an access control policy, display neither the system-provided page nor a custom page. This causes the system to block all connections that match an Interactive Block rule without interaction.

To allow users to bypass a website block:

Access: Admin/Access Admin/Network Admin

Step 1 Create an access control rule that matches web traffic with a URL condition.

See Performing Reputation-Based URL Blocking and Performing Manual URL Blocking.

Step 2 Make sure the access control rule action is Interactive Block or Interactive Block with reset.

See Using Rule Actions to Determine Traffic Handling and Inspection.

Step 3 Assume users will bypass the block and choose inspection and logging options for the rule accordingly. As with Allow rules:

- You can associate either type of Interactive Block rule with a file and intrusion policy. The system can also use discovery to inspect this user-allowed traffic. For more information, see Controlling Traffic Using Intrusion and File Policies.

- Logging options for interactively blocked traffic are identical to those in allowed traffic, but keep in mind that if a user does not bypass the interactive block, the system can log only beginning-of-connection events.

Note that when the system initially warns the user, it marks any logged beginning-of-connection event with the Interactive Block or Interactive Block with reset action. If the user bypasses the block, additional connection events logged for the session have an action of Allow. For more information, see Logging Connections Based on Access Control Handling.

Step 4 Optionally, set the amount of time that elapses after a user bypasses a block before the system displays the warning page again.

See Setting the User Bypass Timeout for a Blocked Website.

Step 5 Optionally, create and use a custom page to display to allow users to bypass a block.

See Displaying a Custom Web Page for Blocked URLs.

Setting the User Bypass Timeout for a Blocked Website

License: Any

By default, the system allows a user to bypass interactive blocks for 10 minutes (600 seconds) without displaying the warning page on subsequent visits. You can set the duration to as long as a year, or to zero to force the user to bypass the block every time. This limit applies to every Interactive Block rule in the policy. You cannot set the limit per rule.

To customize the length of time before a user bypass expires:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select the Advanced tab.

Advanced settings for the access control policy appear.

) next to General Settings.

The General Settings pop-up window appears.

Step 5 In the Allow an Interactive Block to bypass blocking for (seconds) field, type the number of seconds that must elapse before the user bypass expires.

You can specify any number of seconds from zero to 31536000 (one year). Specifying zero forces your users to bypass the block every time.

Step 6 Click OK.

Advanced settings for the access control policy appear.

Step 7 Click Save.

You must apply the access control policy for your changes to take effect. For more information, see Applying an Access Control Policy.

Displaying a Custom Web Page for Blocked URLs

License: Any

Supported Devices: Any except Series 2

When the system blocks a user’s HTTP web request, what the user sees in a browser depends on how you block the session, using the access control rule’s action. You should select:

- Block or Block with reset to deny the connection. A blocked session times out; the system resets Block with reset connections. However, for both blocking actions, you can override the default browser or server page with a custom page that explains that the connection was denied. The system calls this custom page an HTTP response page .

- Interactive Block or Interactive Block with reset if you want to display an interactive HTTP response page that warns users, but also allows them to click a button to continue or refresh the page to load the originally requested site. Users may have to refresh after bypassing the response page to load page elements that did not load.

You can either display a generic system-provided response page, or you can enter custom HTML. When you enter custom text, a counter shows how many characters you have used.

In each access control policy, you configure the interactive HTTP response page separately from the response page you use to block traffic without interaction, that is, using a Block rule. For example, you could display the system-provided page to users whose sessions are blocked without interaction, but a custom page to users who can click to continue.

Reliable display of HTTP response pages to your users depends on your network configuration, traffic loads, and size of the page. If you build a custom response page, keep in mind that a smaller page is more likely to display successfully.

To configure HTTP response pages:

Access: Admin/Access Admin/Network Admin

Step 1 Edit the access control policy that targets the devices monitoring your web traffic.

For more information, see Editing Access Control Policies.

Step 2 Select the HTTP Responses tab.

HTTP response page settings for the access control policy appear.

Step 3 For the Block Response Page and the Interactive Block Response Page, select responses from the drop-down lists. For each page, you have the following choices:

- To use a generic response, select System-provided . You can click the view icon (

) to view the HTML code for this page.

- To create a custom response, select Custom .

).

- To prevent the system from displaying an HTTP response page, select None . Note that selecting this option for interactively blocked sessions prevents users from clicking to continue; the session is blocked without interaction.

Step 4 Click Save.

You must apply the access control policy for your changes to take effect. For more information, see Applying an Access Control Policy.

Controlling Traffic Based on Users

Access control rules within access control policies exert granular control over network traffic logging and handling. User conditions in access control rules allow you perform user control—to manage which traffic can traverse your network, by limiting traffic based on the LDAP user logged into a host.

User control works by associating access-controlled users with IP addresses. Deployed agents monitor specified users as they log in and out of hosts or authenticate with Active Directory credentials for other reasons. For example, your organization may use services or applications that rely on Active Directory for centralized authentication.

For traffic to match an access control rule with a user condition, the IP address of either the source or destination host in the monitored session must be associated with a logged in access-controlled user. You can control traffic based on individual users or the groups those users belong to.

You can combine user conditions with each other and with other types of conditions to create an access control rule. These access control rules can be simple or complex, matching and inspecting traffic using multiple conditions. For detailed information on access control rules, see Tuning Traffic Flow Using Access Control Rules.

Note Hardware-based fast-path rules, Security Intelligence-based traffic filtering, and some decoding and preprocessing occur before network traffic is evaluated by access control rules. You can also configure the SSL inspection feature to block or decrypt encrypted traffic before access control rules evaluate it.

User control requires a Control license and is supported only for LDAP users and groups (access-controlled users), using login and logoff records reported by a User Agent monitoring Microsoft Active Directory servers.

However, with only a FireSIGHT license you can still take advantage of user awareness, which is the basis of user control. User awareness allows you to view agent-reported user activity as well as additional activity for non-access-controlled users, which the system can detect when managed devices examine allowed network traffic for discovery data. The system can identify login attempts over various protocols: AIM, IMAP, LDAP, Oracle, POP3, SIP, FTP, HTTP, and MDNS.

To add context to the user activity reported by the system, you can query an LDAP server in your deployment to retrieve metadata for not only access-controlled users, but also some non-access-controlled users: POP3 and IMAP users detected by user discovery and LDAP users whose activity is detected by either user discovery or a User Agent.

User awareness allows all types of deployments to determine the “who” behind the “what.” For example, you could determine:

- who is attempting unauthorized access of a server that has high host criticality

- who is consuming an unreasonable amount of bandwidth

- who has not applied critical operating system updates

- who is using instant messaging software or peer-to-peer file-sharing applications in violation of company IT policy

- who owns the host targeted by an intrusion event that has a Vulnerable (level 1: red) impact level (requires Protection)

- who initiated an internal attack or portscan (requires Protection)

Armed with this information, you can take a targeted approach to mitigate risk, and take action to protect others from disruption. User control adds the ability to block LDAP users and user activity. Together, user awareness and control capabilities significantly improve audit controls and enhance regulatory compliance. For more information, see Understanding User Data Collection.

The following table lists the requirements for user awareness and control. For detailed, up-to-date information on User Agents, see the User Agent Configuration Guide.

Table 17-1 Requirements for User Awareness and Control

Requirement

User Awareness

User Control

license

FireSIGHT

Control

devices

Any

Any except Series 2 or X-Series

Defense Centers

Any

Any except DC500

User Agent

Install Version 2.2 of the User Agent on a Windows computer running one of the following, with TCP/IP access to and from the Defense Center and Microsoft Active Directory servers you want to monitor:

- Windows Vista, Windows 7, or Windows 8

- Windows Server 2008 or 2012

You must also install Microsoft .NET Framework Version 4.0 Client Profile and Microsoft SQL Server Compact (SQL CE) Version 3.5.

LDAP server for user metadata retrieval

One of the following, with TCP/IP access from the Defense Center:

- Microsoft Active Directory on Windows Server 2008 (required for user control)

- Oracle Directory Server Enterprise Edition 7.0 on Windows Server 2008 (user awareness only)

- OpenLDAP on Linux (user awareness only)

For more information, see:

- Adding a User Condition to an Access Control Rule

- Retrieving Access-Controlled Users and LDAP User Metadata

- Using User Agents to Report Active Directory Logins

Adding a User Condition to an Access Control Rule

License: Control

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

The FireSIGHT System’s user control feature works by associating access-controlled users with host IP addresses. Deployed User Agents monitor specified users as they authenticate with Microsoft Active Directory credentials. For traffic to match an access control rule with a user condition, the IP address of either the source or destination host in the monitored session must be associated with a logged in access-controlled user.

Before you can perform user control, you must:

- Configure a connection between the Defense Center and a Microsoft Active Directory server; see Retrieving Access-Controlled Users and LDAP User Metadata.

- Install a User Agent on a Microsoft Windows computer with TCP/IP access to the Active Directory server; see Using User Agents to Report Active Directory Logins.

Caution If you configure a large number of user groups to monitor, or if you have a very large number of users mapped to hosts on your network, the system may drop user mappings based on groups, due to memory limitations. As a result, access control rules based on user groups may not fire as expected.

You can add a maximum of 50 users and groups to the Selected Users in a single user condition. Conditions with user groups match traffic to or from any of the group’s members, including members of any sub-groups, with the exception of individually excluded users and members of excluded sub-groups.

Note Before you can perform user control using a group criterion, the system must detect activity from at least one user in that group. This initial connection is not handled by the access control rule it matches, but instead by the next rule it matches, or the access control policy default action.

When building a user condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

To control user traffic:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy that targets the devices where you want to control traffic by LDAP user or group, create a new access control rule or edit an existing rule.

For detailed instructions, see Creating and Editing Access Control Rules.

Step 2 In the rule editor, select the Users tab.

The Users tab appears.

Step 3 Find and select the users and groups you want to add from the Available Users list.

Users and groups are marked with different icons. To search for users and groups to add, click the Search by name or value prompt above the Available Users list, then type the name of the user or group. The list updates as you type to display matching items.

To select an item, click it. To select multiple item, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule to add the selected users and groups to the Selected Users list.

You can also drag and drop selected users and groups.

Step 5 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Retrieving Access-Controlled Users and LDAP User Metadata

License: FireSIGHT or Control

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Before you can perform user control (that is, write access control rules with user conditions), you must configure a connection between the Defense Center and at least one of your organization’s Microsoft Active Directory servers. The Defense Center regularly and automatically queries the LDAP server to update metadata for access-controlled users, that is, the users and groups whose activity you want to monitor with User Agents, and who you can use as criteria when limiting traffic. The Defense Center also retrieves metadata for non-access-controlled users whose activity has already been reported by a User Agent. Alternately, you can perform an on-demand query.

If you are not performing user control, you can query additional types of LDAP server for user awareness data—metadata associated with POP3 and IMAP users as well as LDAP users whose activity is detected by user discovery, rather than reported by an User Agent. The system uses the email addresses in POP3 and IMAP logins to correlate with LDAP users on an Active Directory, OpenLDAP, or Oracle Directory Server Enterprise Edition server. In this case, the Defense Center regularly queries the LDAP server to obtain new and updated metadata for users whose activity the system detected since the last query.

For more information, see:

- Connecting to an LDAP Server for User Awareness and Control

- Updating User Control Parameters On-Demand

- Pausing Communications with an LDAP Server

Connecting to an LDAP Server for User Awareness and Control

License: FireSIGHT or Control

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Connections between Defense Centers and your organization’s LDAP servers can:

- specify the access-controlled users and groups whose activity you want to monitor with User Agents, and who you can use as criteria when limiting traffic with access control rules

- allow you to query the server for metadata on access-controlled users, as well as some non-access-controlled users: POP3 and IMAP users detected by user discovery and LDAP users whose activity is detected by either user discovery or a User Agent.

These connections, or user awareness objects, specify connection settings and authentication filter settings for the LDAP server. They are similar to the authentication objects you configure to manage external authentication to the FireSIGHT System’s web interface; see Managing Authentication Objects.

To perform user control, you must connect to a Microsoft Active Directory LDAP server. If you simply want to retrieve LDAP user metadata, the system supports connections to other types of LDAP server; see Table 17-1.

When the system detects user activity, it can add a record of that user to the Defense Center users database, also called the user identity database. The Defense Center regularly queries the LDAP server to obtain metadata for new and updated users whose activity was detected since the last query. If a user already exists in the database, the system updates the metadata if it has not been updated in the last 12 hours. It may take several minutes for the Defense Center to update with user metadata after the system detects a new user login.

The system uses the email addresses in POP3 and IMAP logins to correlate with users on the LDAP server. For example, if a managed device detects a POP3 login for a user with the same email address as an LDAP user, the system associates the LDAP user’s metadata with that user.

Note If you remove a user that has been detected by the system from your LDAP servers, the Defense Center does not remove that user from its users database; you must manually delete it. However, your LDAP changes are reflected in access control rules when the Defense Center next updates its list of access-controlled users.

Table 17-2 Mapping LDAP Fields to Cisco Fields

Metadata

Defense Center

Active Directory

Oracle Directory Server

OpenLDAP

LDAP user name

Username

samaccountname

cn

uid

cn

uid

first name

First Name

givenname

givenname

givenname

last name

Last Name

sn

sn

sn

email address

Email

mail

userprincipalname (if mail has no value)

mail

mail

department

Department

department

distinguishedname (if department has no value)

department

ou

telephone number

Phone

telephonenumber

n/a

telephonenumber

Work closely with your LDAP administrators to ensure your LDAP servers are correctly configured and that you can connect to them, and to obtain the information you must provide when creating an LDAP connection.

Server Type, IP Address, and Port

You must specify the server type, IP address or hostname, and port for a primary, and optionally a backup, LDAP server. To perform user control, you must use a Microsoft Active Directory server.

LDAP-Specific Parameters

When the Defense Center searches the LDAP server to retrieve user information on the authentication server, it needs a starting point for that search. You can specify the namespace, or directory tree, to search by providing a base distinguished name, or base DN. Typically, the base DN has a basic structure indicating the company domain and operational unit. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com. Note that after you identify a primary server, you can automatically retrieve a list of available base DNs from the server and select the appropriate base DN.

You must supply user credentials for a user with appropriate rights to the user information you want to retrieve. Remember that the distinguished name for the user you specify must be unique to the directory information tree for the directory server.

You can also specify an encryption method for the LDAP connection. Note that if you are using a certificate to authenticate, the name of the LDAP server in the certificate must match the host name that you specified in the Defense Center web interface. For example, if you use 10.10.10.250 when configuring the LDAP connection but computer1.example.com in the certificate, the connection fails.

Finally, you must specify the timeout period after which attempts to contact an unresponsive LDAP server roll over to the backup connection.

User and Group Access Control Parameters

To perform user control, specify the groups you want to use as criteria in access control rules.

Including a group automatically includes all of that group’s members, including members of any sub-groups. However, if you want to use the sub-group in access control rules, you must explicitly include the sub-group. You can also exclude groups and individual users. Excluding a group excludes all the members of that group, even if the users are members of an included group.

The maximum number of users you can use in access control depends on your FireSIGHT license. When choosing which users and groups to include, make sure the total number of users is less than your FireSIGHT user license. If your access control parameters are too broad, the Defense Center obtains information on as many users as it can and reports the number of users it failed to retrieve in the task queue.

Note If you do not specify any groups to include, the system retrieves user data for all the groups that match the LDAP parameters you provided. For performance reasons, Cisco recommends that you explicitly include only the groups that represent the users you want to use in access control. Note that you cannot include the Users or Domain Users groups.

You must also specify how often the Defense Center queries the LDAP server to obtain new users to use in access control.

). If the connection is enabled, your saved changes take effect when the Defense Center next queries the LDAP server.

To create an LDAP connection for user awareness or user control:

Access: Admin/Discovery Admin

Step 1 Select Policies > Users.

The Users Policy page appears.

Step 2 Click Add LDAP Connection.

The Create User Awareness Authentication Object page appears.

Step 3 Type a Name and Description for the object.

Step 4 Select the LDAP Server Type.

If you want to perform user control, you must use a Microsoft Active Directory server.

Note User Agents cannot transmit Active Directory user names ending with the $ character to the Defense Center. You must remove the final $ character if you want to monitor these users.

Step 5 Specify an IP Address or Host Name for a primary and, optionally, a backup LDAP server.

Step 6 Specify the Port that your LDAP servers use for authentication traffic.

Step 7 Specify the Base DN for the LDAP directory you want to access.

For example, to authenticate names in the Security organization at the Example company, type ou=security,dc=example,dc=com.

Tip To fetch a list of all available domains, click Fetch DNs and select the appropriate base distinguished name from the drop-down list.

Step 8 Specify the distinguished User Name and Password that you want to use to validate access to the LDAP directory. Confirm the password.

For example, if you are connecting to an OpenLDAP server where user objects have a uid attribute and the object for the administrator in the Security division at our example company has a uid value of NetworkAdmin, you would type uid=NetworkAdmin,ou=security,dc=example,dc=com.

Step 9 Choose an Encryption method. If you are using encryption, you can add an SSL Certificate.

The host name in the certificate must match the host name of the LDAP server you specified in step 5.

Step 10 Specify the Timeout period (in seconds) timeout period after which attempts to contact an unresponsive primary LDAP server roll over to the backup connection.

Step 11 Optionally, before you specify user awareness settings for the object, test the connection by clicking Test.

Step 12 You have two options, depending on the type of LDAP server you selected in step 4:

- If you are connecting to an Active Directory server, you can enable User/Group Access Control Parameters to specify users to use in access control. Continue with the next step.

- If you are connecting to any other kind of server, or do not want to perform user control, skip to step 17.

Step 13 Click Fetch Groups to populate the available groups list using the LDAP parameters you provided.

Step 14 Specify the users you want to use in access control by using the right and left arrow buttons to include and exclude groups.

Including a group automatically includes all of that group’s members, including members of any sub-groups. However, if you want to use the sub-group in access control rules, you must explicitly include the sub-group. Excluding a group excludes all the members of that group, even if the users are members of an included group.

Step 15 Specify any particular User Exclusions.

Excluding a user prevents you from writing an access control rule using that user as a condition. Separate multiple users with commas. You can also use an asterisk (*) as a wildcard character in this field.

Step 16 Specify how often you want to query the LDAP server to obtain new user and group information.

By default, the Defense Center queries the server once a day at midnight:

- Use the Start At drop-down list to specify when you want the query to occur. 0 represents midnight, 1 represents 1:00 AM, and so on.

- Use the Update Interval drop-down list to specify how often, in hours, you want to query the server.

Step 17 Click Save.

If you added or made changes to user and group access control parameters, confirm that you want to implement your changes. The object is saved and the Users Policy page appears again.

Step 18 Enable the connection by clicking the slider next to the connection you just created.

If you are enabling the connection and your connection has user and group access control parameters, choose whether you want to immediately query the LDAP server to obtain user and group information. Note that if you do not immediately query the LDAP server, the query occurs at the scheduled time. You can monitor any query’s progress in the task queue (System > Monitoring > Task Status).

Updating User Control Parameters On-Demand

License: Control

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

If you change the user and group access control parameters in an LDAP connection, or if you change the users or groups on your LDAP server and want your changes to be immediately available for user control, you can force the Defense Center to perform an on-demand user data retrieval from the Active Directory server.

The maximum number of users the Defense Center can retrieve from the server depends on your FireSIGHT license. If the access control parameters in your LDAP connection are too broad, the Defense Center obtains information on as many users as it can and reports the number of users it failed to retrieve in the task queue.

To perform an on-demand user data retrieval:

Access: Admin/Discovery Admin

Step 1 Select Policies > Users.

The Users Policy page appears.

).

The query begins. You can monitor its progress in the task queue (System > Monitoring > Task Status).

Pausing Communications with an LDAP Server

License: FireSIGHT or Control

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Only enabled LDAP connections allow the Defense Center to query LDAP servers. To stop queries, you can temporarily disable LDAP connections rather than deleting them.

When you re-enable an LDAP connection used for access control, you can force the Defense Center to query the server immediately for updated user and group information, or you can wait until the first scheduled query occurs.

To disable or re-enable an LDAP connection:

Access: Admin/Discovery Admin

Step 1 Select Policies > Users.

The Users Policy page appears.

Step 2 Pause or re-enable the connection by clicking the slider next to the connection you just created.

If you are re-enabling the connection and your connection has user and group access control parameters, choose whether you want to immediately query the LDAP server to obtain user and group information. If you do not immediately query the LDAP server, the query occurs at the scheduled time. You can monitor any query’s progress in the task queue (System > Monitoring > Task Status).

Using User Agents to Report Active Directory Logins

License: FireSIGHT

User Agents deployed on Microsoft Windows computers can monitor Microsoft Active Directory servers, then notify the Defense Center when LDAP users in your organization log in and out of hosts, or authenticate with Active Directory credentials for other reasons. For example, your organization may use services or applications that rely on Active Directory for centralized authentication.

This agent-reported information serves not only as a record of user activity in your organizations, but also as the basis of user control. For traffic to match an access control rule with a user condition, the IP address of either the source or destination host in the monitored session must be associated with a logged in access-controlled user. You can control traffic based on individual users or the groups those users belong to.

Note If you want to perform user control, you must install and use User Agents. However, User Agents only report user activity related to Active Directory authentications. User awareness allows you to view all agent-reported user activity, as well as additional activity detected in allowed network traffic by managed devices. The system uses the discovery feature to identify login attempts over various protocols: AIM, IMAP, LDAP, Oracle, POP3, SIP, FTP, HTTP, and MDNS. For more information, see Understanding User Data Collection.

To retrieve LDAP user authentication records with User Agents for either user awareness or control, first configure each Defense Center to allow connections from the agents. In a high availability deployment, enable agent communications on both the primary Defense Center and the secondary Defense Center. User Agents can connect to up to five Defense Centers at a time. After you enable User Agent communications on the Defense Center, you can install agents on Windows computers; see Table 17-1.

Finally, configure User Agents to receive data from Microsoft Active Directory servers and report the information to Defense Centers. You can also configure agents to exclude specific user names and IP addresses from the reporting, and log status messages to a local event log or the Windows application log. The User Agent Status Monitor health module monitors agents connected to a Defense Center; see Configuring User Agent Status Monitoring.

To configure the Defense Center to connect to a User Agent:

Access: Admin/Discovery Admin

Step 1 Select Policies > Users.

The Users Policy page appears.

Step 2 Click Add User Agent.

The Add User Agent pop-up window appears.

Step 3 Type a Name for the agent.

Step 4 Type the Hostname or Address of the computer where you plan to install the agent. You must use an IPv4 address; you cannot configure the Defense Center to connect to a User Agent using an IPv6 address.

Step 5 Click Add User Agent.

) and confirm that you want to delete it.

Step 6 Install User Agent on the computer you specified. Configure it to receive data from Microsoft Active Directory servers and report the information to Defense Centers.

For detailed, up-to-date information, see the User Agent Configuration Guide.

Controlling Traffic Using Intrusion and File Policies

Intrusion and file policies work together as part of the FireSIGHT System, as the last line of defense before traffic is allowed to its destination:

- Intrusion policies govern the system’s intrusion prevention capabilities; see Understanding Network Analysis and Intrusion Policies.

- File policies govern the system’s network-based file control and advanced malware protection (AMP) capabilities; see Understanding and Creating File Policies.

Hardware-based fast-pathing, Security Intelligence-based traffic filtering (blacklisting), SSL inspection-based decisions, and traffic decoding and preprocessing occur before network traffic is examined for intrusions, prohibited files, and malware. Access control rules and the access control default action determine which traffic is inspected by intrusion and file policies.

By associating an intrusion or file policy with an access control rule, you are telling the system that before it passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an intrusion policy, a file policy, or both.

Note By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Understanding Traffic Decryption and Using the SSL Preprocessor.

Table 18-1 License and Model Requirements for Intrusion and File Inspection

Feature

Description

License

Supported Defense Centers

Supported Devices

intrusion prevention

detect and optionally block intrusions and exploits

Protection

Any

Any

file control

detect and optionally block the transmission of file types

Protection

Any

Any

advanced malware protection (AMP)

detect, store, track, and optionally block the transmission of malware

submit captured files to the Cisco cloud to analyze for malware

Malware

Any except DC500

Any except Series 2 or X-Series

If your organization has a FireAMP subscription, the Defense Center can also receive endpoint-based malware detection data from the Cisco cloud. The Defense Center presents this data alongside any network-based file and malware data generated by the system. Importing FireAMP data does not require a license in addition to your FireAMP subscription. For more information, see Working with Cloud Connections for FireAMP.

For more information on inspecting traffic for intrusions, prohibited files, and malware, see:

- Inspecting Allowed Traffic For Intrusions and Malware

- Tuning Intrusion Prevention Performance

- Tuning File and Malware Inspection Performance and Storage

Inspecting Allowed Traffic For Intrusions and Malware

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Intrusion and file policies govern the system’s intrusion prevention, file control, and AMP capabilities as a last line of defense before traffic is allowed to its destination. Hardware-based fast-path rules, Security Intelligence-based traffic filtering, SSL inspection decisions (including decryption), decoding and preprocessing, and access control rule selection occur before intrusion and file inspection.

Access control rules provide a granular method of handling network traffic across multiple managed devices. By associating an intrusion or file policy with an access control rule, you are telling the system that before it passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an intrusion policy, a file policy, or both. Access control rule conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, and user.

The system matches traffic to access control rules in the order you specify. In most cases, the system handles network traffic according to the first access control rule where all the rule’s conditions match the traffic. An access control rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow (with or without further inspection) matching traffic; see Using Rule Actions to Determine Traffic Handling and Inspection.

The following diagram shows the flow of traffic in an inline intrusion prevention and AMP deployment, as governed by an access control policy that contains four different types of access control rules and a default action.

In the scenario above, the first three access control rules in the policy—Monitor, Trust, and Block—cannot inspect matching traffic. Monitor rules track and log but do not inspect network traffic, so the system continues to match traffic against additional rules to determine whether to permit or deny it. Trust and Block rules handle matching traffic without further inspection of any kind, while traffic that does not match continues to the next access control rule.

The fourth and final rule in the policy, an Allow rule, invokes various other policies to inspect and handle matching traffic, in the following order:

- Discovery: Network Discovery Policy— First, the network discovery policy inspects traffic for discovery data. Discovery is passive analysis and does not affect the flow of traffic. Although you do not explicitly enable discovery, you can enhance or disable it. However, allowing traffic does not automatically guarantee discovery data collection. The system performs discovery only for connections involving IP addresses that are explicitly monitored by your network discovery policy. For more information, see Introduction to Network Discovery.

- Advanced Malware Protection and File Control: File Policy— After traffic is inspected by discovery, the system can inspect it for prohibited files and malware. Network-based AMP detects and optionally blocks malware in many types of files, including PDFs, Microsoft Office documents, and others. If your organization wants to block not only the transmission of malware files, but all files of a specific type (regardless of whether the files contain malware), file control allows you to monitor network traffic for transmissions of specific file types, then either block or allow the file.

- Intrusion Prevention: Intrusion Policy— After file inspection, the system can inspect traffic for intrusions and exploits. An intrusion policy examines decoded packets for attacks based on patterns, and can block or alter malicious traffic . Intrusion policies are paired with variable sets , which allow you to use named values to accurately reflect your network environment.

- Destination— Traffic that passes all the checks described above passes to its destination.

Note that an Interactive Block rule (not shown in the diagram) has the same inspection options as an Allow rule. This is so you can inspect traffic for malicious content when a user bypasses a blocked website by clicking through a warning page. For more information, see Interactive Blocking Actions: Allowing Users to Bypass Website Blocks.

Traffic that does not match any of the non-Monitor access control rules in the policy is handled by the default action. In this scenario, the default action is an Intrusion Prevention action, which allows traffic to its final destination as long as it is passed by the intrusion policy you specify. In a different deployment, you might have a default action that trusts or blocks all traffic without further inspection; see Table 12-4. Note that the system can inspect traffic allowed by the default action for discovery data and intrusions, but not prohibited files or malware. You cannot associate a file policy with the access control default action.

Note Sometimes, when a connection is analyzed by an access control policy, the system must process the first few packets in that connection, allowing them to pass, before it can decide which access control rule (if any) will handle the traffic. However, so these packets do not reach their destination uninspected, you can use an intrusion policy—called the default intrusion policy—to inspect them and generate intrusion events. For more information, see Setting the Default Intrusion Policy for Access Control.

For more information on the above scenario and instructions on associating file and intrusion policies with access control rules and the access control default action, see:

- Understanding File and Intrusion Inspection Order

- Configuring an Access Control Rule to Perform AMP or File Control

- Configuring an Access Control Rule to Perform Intrusion Prevention

- Setting Default Handling and Inspection for Network Traffic

Understanding File and Intrusion Inspection Order

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The scenario in Inspecting Allowed Traffic For Intrusions and Malware shows one access control rule of each type, including an Allow rule associated with both a file policy and intrusion policy. In your access control policy, you can associate multiple Allow and Interactive Block rules with different intrusion and file policies to match inspection profiles to various types of traffic.

Note Traffic allowed by an Intrusion Prevention or Network Discovery Only default action can be inspected for discovery data and intrusions, but cannot be inspected for prohibited files or malware. You cannot associate a file policy with the access control default action.

You do not have to perform both file and intrusion inspection in the same rule. For a connection matching an Allow or Interactive Block rule:

- without a file policy, traffic flow is determined by the intrusion policy

- without an intrusion policy, traffic flow is determined by the file policy

- without either, allowed traffic is inspected by network discovery only

Tip The system does not perform any kind of inspection on trusted traffic. Although configuring an Allow rule with neither an intrusion nor file policy passes traffic like a Trust rule, Allow rules let you perform discovery on matching traffic.

For any single connection handled by an access control rule, file inspection occurs before intrusion inspection. That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple blocking by type takes precedence over malware inspection and blocking.

For example, consider a scenario where you normally want to allow certain network traffic as defined in an access control rule. However, as a precaution, you want to block the download of executable files, examine downloaded PDFs for malware and block any instances you find, and perform intrusion inspection on the traffic.

You create an access control policy with a rule that matches the characteristics of the traffic you want to provisionally allow, and associate it with both an intrusion policy and a file policy. The file policy blocks the download of all executables, and also inspects and blocks PDFs containing malware:

- First, the system blocks the download of all executables, based on simple type matching specified in the file policy. Because they are immediately blocked, these files are subject to neither malware cloud lookup nor intrusion inspection.

- Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network. Any PDFs with a malware file disposition are blocked, and are not subject to intrusion inspection.

- Finally, the system uses the intrusion policy associated with the access control rule to inspect any remaining traffic, including files not blocked by the file policy.

Note Until a file is detected and blocked in a session packets from the session may be subject to intrusion inspection.

Configuring an Access Control Rule to Perform AMP or File Control

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

An access control policy can have multiple access control rules associated with file policies. You can configure file inspection for any Allow or Interactive Block access control rule, which permits you to match different file and malware inspection profiles against different types of traffic on your network before it reaches its final destination.

When the system detects a prohibited file (including malware) according to the settings in the file policy, it automatically logs an event to the Defense Center database. If you do not want to log file or malware events, you can disable this logging on a per-access-control-rule basis. After you associate the file policy with the access control rule, clear the Log Files check box on the Logging tab of the access control rule editor. For more information, see Disabling File and Malware Event Logging for Allowed Connections.

The system also logs the end of the associated connection to the Defense Center database, regardless of the logging configuration of the invoking access control rule; see Connections Associated with File and Malware Events (Automatic).

Caution Associating a file policy with an access control rule, or subsequently dissociating the policy by selecting None, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To associate a file policy with an access control rule:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy where you want to configure AMP or file control using access control rules.

Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules.

The access control rule editor appears.

Step 4 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.

Step 5 Select the Inspection tab.

The Inspection tab appears.

Step 6 Select a File Policy to inspect traffic that matches the access control rule, or select None to disable file inspection for matching traffic.

) that appears to edit the policy in a new browser tab; see Creating a File Policy.

Step 7 Click Add to save the rule.

Your rule is saved. You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Configuring an Access Control Rule to Perform Intrusion Prevention

License: Protection

An access control policy can have multiple access control rules associated with intrusion policies. You can configure intrusion inspection for any Allow or Interactive Block access control rule, which permits you to match different intrusion inspection profiles against different types of traffic on your network before it reaches its final destination.

Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Variables in a set represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions and dynamic rule states.

Tip Even if you use system-provided intrusion policies, Cisco strongly recommends you configure the system’s intrusion variables to accurately reflect your network environment. At a minimum, modify default variables in the default set; see Optimizing Predefined Default Variables.

The number of unique intrusion policies you can use in a single access control policy depends on the model of the target devices; more powerful devices can handle more. Every unique pair of intrusion policy and variable set counts as one policy. Although you can associate a different intrusion policy-variable set pair with each Allow and Interactive Block rule (as well as with the default action), you cannot apply an access control policy if the target devices have insufficient resources to perform inspection as configured. For more information, see Simplifying Rules to Improve Performance.

Understanding System-Provided and Custom Intrusion Policies

Cisco delivers several intrusion policies with the FireSIGHT System. By using system-provided intrusion policies, you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states, as well as provides the initial configurations for advanced settings. You can use system-provided policies as-is, or you can use them as the base for custom policies. Building custom policies can improve the performance of the system in your environment and provide a focused view of the malicious traffic and policy violations occurring on your network.

In addition to custom policies that you create, the system provides two custom policies: Initial Inline Policy and Initial Passive Policy. These two intrusion policies use the Balanced Security and Connectivity intrusion policy as their base. The only difference between them is their Drop When Inline setting, which enables drop behavior in the inline policy and disables it in the passive policy. For more information, see Comparing System-Provided with Custom Policies.

Connection and Intrusion Event Logging

When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, it saves that event to the Defense Center database. The system also automatically logs the end of the connection where the intrusion occurred to the Defense Center database, regardless of the logging configuration of the access control rule; see Connections Associated with Intrusions (Automatic).

Caution Associating an intrusion policy with an access control rule, or subsequently dissociating the policy by selecting None, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To associate an intrusion policy with an access control rule:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy where you want to configure intrusion inspection using access control rules.

Step 3 Create a new rule or edit an existing rule; see Creating and Editing Access Control Rules.

The access control rule editor appears.

Step 4 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.

Step 5 Select the Inspection tab.

The Inspection tab appears.

Step 6 Select a system-provided or custom Intrusion Policy, or select None to disable intrusion inspection for traffic that matches the access control rule.

) that appears to edit the policy in a new browser tab; see Editing Intrusion Policies.

Step 7 Optionally, change the Variable Set associated with the intrusion policy.

) that appears to edit the variable set in a new browser tab; see Working with Variable Sets.

Step 8 Click Save to save the rule.

Your rule is saved. You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Tuning Intrusion Prevention Performance

License: Protection

Cisco provides several features for improving the performance of your system as it analyzes traffic for attempted intrusions. You configure these performance settings on a per-access-control-policy basis, and they apply to all intrusion policies invoked by that parent access control policy.

For more information, see:

- Limiting Pattern Matching for Intrusions describes how you can specify the number of packets to allow in the event queue, and enable or disable inspection of packets that will be rebuilt into larger streams.

- Overriding Regular Expression Limits for Intrusion Rules describes how you can override default match and recursion limits on Perl-compatible regular expressions (PCRE).

- Limiting Intrusion Events Generated Per Packet describes how you can configure rule processing event queue settings.

- Configuring Packet and Intrusion Rule Latency Thresholds describes settings for packet and rule latency thresholding.

- Configuring Intrusion Performance Statistic Logging describes how you can configure your managed devices’ basic performance monitoring and reporting parameters.

Limiting Pattern Matching for Intrusions

License: Protection

You can specify the number of packets to allow in the event queue. You can also, before and after stream reassembly, enable or disable inspection of packets that will be rebuilt into larger streams.

To configure event queue settings:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

tab in the pop-up window that appears.

Step 5 You can modify the following options:

- Type a value for the maximum number of events to queue in the Maximum Pattern States to Analyze Per Packet field.

- To inspect packets which will be rebuilt into larger streams of data before and after stream reassembly, select Disable Content Checks on Traffic Subject to Future Reassembly . Inspection before and after reassembly requires more processing overhead and may decrease performance.

- To disable inspection of packets which will be rebuilt into larger streams of data before and after stream reassembly, clear Disable Content Checks on Traffic Subject to Future Reassembly . Disabling inspection decreases the processing overhead for inspection of stream inserts and may boost performance.

Step 6 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Overriding Regular Expression Limits for Intrusion Rules

License: Protection

You can override default match and recursion limits on PCRE that are used in intrusion rules to examine packet payload content. See Searching for Content Using PCRE for information on using the pcre keyword in intrusion rules. The default limits ensure a minimum level of performance. Overriding these limits could increase security, but could also significantly impact performance by permitting packet evaluation against inefficient regular expressions.

Caution Do not override default PCRE limits unless you are an experienced intrusion rule writer with knowledge of the impact of degenerative patterns.

Table 18-2 Regular Expression Constraint Options

Option

Description

Match Limit State

Specifies whether to override Match Limit. You have the following options:

- select Default to use the value configured for Match Limit

- select Unlimited to permit an unlimited number of attempts

- select Custom to specify either a limit of 1 or greater for Match Limit , or to specify 0 to completely disable PCRE match evaluations

Match Limit

Specifies the number of times to attempt to match a pattern defined in a PCRE regular expression.

Match Recursion Limit State

Specifies whether to override Match Recursion Limit. You have the following options:

- select Default to use the value configured for Match Recursion Limit

- select Unlimited to permit an unlimited number of recursions

- select Custom to specify either a limit of 1 or greater for Match Recursion Limit , or to specify 0 to completely disable PCRE recursions

Note that for Match Recursion Limit to be meaningful, it must be smaller than Match Limit.

Match Recursion Limit

Specifies the number of recursions when evaluating a PCRE regular expression against the packet payload.

To configure PCRE overrides:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

, then select the Regular Expression Limits tab in the pop-up window that appears.

Step 5 You can modify any of the options in the Regular Expression Constraint Options table.

Step 6 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Limiting Intrusion Events Generated Per Packet

License: Protection

When the rules engine evaluates traffic against rules, it places the events generated for a given packet or packet stream in an event queue, then reports the top events in the queue to the user interface. You can elect to have the rules engine log more than one event per packet or packet stream when multiple events are generated. Logging these events allows you to collect information beyond the reported event. When configuring this option, you can specify how many events can be placed in the queue and how many are logged, and select the criteria for determining event order within the queue.

Table 18-3 Intrusion Event Logging Limits Options

Option

Description

Maximum Events Stored Per Packet

The maximum number of events that can be stored for a given packet or packet stream.

Maximum Events Logged Per Packet

The number of events logged for a given packet or packet stream. This cannot exceed the Maximum Events Stored Per Packet value.

Prioritize Event Logging By

The value used to determine event ordering within the event queue. The highest ordered event is reported through the user interface. You can select from:

- priority , which orders events in the queue by the event priority.

- content_length , which orders events by the longest identified content match. When events are ordered by content length, rule events always take precedence over decoder and preprocessor events.

To configure how many events are logged per packet or stream:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

tab in the pop-up window that appears.

Step 5 You can modify any of the options in the Intrusion Event Logging Limits Options table.

Step 6 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Configuring Packet and Intrusion Rule Latency Thresholds

License: Protection

Settings for packet and rule latency thresholding maintain device latency. For more information, see:

- Understanding Packet Latency Thresholding

- Configuring Packet Latency Thresholding

- To disable packet latency thresholding:

- Configuring Rule Latency Thresholding

Understanding Packet Latency Thresholding

License: Protection

You can balance security with the need to maintain latency at an acceptable level by enabling packet latency thresholding. Packet latency thresholding measures the total elapsed time taken to process a packet by applicable decoders, preprocessors, and rules, and ceases inspection of the packet if the processing time exceeds a configurable threshold.

Packet latency thresholding measures elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing.

The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.

As illustrated in the above figure, packet latency timing is tested at the following test points:

- after the completion of all decoder and preprocessor processing and before rule processing begins

- after processing by each rule

If the processing time exceeds the threshold at any test point, packet inspection ceases.

Tip Total packet processing time does not include routine TCP stream or IP fragment reassembly times.

Packet latency thresholding has no effect on events triggered by a decoder, preprocessor, or rule processing the packet. Any applicable decoder, preprocessor, or rule triggers normally until a packet is fully processed, or until packet processing ends because the latency threshold is exceeded, whichever comes first. If a drop rule detects an intrusion in an inline deployment, the drop rule triggers an event and the packet is dropped.

Note No packets are evaluated against rules after processing for that packet ceases because of a packet latency threshold violation. A rule that would have triggered an event cannot trigger that event, and for drop rules, cannot drop the packet.

For more information on drop rules, see Setting Rule States.

Packet latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by stopping inspection of packets that require excessive processing time. These performance benefits might occur when, for example:

- for both passive and inline deployments, sequential inspection of a packet by multiple rules requires an excessive amount of time

- for inline deployments, a period of poor network performance, such as when someone downloads an extremely large file, slows packet processing

In a passive deployment, stopping the processing of packets might not contribute to restoring network performance because processing simply moves to the next packet.

Configuring Packet Latency Thresholding

License: Protection

Table 18-4 Packet Latency Thresholding Options

Option

Description

Threshold (microseconds)

Specifies the time, in microseconds, when inspection of a packet ceases.

You can enable rule 134:3 to generate an event when the system stops inspecting a packet because the packet latency threshold is exceeded. See Setting Rule States for more information.

To configure packet latency thresholding:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

, then select the Packet Handling tab in the pop-up window that appears.

Tip By default, packet latency thresholding is enabled. To completely disable latency thresholding, clear the Enable checkbox.

Step 5 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

To disable packet latency thresholding:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

, then select the Packet Handling tab in the pop-up window that appears.

Step 5 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Understanding Rule Latency Thresholding

License: Protection

Rule latency thresholding measures the elapsed time each rule takes to process an individual packet, suspends the violating rule along with a group of related rules for a specified time if the processing time exceeds the rule latency threshold a configurable consecutive number of times, and restores the rules when the suspension expires.

Rule latency thresholding measures elapsed time, not just processing time, in order to more accurately reflect the actual time required for the rule to process a packet. However, latency thresholding is a software-based latency implementation that does not enforce strict timing.

The trade-off for the performance and latency benefits derived from latency thresholding is that uninspected packets could contain attacks.

A timer measures the processing time each time a packet is processed against a group of rules. Any time the rule processing time exceeds a specified rule latency threshold, the system increments a counter. If the number of consecutive threshold violations reaches a specified number, the system takes the following actions:

- suspends the rules for the specified period

- triggers an event indicating the rules have been suspended

- re-enables the rules when the suspension expires

- triggers an event indicating the rules have been re-enabled

The system zeroes the counter when the group of rules has been suspended, or when rule violations are not consecutive. Permitting some consecutive violations before suspending rules lets you ignore occasional rule violations that might have negligible impact on performance and focus instead on the more significant impact of rules that repeatedly exceed the rule latency threshold.

In the above example, the time required to process each of the first three packets violates the rule latency threshold of 1000 microseconds, and the violations counter increments with each violation. Processing of the fourth packet does not violate the threshold, and the violations counter resets to zero. The fifth packet violates the threshold and the violations counter restarts at one.

The following example shows five consecutive rule processing times that do result in rule suspension.

In the second example, the time required to process each of the five packets violates the rule latency threshold of 1000 microseconds. The group of rules is suspended because the rule processing time of 1100 microseconds for each packet violates the threshold of 1000 microseconds for the specified five consecutive violations. Any subsequent packets, represented in the figure as packets 6 through n, are not examined against suspended rules until the suspension expires. If more packets occur after the rules are re-enabled, the violations counter begins again at zero.

Rule latency thresholding has no effect on intrusion events triggered by the rules processing the packet. A rule triggers an event for any intrusion detected in the packet, regardless of whether the rule processing time exceeds the threshold. If the rule detecting the intrusion is a drop rule in an inline deployment, the packet is dropped. When a drop rule detects an intrusion in a packet that results in the rule being suspended, the drop rule triggers an intrusion event, the packet is dropped, and that rule and all related rules are suspended. For more information on drop rules, see Setting Rule States.

Note Packets are not evaluated against suspended rules. A suspended rule that would have triggered an event cannot trigger that event and, for drop rules, cannot drop the packet.

Rule latency thresholding can improve system performance in both passive and inline deployments, and can reduce latency in inline deployments, by suspending rules that take the most time to process packets. Packets are not evaluated again against suspended rules until a configurable time expires, giving the overloaded device time to recover. These performance benefits might occur when, for example:

- hastily written, largely untested rules require an excessive amount of processing time

- a period of poor network performance, such as when someone downloads an extremely large file, causes slow packet inspection

Configuring Rule Latency Thresholding

License: Protection

Rule latency thresholding suspends rules for the time specified by Suspension Time when the time rules take to process a packet exceeds Threshold for the consecutive number of times specified by Consecutive Threshold Violations Before Suspending Rule.

You can enable rule 134:1 to generate an event when rules are suspended, and rule 134:2 to generate an event when suspended rules are enabled. See Viewing Intrusion Events and Setting Rule States for more information.

Table 18-5 Rule Latency Thresholding Options

Option

Description

Threshold

Specifies the time in microseconds that rules should not exceed when examining a packet.

Consecutive Threshold Violations Before Suspending Rule

Specifies the consecutive number of times rules can take longer than the time set for Threshold to inspect packets before rules are suspended.

Suspension Time

Specifies the number of seconds to suspend a group of rules.

To configure rule latency thresholding:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

, then select the Rule Handling tab in the pop-up window that appears.

Step 5 You can configure any of the options in the Rule Latency Thresholding Options table.

Step 6 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Configuring Intrusion Performance Statistic Logging

License: Protection

You can configure the basic parameters of how devices monitor and report their own performance. This allows you to specify the intervals at which the system updates performance statistics on your devices by configuring the following options.

Sample time (seconds) and Minimum number of packets

When the number of seconds specified elapses between performance statistics updates, the system verifies it has analyzed the specified number of packets. If it has, the system updates performance statistics. Otherwise, the system waits until it analyzes the specified number of packets.

Troubleshooting Options: Log Session/Protocol Distribution

Support might ask you during a troubleshooting call to log protocol distribution, packet length, and port statistics.

Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.

Troubleshooting Options: Summary

Support might ask you during a troubleshooting call to configure the system to calculate the performance statistics only when the Snort® process is shut down or restarted. To enable this option, you must also enable the Log Session/Protocol Distribution troubleshooting option.

Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.

To configure basic performance statistics parameters:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

, then select the Performance Statistics tab in the pop-up window that appears.

Step 5 Modify the Sample time or Minimum number of packets as described above.

Step 6 Optionally, expand the Troubleshoot Options section and modify those options only if asked to do so by Support.

Step 7 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Tuning File and Malware Inspection Performance and Storage

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

If you use file policies to perform file control, file storage, dynamic analysis, or malware detection or blocking, you can set the options listed in the following table. Keep in mind that increasing the file sizes can affect the performance of the system.

Caution Changing a value of an access control policy Files and Malware Settings advanced setting restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Table 18-6 Advanced Access Control File and Malware Detection Options

Field

Description

Default Value

Range

Notes

Limit the number of bytes inspected when doing file type detection

Specify the number of bytes inspected when performing file type detection.

1460 bytes, or the maximum segment size of a TCP packet

0 - 4294967295 (4GB)

Set to 0 to remove the restriction.

In most cases, the system can identify common file types using the first packet.

Do not calculate SHA-256 hash values for files larger than (in bytes)

Prevent the system from storing files larger than a certain size, performing a Collective Security Intelligence Cloud lookup on the files, or blocking the files if added to the custom detection list.

10485760 (10MB)

0 - 4294967295 (4GB)

Set to 0 to remove the restriction.

This value must be greater than or equal to Maximum file size to store (bytes) and Maximum file size for dynamic analysis testing (bytes).

Allow file if cloud lookup for Block Malware takes longer than (seconds)

Specify how long the system will hold the last byte of a file that matches a Block Malware rule and that does not have a cached disposition, while malware cloud lookup occurs. If the time elapses without the system obtaining a disposition, the file passes. Dispositions of Unavailable are not cached.

2 seconds

0 - 30 seconds

Although this option accepts values of up to 30 seconds, Cisco recommends that you use the default value to avoid blocking traffic because of connection failures. Do not set this option to 0 without contacting Support.

Minimum file size to store (bytes)

Specify the minimum file size the system can store using a file rule.

6144 (6KB)

0 - 10485760 (10MB)

Set to 0 to disable file storage.

This field must be less than or equal to Maximum file size to store (bytes) and Do not calculate SHA-256 hash values for files larger than (in bytes).

Maximum file size to store (bytes)

Specify the maximum file size the system can store using a file rule.

1048576 (1MB)

0 - 10485760 (10MB)

Set to 0 to disable file storage.

This field must be greater than or equal to Minimum file size to store (bytes), and less than or equal to Do not calculate SHA-256 hash values for files larger than (in bytes).

Minimum file size for dynamic analysis testing (bytes)

Specify the minimum file size the system can submit to the cloud for dynamic analysis.

6144 (6KB)

6144 (6KB) -2097152 (2MB)

This field must be less than or equal to Maximum file size for dynamic analysis testing (bytes) and Do not calculate SHA-256 hash values for files larger than (in bytes).

The system checks the cloud for updates to the minimum file size you can submit (no more than once a day). If the new minimum size is larger than your current value, your current value is updated to the new minimum, and your policy is marked out-of-date.

Maximum file size for dynamic analysis testing (bytes)

Specify the maximum file size the system can submit to the cloud for dynamic analysis.

1048576 (1MB)

6144 (6KB) -2097152 (2MB)

This field must be greater than or equal to Minimum file size for dynamic analysis testing (bytes), and less than or equal to Do not calculate SHA-256 hash values for files larger than (in bytes).

The system checks the cloud for updates to the maximum file size you can submit (no more than once a day). If the new maximum size is smaller than your current value, your current value is updated to the new maximum, and your policy is marked out-of-date.

Note that because you cannot use a Malware license with a DC500, nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture, store, or block individual files, analyze the contents of archive files, submit files for dynamic analysis, or view file trajectories for files for which you conduct a malware cloud lookup.

To configure file and malware inspection performance and storage:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

.

The Files and Malware Settings pop-up window appears.

Step 5 You can set any of the options in the Advanced Access Control File and Malware Detection Options table.

Step 6 Click OK.

You must save and apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Understanding Traffic Decryption

By default, the system cannot inspect traffic encrypted with the Secure Socket Layer (SSL) or Transport Layer Security (TLS) protocols. As part of access control, the SSL inspection feature allows you to either block encrypted traffic without inspecting it, or inspect encrypted or decrypted traffic with access control. As the system handles encrypted sessions, it logs details about the traffic. The combination of inspecting encrypted traffic and analyzing encrypted session data allows greater awareness and control of the encrypted applications and traffic in your network.

If the system detects an SSL or TLS handshake over a TCP connection, it determines whether it can decrypt the detected traffic. If it cannot, it applies a configured action:

- block the encrypted traffic, and optionally reset the TCP connection

- not decrypt the encrypted traffic

Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to pass, or if you do not configure SSL inspection. However, some access control rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Creating and Editing Access Control Rules and Using the SSL Preprocessor.

If the system can decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted traffic with access control, or decrypts it using one of the following methods:

- Decrypt with a known private key. When an external host initiates an SSL handshake with a server on your network, the system matches the exchanged server certificate with a server certificate previously uploaded to the appliance. It then uses the uploaded private key to decrypt the traffic.

- Decrypt by re-signing the server certificate. When a host on your network initiates an SSL handshake with an external server, the system re-signs the exchanged server certificate with a previously uploaded certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.

Decrypted traffic is subject to the same traffic handling and analysis as originally unencrypted traffic: network, reputation, and user-based access control; intrusion detection and prevention; advanced malware protection; and discovery. If the system does not block the decrypted traffic post-analysis, it reencrypts the traffic before passing it to the destination host.

Note Certain SSL inspection actions, such as blocking traffic and decrypting outgoing traffic, modify the flow of traffic. Devices deployed inline can perform these actions. Devices deployed passively or in tap mode cannot affect the flow of traffic. However, these devices can still decrypt incoming traffic; see Example: Decrypting Traffic in a Passive Deployment for more information.

For more information, see the following sections:

- SSL Inspection Requirements

- Analyzing SSL Inspection Appliance Deployments

SSL Inspection Requirements

License: feature dependent

Supported Devices: Series 3

Only certain appliance models support SSL inspection. How you deploy the appliances on your network, in addition to your configuration settings and licenses, influences the actions you can take to control and decrypt encrypted traffic.

Available features and actions to configure SSL inspection depend on your user role. The system includes predefined user roles designed for a variety of administrators and analysts, and you can create custom user roles with specialized access privileges.

SSL inspection requires public key certificates and paired private keys for certain features. You must upload certificates and paired private keys to the Defense Center to decrypt and control traffic based on encryption session characteristics.

For more information, see the following sections:

- Deploying Appliances that Support SSL Inspection

- Determining Necessary Licenses for SSL Inspection

- Managing Your SSL Inspection Deployment with Custom User Roles

- Collecting Prerequisite Information to Configure SSL Rules

Deploying Appliances that Support SSL Inspection

License: Any

Supported Devices: Series 3

SSL inspection requires a Series 3 device.

Devices configured and deployed with inline, routed, switched, or hybrid interfaces can modify the flow of traffic. These devices can monitor, block, allow, and decrypt incoming and outgoing traffic.

Devices configured and deployed with passive or inline (tap mode) interfaces cannot affect the flow of traffic. They can only monitor, allow, and decrypt incoming traffic. Note that passive deployments do not support decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve Diffie-Hellman (ECDHE) cipher suites.

Review your list of mapped actions, existing network deployment, and overall requirements to determine whether one or the other type of deployment better suits your organization. See Analyzing SSL Inspection Appliance Deployments for more information.

Determining Necessary Licenses for SSL Inspection

License: feature dependent

) and confirmation dialog boxes to designate unsupported features for your deployment. For details, hover your pointer over a warning icon.

You apply an SSL policy to a managed device as part of an access control policy, and the access control policy inspects traffic decrypted by the SSL policy. See Access Control License and Role Requirements for more information on access control licensing.

The following table explains the license requirements to apply an SSL policy as part of an access control policy.

Table 19-1 License and Model Requirements for SSL Inspection

To apply an SSL policy that...

Licenses

Supported Defense Centers

Supported Devices

handles encrypted traffic on the basis of zone, network, VLAN, port, or SSL-related criteria

Any

Any

Series 3

handles encrypted traffic using geolocation data

FireSIGHT

Any except DC500

Series 3

handles encrypted traffic using application or user criteria

Control

Any, except the DC500 cannot perform user control

Series 3

filters encrypted traffic using URL category and reputation data

URL Filtering

Any except DC500

Series 3

Managing Your SSL Inspection Deployment with Custom User Roles

License: Any

Table 19-2 SSL Inspection-Related User Role Permissions

User Permission

Description

Object Manager

allows you to create, modify, and delete objects related to SSL inspection

SSL

allows you to generate reports for SSL policies and compare SSL policies or policy revisions

Modify SSL Policy

allows you to view, create, modify, and delete an SSL policy, and create, modify, and delete SSL rules not in the Administrator Rules or Root Rules categories

Modify Administrator Rules

allows you to create, modify, and delete SSL rules in the Administrator Rules category

Modify Root Rules

allows you to create, modify, and delete SSL rules in the Root Rules category

Apply SSL Policy

allows you to apply an SSL policy if you apply the access control policy with which it is associated

Access Control List

allows you to view the list of access control policies

Modify Access Control Policy

allows you to associate an SSL policy with an access control policy

Apply Access Control Policies

allows you to apply the access control policy associated with the SSL policy

For more information, see Access Control License and Role Requirements.

Collecting Prerequisite Information to Configure SSL Rules

License: feature-dependent

SSL inspection relies on a significant amount of supporting public key infrastructure (PKI) information. Consider your organization’s traffic patterns to determine the matching rule conditions you can configure. Collect the information listed in the following table:

Table 19-3 SSL Rule Condition Prerequisites

To match on...

Collect the...

detected server certificates, including self-signed server certificates

server certificate

trusted server certificates

CA certificate

detected server certificate subject or issuer

server certificate subject DN or issuer DN

For more information, see Tuning Traffic Decryption Using SSL Rules.

Table 19-4 SSL Decryption Prerequisites

To decrypt...

Collect...

incoming traffic to a server you control

the server’s certificate file and paired private key file

outgoing traffic to an external server

a CA certificate file and paired private key file

You can also generate a CA certificate and private key.

For more information, see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection.

After you have collected this information, upload it to the system and configure reusable objects. See Managing Reusable Objects for more information.

Analyzing SSL Inspection Appliance Deployments

License: feature-dependent

Supported Devices: Series 3

This section presents several scenarios in which the Life Insurance Example, Inc. life insurance company (LifeIns) uses SSL inspection on encrypted traffic to help audit their processes. Based on their business processes, LifeIns plans to deploy:

- one Series 3 managed device in a passive deployment for the Customer Service department

- one Series 3 managed device in an inline deployment for the Underwriting Department

- one Defense Center to manage both devices

Customer Service Business Processes

LifeIns created a customer-facing website for their customers. LifeIns receives encrypted questions and requests regarding policies from prospective customers through their website and through e-mail. LifeIns’s Customer Service department processes them and returns the requested information within 24 hours. Customer Service wants to expand its incoming contact metrics collection. LifeIns has an established internal audit review for Customer Service.

LifeIns also receives encrypted applications online. The Customer Service department processes the applications within 24 hours before sending the case file to the Underwriting department. Customer Service filters out any obvious false applications sent through the online form, which consumes a fair portion of their time.

Underwriting Business Processes

LifeIns’s underwriters submit encrypted medical information requests online to the Medical Repository Example, LLC medical data repository (MedRepo). MedRepo reviews the requests and transmits the encrypted records to LifeIns within 72 hours. The underwriters subsequently underwrite an application and submit policy and rate decisions. Underwriting wants to expand its metrics collection.

Lately, an unknown source has been sending spoofed responses to LifeIns. Though LifeIns’s underwriters receive training on proper Internet use, LifeIns’s IT department first wants to analyze all encrypted traffic that takes the form of medical responses, then wants to block all spoof attempts.

LifeIns places junior underwriters on six-month training periods. Lately, these underwriters have been incorrectly submitting encrypted medical regulation requests to MedRepo’s customer service department. MedRepo has submitted multiple complaints to LifeIns in response. LifeIns plans on extending their new underwriter training period to also audit underwriter requests to MedRepo.

For more information, see the following sections:

- Example: Decrypting Traffic in a Passive Deployment

- Example: Decrypting Traffic in an Inline Deployment

Example: Decrypting Traffic in a Passive Deployment

License: feature-dependent

Supported Devices: Series 3

LifeIns’s business requirements state that Customer Service must:

- process all requests and applications within 24 hours

- improve its incoming contact metrics collection process

- identify and discard incoming false applications

Customer Service does not require additional audit review.

Traffic from an external network goes to LifeIns’s router. The router routes traffic to the Customer Service department, and mirrors a copy of the traffic to the managed device for inspection.

On the managing Defense Center, a user in the Access Control and SSL Editor custom role configures SSL inspection to:

- log all encrypted traffic sent to the Customer Service department

- decrypt encrypted traffic sent using the online application form to Customer Service

- not decrypt all other encrypted traffic sent to Customer service, including traffic sent using the online request form

The user also configures access control to inspect the decrypted application form traffic for fake application data and log when fake data is detected.

In the following scenarios, the user submits an online form to Customer Service. The user’s browser establishes a TCP connection with the server, then initiates an SSL handshake. The managed device receives a copy of this traffic. The client and server complete the SSL handshake, establishing the encrypted session. Based on handshake and connection details, the system logs the connection and acts upon the copy of the encrypted traffic.

For more information, see the following:

- Monitoring Encrypted Traffic in a Passive Deployment

- Not Decrypting Encrypted Traffic in a Passive Deployment

- Inspecting Encrypted Traffic with a Private Key in a Passive Deployment

Monitoring Encrypted Traffic in a Passive Deployment

License: Any

Supported Devices: Series 3

For all SSL-encrypted traffic sent to Customer Service, the system logs the connection. The following diagram illustrates the system monitoring encrypted traffic.

The following steps occur:

1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (info).

4. The managed device does not decrypt the traffic.

The access control policy continues to process the encrypted traffic and allows it. The device generates a connection event after the session ends.

5. The Defense Center receives the connection event.

Not Decrypting Encrypted Traffic in a Passive Deployment

License: Any

Supported Devices: Series 3

The following steps occur:

1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (info).

4. The managed device does not decrypt the traffic.

The access control policy continues to process the encrypted traffic and allows it. The device generates a connection event after the session ends.

5. The Defense Center receives the connection event.

Inspecting Encrypted Traffic with a Private Key in a Passive Deployment

License: Any

Supported Devices: Series 3

For all SSL-encrypted traffic that contains application form data, the system decrypts the traffic and logs the connection.

Note In a passive deployment, if traffic is encrypted with either the DHE or ECDHE cipher suite, you cannot decrypt it with a known private key.

The following steps occur:

1. The user submits the plain text request (form). The client encrypts this (AaBb) and sends the encrypted traffic to Customer Service.

2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts it to plain text (form).

4. The managed device uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text (form).

The access control policy continues to process the decrypted traffic and does not find fake application information. The device generates a connection event after the session ends.

5. The Defense Center receives a connection event with information about the encrypted and decrypted traffic.

The following steps occur:

1. The user submits the plain text request (fake). The client encrypts this (CcDd) and sends the encrypted traffic to Customer Service.

2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It also mirrors a copy to the managed device.

3. The Customer Service department server receives the encrypted information request (CcDd) and decrypts it to plain text (fake).

4. The managed device uses the session key obtained with the uploaded known private key to decrypt the encrypted traffic to plain text (fake).

The access control policy continues to process the decrypted traffic and finds fake application information. The device generates an intrusion event. After the session ends, it generates a connection event.

5. The Defense Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the fake application data.

Example: Decrypting Traffic in an Inline Deployment

License: feature-dependent

Supported Devices: Series 3

LifeIns’s business requirements state that Underwriting must:

- audit new and junior underwriters, verifying that their information requests to MedRepo comply with all applicable regulations

- improve its underwriting metrics collection process

- examine all requests that appear to come from MedRepo, then drop any spoofing attempts

- drop all improper regulatory requests to MedRepo’s Customer Service department from the Underwriting department

- not audit senior underwriters

LifeIns plans to deploy a device in an inline deployment for the Underwriting department. The following diagram illustrates LifeIns’s inline deployment.

Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The managed device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the managing Defense Center. LifeIns’s router routes traffic to the destination host.

On the managing Defense Center, a user in the Access Control and SSL Editor custom role configures SSL inspection to:

- log all encrypted traffic sent to the Underwriting department

- block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer service department

- decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s junior underwriters to MedRepo’s requests department

- not decrypt encrypted traffic sent from the senior underwriters

The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:

- block decrypted traffic if it contains a spoof attempt, and log the spoof attempt

- block decrypted traffic that contains information not compliant with regulations, and log the improper information

- allow all other encrypted and decrypted traffic

The system reencrypts allowed decrypted traffic before sending it to the destination host.

In the following scenarios, the user submits information online to a remote server. The user’s browser establishes a TCP connection with the server, then initiates an SSL handshake. The managed device receives this traffic; based on handshake and connection details, the system logs the connection and acts on the traffic. If the system blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL handshake, establishing the encrypted session.

For more information, see the following:

- Monitoring Encrypted Traffic in an Inline Deployment

- Allowing Specific Users’ Encrypted Traffic in an Inline Deployment

- Blocking Encrypted Traffic in an Inline Deployment

- Inspecting Encrypted Traffic with a Private Key in an Inline Deployment

- Inspecting Specific Users’ Encrypted Traffic with a Re-signed Certificate in an Inline Deployment

Monitoring Encrypted Traffic in an Inline Deployment

License: Any

Supported Devices: Series 3

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to MedRepo’s Requests department server.

2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.

3. The managed device does not decrypt the traffic.

The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.

4. The external router receives the traffic and routes it to the Requests department server.

5. The Underwriting department server receives the encrypted information request (AaBb) and decrypts it to plain text (help).

6. The Defense Center receives the connection event.

Allowing Specific Users’ Encrypted Traffic in an Inline Deployment

License: Control

Supported Devices: Series 3

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to MedRepo’s Requests department server.

2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.

3. The managed device does not decrypt this traffic.

The access control policy continues to process the encrypted traffic and allows it, then generates a connection event after the session ends.

4. The external router receives the traffic and routes it to the Requests department server.

5. The Requests department server receives the encrypted information request (AaBb) and decrypts it to plain text (help).

6. The Defense Center receives the connection event.

Blocking Encrypted Traffic in an Inline Deployment

License: Any

Supported Devices: Series 3

The following steps occur:

1. Having received the request to establish an SSL handshake from a client’s browser, the Customer Service department server sends the server certificate (cert) as the next step in the SSL handshake to the LifeIns underwriter.

2. MedRepo’s router receives the certificate and routes it to the LifeIns underwriter.

3. The managed device blocks the traffic without further inspection and ends the TCP connection. It generates a connection event.

4. The internal router does not receive the blocked traffic.

5. The underwriter does not receive the blocked traffic.

6. The Defense Center receives the connection event.

Inspecting Encrypted Traffic with a Private Key in an Inline Deployment

License: Any

Supported Devices: Series 3

For all SSL-encrypted traffic sent from MedRepo to LifeIns’s underwriting department, the system uses an uploaded server private key to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to the Underwriting department.

The following diagram illustrates the system decrypting encrypted traffic with a known private key, then inspecting the traffic using access control and allowing the decrypted traffic.

The following steps occur:

1. The user submits the plain text request (stats). The client encrypts this (AaBbC) and sends the encrypted traffic to the Underwriting department server.

2. The external router receives the traffic and routes it to the Underwriting department server.

3. The managed device uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text (stats).

The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find a spoof attempt. The device passes the encrypted traffic (AaBbC), then generates a connection event after the session ends.

4. The internal router receives the traffic and routes it to the Underwriting department server.

5. The Underwriting department server receives the encrypted information (AaBbC) and decrypts it to plain text (stats).

6. The Defense Center receives the connection event with information about the encrypted and decrypted traffic.

The following steps occur:

1. The user submits the plain text request (spoof), altering the traffic to appear to originate from MedRepo, LLC. The client encrypts this (FfGgH) and sends the encrypted traffic to the Underwriting department server.

2. The managed device uses the session key obtained with the uploaded known private key to decrypt this traffic to plain text (spoof).

The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds a spoof attempt. The device blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.

3. The internal router does not receive the blocked traffic.

4. The Underwriting department server does not receive the blocked traffic.

5. The Defense Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the spoofing attempt.

Inspecting Specific Users’ Encrypted Traffic with a Re-signed Certificate in an Inline Deployment

License: Control

Supported Devices: Series 3

For all SSL-encrypted traffic sent from the new and junior underwriters to MedRepo’s requests department, the system uses a re-signed server certificate to obtain session keys, then decrypts the traffic and logs the connection. Legitimate traffic is allowed and reencrypted before being sent to MedRepo.

Note When decrypting traffic in an inline deployment by re-signing the server certificate, the device acts as a man-in-the-middle. It creates two SSL sessions, one between client and managed device, one between managed device and server. As a result, each session contains different cryptographic session details.

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted traffic to the Requests department server.

2. The internal router receives the traffic and routes it to the Requests department server.

3. The managed device uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text (help).

The access control policy continues to process the decrypted traffic with the custom intrusion policy and does not find an improper request. The device reencrypts the traffic (CcDd), allowing it to pass. It generates a connection event after the session ends.

4. The external router receives the traffic and routes it to the Requests department server.

5. The Requests department server receives the encrypted information (CcDd) and decrypts it to plain text (help).

6. The Defense Center receives the connection event with information about the encrypted and decrypted traffic.

Note Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is not trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store or the client trusted certificates store.

The following steps occur:

1. The user submits the plain text request (regs), which does not comply with regulatory requirements. The client encrypts this (EeFf) and sends the encrypted traffic to the Requests department server.

2. The internal router receives the traffic and routes it to the Requests department server.

3. The managed device uses the session key obtained with a re-signed server certificate and private key to decrypt this traffic to plain text (regs).

The access control policy continues to process the decrypted traffic with the custom intrusion policy and finds an improper request. The device blocks the traffic, then generates an intrusion event. It generates a connection event after the session ends.

4. The external router does not receive the blocked traffic.

5. The Requests department server does not receive the blocked traffic.

6. The Defense Center receives a connection event with information about the encrypted and decrypted traffic, and an intrusion event for the improper request.

Getting Started with SSL Policies

An SSL policy determines how the system handles encrypted traffic on your network. You can configure one or more SSL policies. You associate an SSL policy with an access control policy, then apply the access control policy to a managed device. When the device detects a TCP handshake, the access control policy first handles and inspects the traffic. If it subsequently identifies an SSL-encrypted session over the TCP connection, the SSL policy takes over, handling and decrypting the encrypted traffic. You can have one SSL policy currently applied to a Series 3 device.

The simplest SSL policy, as shown in the following diagram, directs the device where it is applied to handle encrypted traffic with a single default action. You can set the default action to block decryptable traffic without further inspection, or inspect undecrypted decryptable traffic with access control. The system can then either allow or block the encrypted traffic. If the device detects undecryptable traffic, it either blocks the traffic without further inspection or does not decrypt it, inspecting it with access control.

This chapter explains how to create and apply a simple SSL policy. It also contains basic information on managing SSL policies: editing, updating, comparing, and so on. For more information, see:

- Creating a Basic SSL Policy

- Editing an SSL Policy

- Applying Decryption Settings Using Access Control

- Generating a Report of Current Traffic Decryption Settings

- Comparing SSL Policies

A more complex SSL policy can handle different types of undecryptable traffic with different actions, control traffic based on whether a certificate authority (CA) issued or trusts the encryption certificate, and use SSL rules to exert granular control over encrypted traffic logging and handling. These rules can be simple or complex, matching and inspecting encrypted traffic using multiple criteria. After you create a basic SSL policy, see the following chapters for more information on tailoring it to your deployment:

- Managing Reusable Objects describes how to configure reusable public key infrastructure (PKI) objects and other SSL inspection-related objects to enhance encrypted traffic control and decrypt traffic.

- Logging Connections in Network Traffic describes how to configure logging for encrypted traffic, whether decryptable or undecryptable.

- Applying Decryption Settings Using Access Control describes how to associate an SSL policy with an access control policy.

- Getting Started with Access Control Policies describes how to apply an access control policy to a device.

- Tuning Traffic Flow Using Access Control Rules describes how to configure access control rules to inspect decrypted traffic.

- Getting Started with SSL Rules describes how to configure SSL rules to handle and log encrypted traffic.

- Tuning Traffic Decryption Using SSL Rules describes how to configure SSL rule conditions to better match specific encrypted traffic.

Creating a Basic SSL Policy

License: Any

Supported Devices: Series 3

When you create a new SSL policy you must, at minimum, give it a unique name and specify a policy default action. You have the following options when selecting a default action for a new policy:

- Do not decrypt creates a policy with the Do not decrypt default action.

- Block creates a policy with the Block default action.

- Block with reset creates a policy with the Block with reset default action.

After you create the SSL policy, you can modify the default action. For guidance on choosing a default action, see Setting Default Handling and Inspection for Encrypted Traffic.

The new SSL policy also contains default actions for traffic the system cannot decrypt: either it inherits the default action you just selected for undecryptable traffic, blocks it, or does not decrypt the traffic and inspects it with access control. You can modify the undecryptable traffic actions after you create the SSL policy. For guidance on selecting undecryptable traffic actions, see Setting Default Handling for Undecryptable Traffic

On the SSL policy page (Policies > SSL) you can view all your current SSL policies by name with optional description. Options on this page allow you to compare policies, create a new policy, copy a policy, view a report that lists all of the most recently saved settings in each policy, edit a policy, or delete a policy.

Tip You can export SSL policies to, and import SSL policies from, other Defense Centers in your deployment. See Importing and Exporting Configurations for more information.

Editing an SSL Policy

Editing an SSL Policy

Generating a Report of Current Traffic Decryption Settings

Table 20-1 SSL Policy Management Actions

To...

You can...

create a new SSL policy

click New Policy. See Creating a Basic SSL Policy for more information.

modify the settings in an existing SSL policy

). See for more information.

compare SSL policies

click Compare Policies. See Comparing SSL Policies for more information.

copy an SSL policy

). See for more information on editing a copied policy.

view a PDF report that lists the current configuration settings in an SSL policy

). See for more information.

delete an SSL policy

. When prompted whether to continue, you are also informed if another user has unsaved changes in the policy.

To create an SSL policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL Policy page appears.

Step 2 Click New Policy.

The New SSL Policy pop-up window appears.

Step 3 Give the policy a unique Name and, optionally, a Description.

You can use all printable characters, including spaces and special characters.

Step 4 Specify the Default Action.

Note that you can modify your selected default action after you create your SSL policy. See Setting Default Handling and Inspection for Encrypted Traffic for more information.

Step 5 Click Save.

The SSL Policy Editor page appears. See Editing an SSL Policy for more information.

Setting Default Handling and Inspection for Encrypted Traffic

License: Any

Supported Devices: Series 3

The default action for an SSL policy determines how the system handles decryptable encrypted traffic that does not match any non-Monitor rule in the policy. When you apply an SSL policy that does not contain any SSL rules, the default action determines how all decryptable traffic on your network is handled. See Setting Default Handling for Undecryptable Traffic for more information on how the system handles undecryptable encrypted traffic.

The following table lists the default actions you can choose, as well as their effect on encrypted traffic. Note that the system does not perform any kind of inspection on encrypted traffic blocked by the default action.

:

Table 20-2 SSL Policy Default Actions

Default Action

Effect on Encrypted Traffic

Block

block the SSL session without further inspection

Block with reset

block the SSL session without further inspection and reset the TCP connection

Do not decrypt

inspect the encrypted traffic with access control

When you first create an SSL policy, logging connections that are handled by the default action is disabled by default. You can change this, as well as the default action itself, after you create the policy.

The following procedure explains how to set the default action for an SSL policy while editing the policy. See Editing an SSL Policy for the complete procedure for editing an SSL policy.

To set the default action of an SSL policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL policy page appears.

) next to the SSL policy you want to configure.

The SSL policy editor appears.

Step 3 Select a Default Action. See the SSL Policy Default Actions table for more information.

Step 4 Configure logging options for the default action as described in Logging Decryptable Connections with SSL Rules.

Step 5 Click Save.

The SSL Policy Editor page appears. See Editing an SSL Policy for more information.

Setting Default Handling for Undecryptable Traffic

License: Any

Supported Devices: Series 3

You can set undecryptable traffic actions at the SSL policy level to handle certain types of encrypted traffic the system cannot decrypt or inspect. When you apply an SSL policy that does not contain any SSL rules, the undecryptable traffic actions determine how all undecryptable encrypted traffic on your network is handled.

Depending on the type of undecryptable traffic, you can choose to:

- block the connection

- block the connection, then reset it

- inspect the encrypted traffic with access control

- inherit the default action from the SSL policy

Table 20-3 Undecryptable Traffic Types

Type

Description

Default Action

Available Actions

Compressed Session

The SSL session applies a data compression method.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

SSLv2 Session

The session is encrypted with SSL version 2.

Note that traffic is decryptable if the client hello message is SSL 2.0, and the remainder of the transmitted traffic is SSL 3.0.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

Unknown Cipher Suite

The system does not recognize the cipher suite.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

Unsupported Cipher Suite

The system does not support decryption based on the detected cipher suite.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

Session not cached

The SSL session has session reuse enabled, the client and server reestablished the session with the session identifier, and the system did not cache that session identifier.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

Handshake Errors

An error occurred during SSL handshake negotiation.

Inherit default action

Do not decrypt

Block

Block with reset

Inherit default action

Decryption Errors

An error occurred during traffic decryption.

Block

Block

Block with Reset

When you first create an SSL policy, logging connections that are handled by the default action is disabled by default. Because the logging settings for the default action also apply to undecryptable traffic handling, logging connections handled by the undecryptable traffic actions is disabled by default. For more information on configuring default logging, see Logging Decryptable Connections with SSL Rules.

Note The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed device, and the client and server establish a tunneled SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic. See Decrypt Actions: Decrypting Traffic for Further Inspection for more information.

Note that if your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate. Because you can still inspect this traffic with access control, it is not handled by the undecryptable traffic actions. If you want to allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.

To set the default handling for undecryptable traffic:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy you want to configure.

The SSL policy editor appears.

Step 3 Select the Undecryptable Actions tab.

The Undecryptable Actions tab appears.

Step 4 For each field, select the action you want to take on the type of undecryptable traffic, or if you want to apply the SSL policy’s default action. See the SSL Policy Default Actions table for more information.

Step 5 Click Save to save your changes.

You must apply the associated access control policy for your changes to take effect; see Applying an Access Control Policy.

Editing an SSL Policy

License: Any

Supported Devices: Series 3

On the SSL policy editor, you can configure your policy and organize SSL rules. To configure an SSL policy, you must give the policy a unique name and specify a default action. You can also:

- add, edit, delete, enable, and disable SSL rules

- add trusted CA certificates

- determine the handling for encrypted traffic the system cannot decrypt

- log traffic that is handled by the default action and undecryptable traffic actions

After you create or modify an SSL policy, you can associate it with an access control policy, then apply the access control policy. You can also create custom user roles that allow you to assign different permissions to different users for configuring, organizing, and applying policies.

Understanding and Creating SSL Rules

Table 20-4 SSL Policy Configuration Actions

To...

You can...

modify the policy name or description

click the name or description field, delete any characters as needed, then type the new name or description.

set the default action

find more information at Setting Default Handling and Inspection for Encrypted Traffic.

set default handling for undecryptable traffic

find more information at Setting Default Handling for Undecryptable Traffic.

log connections for the default action and undecryptable traffic actions

find more information at Logging Decryptable Connections with SSL Rules.

add trusted CA certificates

find more information at Trusting External Certificate Authorities.

assign different rights to different users

find more information at Managing Your SSL Inspection Deployment with Custom User Roles.

save your policy changes

click Save.

cancel your policy changes

click Cancel, then, if you have made changes, click OK.

add a rule to a policy

click Add Rule. See Understanding and Creating SSL Rules for more information.
.

edit an existing rule

) next to the rule. See for more information. .

delete a rule

. to delete one or more selected rules.

enable or disable an existing rule

right-click a selected rule, select State, then select Disable or Enable. Disabled rules are grayed and marked (disabled) beneath the rule name.

display the configuration page for a specific rule attribute

click the name, value, or icon in the column for the condition on the row for the rule. For example, click the name or value in the Source Networks column to display the Networks page for the selected rule. See Tuning Traffic Decryption Using SSL Rules for more information.

When you change your configuration, a message indicates that you have unsaved changes. To retain your changes, you must save the policy before exiting the policy editor. If you attempt to exit the policy editor without saving your changes, you are cautioned that you have unsaved changes; you can then discard your changes and exit the policy, or return to the policy editor.

To protect the privacy of your session, after sixty minutes of inactivity on the policy editor, changes to your policy are discarded and you are returned to the SSL Policy page. After the first thirty minutes of inactivity, a message appears and updates periodically to provide the number of minutes remaining before changes are discarded. Any activity on the page cancels the timer.

When you attempt to edit the same policy in two browser windows, you are prompted whether to resume your edit in the new window, discard your changes in the original window and continue editing in the new window, or cancel the second window and return to the policy editor.

When multiple users edit the same policy concurrently, a message on the policy editor identifies other users who have unsaved changes. Any user who attempts to save changes is cautioned that his changes will overwrite changes by other users. When the same policy is saved by multiple users, the last saved changes are retained.

To edit an SSL policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy you want to configure.

The SSL policy editor page appears.

Step 3 You have the following choices:

- To configure your policy, you can take any of the actions summarized in the SSL Policy Configuration Actions table.

- To organize rules in your policy, you can take any of the actions described in Managing SSL Rules in a Policy.

Step 4 Save or discard your configuration. You have the following choices:

- To save your changes and continue editing, click Save.

- To discard your changes, click Cancel and, if prompted, click OK .

Your changes are discarded and the SSL Policy page appears.

Applying Decryption Settings Using Access Control

License: Any

Supported Devices: Series 3

After making any changes to an SSL policy, you must apply the access control policy it is associated with. For more information, see Applying an Access Control Policy.

Caution Associating an SSL policy with an access control policy, or subsequently dissociating the policy by selecting None, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Keep the following points in mind when applying SSL policies:

- You cannot delete an SSL policy that has been applied or is currently applying.

- Applying an access control policy automatically applies the associated SSL policy. You cannot apply an SSL policy independently.

Note In a passive deployment, the system cannot influence the flow of traffic. If you attempt to apply an access control policy that references an SSL policy that blocks encrypted traffic, or that is configured to decrypt traffic by re-signing the server certificate, the system displays a warning. Also, passive deployments do not support decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve Diffie-Hellman (ECDHE) cipher suites.

To associate an SSL policy with an access control policy:

Access: Admin/Security Approver

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select the Advanced tab.

Advanced settings for the access control policy appear.

) next to General Settings.

The General Settings pop-up window appears.

Step 5 Select an SSL policy from the SSL Policy to use for inspecting encrypted connections drop-down.

Step 6 Click OK.

Advanced settings for the access control policy appear.

Step 7 Click Save to save your changes.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Generating a Report of Current Traffic Decryption Settings

License: Any

An SSL policy report is a record of the policy and rules configuration at a specific point in time. You can use the report for auditing purposes or to inspect the current configuration.

Tip You can also generate an SSL comparison report that compares a policy with the currently applied policy or with another policy. For more information, see Comparing SSL Policies.

Table 20-5 SSL Policy Report Sections

Section

Description

Title Page

Identifies the name of the policy report, the date and time the policy was last modified, and the name of the user who made that modification.

Table of Contents

Describes the contents of the report.

Policy Information

Provides the name and description of the policy, the name of the user who last modified the policy, and the date and time the policy was last modified.

Default Action

Provides the default action.

Default Logging

Provides the default connection logging settings.

Rules

Provides the rule action and conditions for each rule in the policy, by rule category.

Trusted CA Certificates

Provides the CA certificates that are automatically trusted if detected traffic is encrypted using these certificates or other certificates within the chain of trust.

Undecryptable Actions

Provides the action taken on detected types of traffic that cannot be decrypted.

Referenced Objects

Provides the name and configuration of all individual objects and group objects used in the policy, by type of condition (networks, VLAN tags, and so on) where the object is configured.

To view an SSL policy report:

Access: Admin/Access Admin/Network Admin/Security Approver

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the policy for which you want to generate a report. Remember to save any changes before you generate an SSL policy report; only saved changes appear in the report.

The system generates the report. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Comparing SSL Policies

License: Any

To review policy changes for compliance with your organization’s standards or to optimize system performance, you can examine the differences between two SSL policies. You can compare any two policies or the currently applied policy with another policy. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies.

There are two tools you can use to compare policies:

- The comparison view displays only the differences between two policies in a side-by-side format. The name of each policy appears in the title bar on the left and right sides of the comparison view except when you select Running Configuration , in which case a blank bar represents the currently active policy.

You can use this to view and navigate both policies on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two policies in a format similar to the policy report, but in PDF format.

You can use this to save, copy, print, and share your policy comparisons for further examination.

For more information on understanding and using the policy comparison tools, see:

- Using the SSL Policy Comparison View

- Using the SSL Policy Comparison Report

Using the SSL Policy Comparison View

License: Any

The comparison view displays both policies in a side-by-side format, with each policy identified by name in the title bar on the left and right sides of the comparison view. When comparing two policies other than the running configuration, the time of last modification and the last user to modify are displayed with the policy name. Differences between the two policies are highlighted:

- Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy but not the other.

Table 20-6 SSL Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a new policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the SSL Policy Comparison Report for more information.

generate a policy comparison report

click Comparison Report.

The policy comparison report creates a PDF document that lists only the differences between the two policies.

Using the SSL Policy Comparison Report

License: Any

An SSL policy comparison report is a record of all differences between two SSL policies or a policy and the currently applied policy identified by the policy comparison view, presented in PDF format. You can use this report to further examine the differences between two policy configurations and to save and disseminate your findings.

You can generate an SSL policy comparison report from the comparison view for any policies to which you have access. Remember to save any changes before you generate a policy report; only saved changes appear in the report.

The format of the policy comparison report is the same as the policy report with one exception: the policy report contains all configurations in the policy, and the policy comparison report lists only those configurations that differ between the policies. An SSL policy comparison report contains the sections described in Generating a Report of Current Traffic Decryption Settings.

Tip You can use a similar procedure to compare access control, network analysis, intrusion, file, system, or health policies.

To compare two SSL policies:

Access: Admin/Access Admin/Network Admin/Security Approver

Step 1 Select Policies > SSL.

The SSL Policy appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

The page refreshes and the Policy A and Policy B drop-down lists appear.

- To compare another policy to the currently active policy, select Running Configuration.

The page refreshes and the Target/Running Configuration A and Policy B drop-down lists appear.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing the running configuration to another policy, select the second policy from the Policy B drop-down list.

Step 5 Click OK to display the policy comparison view.

The comparison view appears.

Step 6 Optionally, click Comparison Report to generate the SSL policy comparison report.

The SSL policy comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Getting Started with SSL Rules

Within an SSL policy, SSL rules provide a granular method of handling encrypted traffic across multiple managed devices, whether blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access control, or decrypting the traffic for access control analysis.

The system matches traffic to SSL rules in the order you specify. In most cases, the system handles encrypted traffic according to the first SSL rule where all the rule’s conditions match the traffic. Conditions can be simple or complex; you can control traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate distinguished name, certificate status, cipher suite, or encryption protocol version.

Each rule also has an action, which determines whether you monitor, block, or inspect matching traffic with access control, optionally after decrypting matching traffic. Note that the system does not further inspect encrypted traffic it blocks. It does inspect encrypted and undecryptable traffic with access control. However, some access control rule conditions require unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted payloads.

The following scenario summarizes the ways that SSL rules handle traffic in an inline deployment.

In this scenario, traffic is evaluated as follows:

- Undecryptable Traffic Action evaluates encrypted traffic first. For traffic the system cannot decrypt, the system either blocks it without further inspection or passes it for access control inspection. Encrypted traffic that does not match continues to the next rule.

- SSL Rule 1: Monitor evaluates encrypted traffic next. Monitor rules track and log encrypted traffic but do not affect traffic flow. The system continues to match traffic against additional rules to determine whether to permit or deny it.

- SSL Rule 2: Do Not Decrypt evaluates encrypted traffic third. Matching traffic is not decrypted; the system inspects this traffic with access control, but not file or intrusion inspection. Traffic that does not match continues to the next rule.

- SSL Rule 3: Block evaluates encrypted traffic fourth. Matching traffic is blocked without further inspection. Traffic that does not match continues to the next rule.

- SSL Rule 4: Decrypt - Known Key evaluates encrypted traffic fifth. Matching traffic incoming to your network is decrypted using a private key you upload. The decrypted traffic is then evaluated against access control rules. Access control rules handle decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.

- SSL Rule 5: Decrypt - Resign is the final rule. If traffic matches this rule, the system re-signs the server certificate with an uploaded CA certificate, then acts as a man-in-the-middle to decrypt traffic. The decrypted traffic is then evaluated against access control rules. Access control rules treat decrypted and unencrypted traffic identically. The system can block traffic as a result of this additional inspection. All remaining traffic is reencrypted before being allowed to the destination. Traffic that does not match the SSL rule continues to the next rule.

- SSL Policy Default Action handles all traffic that does not match any of the SSL rules. The default action either blocks encrypted traffic without further inspection or does not decrypt it, passing it for access control inspection.

For more information, see the following sections:

- Configuring Supporting Inspection Information

- Understanding and Creating SSL Rules

- Managing SSL Rules in a Policy

Configuring Supporting Inspection Information

License: Any

You must create reusable public key infrastructure (PKI) objects to control encrypted traffic based on encrypted session characteristics and decrypt encrypted traffic. You can add this information on the fly when uploading trusted certificate authority (CA) certificates to the SSL policy and creating SSL rule conditions, creating the associated object in the process. However, configuring these objects ahead of time reduces the chance of improper object creation.

Decrypting Encrypted Traffic with Certificates and Paired Keys

The system can decrypt incoming encrypted traffic if you configure an internal certificate object by uploading the server certificate and private key used to encrypt the session. If you reference that object in an SSL rule with an action of Decrypt - Known Key and traffic matches that rule, the system uses the uploaded private key to decrypt the session.

The system can also decrypt outgoing traffic if you configure an internal CA object by uploading a CA certificate and private key. If you reference that object in an SSL rule with an action of Decrypt - Resign and traffic matches that rule, the system re-signs the server certificate passed to the client browser, then acts as a man-in-the-middle to decrypt the session.

See the following for more information:

- Working with Internal Certificate Objects

- Working with Internal Certificate Authority Objects

Controlling Traffic Based on Encrypted Session Characteristics

If you configure...

You can control encrypted traffic based on whether...

a cipher suite list containing one or more cipher suites

the cipher suite used to negotiate the encrypted session matches a cipher suite in the cipher suite list

a trusted CA object by uploading a CA certificate your organization trusts

the trusted CA trusts the server certificate used to encrypt the session, whether:

- the CA issued the certificate directly

- the CA issued a certificate to an intermediate CA that issued the server certificate

an external certificate object by uploading a server certificate

the server certificate used to encrypt the session matches the uploaded server certificate

a distinguished name object containing a certificate subject or issuer distinguished name

the subject or issuer common name, country, organization, or organizational unit on the certificate used to encrypt the session matches the configured distinguished name

See the following for more information:

- Working with Cipher Suite Lists

- Working with Trusted Certificate Authority Objects

- Working with External Certificate Objects

- Working with Distinguished Name Objects

Understanding and Creating SSL Rules

License: Any

Supported Devices: Series 3

Within an SSL policy, SSL rules provide a granular method of handling network traffic across multiple managed devices. In addition to its unique name, each SSL rule has the following basic components.

State

By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and stops generating warnings and errors for that rule.

Position

Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Conditions

Conditions specify the specific traffic the rule handles. Conditions can match traffic by security zone, network or geographical location, VLAN, port, application, requested URL, user, certificate, certificate subject or issuer, certificate status, cipher suite, or encryption protocol version. Conditions can be simple or complex; their use can depends on target device licenses.

Action

A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or decrypt matching traffic. Decrypted traffic is subject to further inspection. Note that the system does not perform inspection on blocked or trusted encrypted traffic.

Logging

A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record of traffic that matches a rule. You can log a connection when the system blocks an encrypted session or allows it to pass uninspected, according to the settings in an SSL policy. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. You can log connections to the Defense Center database, as well as to the system log (syslog) or to an SNMP trap server.

Tip Properly creating and ordering SSL rules is a complex task, but one that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback system for rules. For more information, see Troubleshooting SSL Rules.

To create or modify an SSL rule:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy where you want to add a rule.

The SSL policy editor appears, focused on the Rules tab.

Step 3 You have the following options:

- To add a new rule, click Add Rule .

- To edit an existing rule, click the edit icon (

) next to the rule you want to edit.

The SSL rule editor appears.

Step 4 Type a Name for the rule.

Each rule must have a unique name. You can use up to thirty printable characters, including spaces and special characters, with the exception of the colon (:).

Step 5 Configure the rule components, as summarized above. You can configure the following, or accept the defaults:

- Specify whether the rule is Enabled .

- Specify the rule position; see Specifying an SSL Rule’s Order of Evaluation.

- Select a rule Action ; see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection.

- Configure the rule’s conditions; see Using Conditions to Specify the Encrypted Traffic a Rule Handles.

- Specify Logging options; see Logging Decryptable Connections with SSL Rules.

Step 6 Click Save to save the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Specifying an SSL Rule’s Order of Evaluation

License: Any

Supported Devices: Series 3

When you first create an SSL rule, you specify its position using the Insert drop-down list in the rule editor. SSL rules in an SSL policy are numbered, starting at 1. The system matches traffic to SSL rules in top-down order by ascending rule number.

In most cases, the system handles network traffic according to the first SSL rule where all the rule’s conditions match the traffic. Except in the case of Monitor rules (which log traffic but do not affect traffic flow), the system does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule.

Tip Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs. For more information, see Ordering SSL Rules to Improve Performance and Avoid Preemption.

In addition to ordering rules by number, you can group rules by category. By default the system provides three categories: Administrator, Standard, and Root. You can add custom categories, but you cannot delete the system-provided categories or change their order. For information on changing the position or category of an existing rule, see Changing an SSL Rule’s Position or Category.

To add a rule to a category while editing or creating a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you want to use.

When you save the rule, it is placed last in that category.

To position a rule by number while editing or creating a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate rule number.

When you save the rule, it is placed where you specified.

Using Conditions to Specify the Encrypted Traffic a Rule Handles

License: feature dependent

Supported Devices: Series 3

An SSL rule’s conditions identify the type of encrypted traffic that rule handles. Conditions can be simple or complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions in a rule does the rule apply to the traffic.

If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on the server certificate used to negotiate the session, regardless of the session SSL or TLS version.

Table 21-1 SSL Rule Condition Types

This Condition...

Matches Encrypted Traffic...

Details

Zones

entering or leaving a device via an interface in a specific security zone

A security zone is a logical grouping of one or more interfaces according to your deployment and security policies. Interfaces in a zone may be located across multiple devices. To build a zone condition, see Controlling Encrypted Traffic by Network Zone.

Networks

by its source or destination IP address, country, or continent

You can explicitly specify IP addresses. The geolocation feature also allows you to control traffic based on its source or destination country or continent. To build a network condition, see Controlling Encrypted Traffic by Network or Geographical Location.

VLAN Tags

tagged by VLAN

The system uses the innermost VLAN tag to identify a packet by VLAN. To build a VLAN connection, see Controlling Encrypted VLAN Traffic.

Ports

by its source or destination port

You can control encrypted traffic based on the TCP port. To build a port condition, see Controlling Encrypted Traffic by Port.

Users

by the user involved in the session

You can control encrypted traffic based on the LDAP user logged into a host involved in an encrypted, monitored session. You can control traffic based on individual users or groups retrieved from a Microsoft Active Directory server. To build a user condition, see Controlling Encrypted Traffic Based on User.

Applications

by the application detected in a session

You can control access to individual applications in encrypted sessions, or filter access according to basic characteristics: type, risk, business relevance, and categories. To build an application condition, see Controlling Encrypted Traffic Based on Application.

Categories

by the URL requested in the session, based on the certificate subject distinguished name

You can limit the websites that users on your network can access based on the URL’s general classification and risk level. To build a URL condition, see Controlling Encrypted Traffic by URL Category and Reputation.

Caution Adding or removing a URL category and reputation condition in an SSL rule restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Distinguished Names

by the subject or issuer distinguished name of the server certificate used to negotiate the encrypted session

You can control encrypted traffic based on the CA that issued a server certificate, or the server certificate holder. To build a distinguished name condition, see Controlling Encrypted Traffic by Certificate Distinguished Name.

Certificates

by the server certificate used to negotiate the encrypted session

You can control encrypted traffic based on the server certificate passed to the user’s browser in order to negotiate the encrypted session. To build a certificate condition, see Controlling Encrypted Traffic by Certificate Status.

Certificate Status

by properties of the server certificate used to negotiate the encrypted session

You can control encrypted traffic based on a server certificate’s status. To build a certificate status condition, see Controlling Encrypted Traffic by Certificate Status.

Cipher Suites

by the cipher suite used to negotiate the encrypted session

You can control encrypted traffic based on the cipher suite selected by the server to negotiate the encrypted session. To build a cipher suite condition, see Controlling Encrypted Traffic by Cipher Suite.

Versions

by the version of SSL or TLS used to encrypt the session

You can control encrypted traffic based on the version of SSL or TLS used to encrypt the session. To build a version condition, see Controlling Traffic by Encryption Protocol Version.

Note that while you can control and inspect encrypted traffic with a Series 3 device, controlling traffic using detected application, URL category, or user requires additional licenses. Also, overly complex rules can consume excessive resources and in some cases prevent you from applying the policy. For more information, see Troubleshooting SSL Rules.

Using Rule Actions to Determine Encrypted Traffic Handling and Inspection

License: Any

Supported Devices: Series 3

Every SSL rule has an associated action that determines the following for matching encrypted traffic:

- handling — foremost, the rule action governs whether the system will monitor, trust, block, or decrypt encrypted traffic that matches the rule’s conditions

- logging — the rule action determines when and how you can log details about matching encrypted traffic.

Your SSL inspection configuration handles, inspects, and logs decrypted traffic:

- The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt; see Setting Default Handling for Undecryptable Traffic.

- The policy’s default action handles traffic that does not meet the condition of any non-Monitor SSL rule; see Setting Default Handling and Inspection for Encrypted Traffic.

You can log a connection event when the system blocks or trusts an encrypted session. You can also force the system to log connections that it decrypts for further evaluation by access control rules, regardless of how the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events, however:

- for blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event

- for trusted connections (Do not decrypt), the system generates an event when the session ends

For detailed information on rule actions and how they affect handling and logging, see the following sections:

- Monitor Action: Postponing Action and Ensuring Logging

- Do Not Decrypt Action: Passing Encrypted Traffic Without Inspection

- Blocking Actions: Blocking Encrypted Traffic Without Inspection

- Decrypt Actions: Decrypting Traffic for Further Inspection

- Managing SSL Rules in a Policy

Monitor Action: Postponing Action and Ensuring Logging

License: Any

Supported Devices: Series 3

The Monitor action does not affect encrypted traffic flow; matching traffic is neither immediately permitted nor denied. Rather, traffic is matched against additional rules, if present, to determine whether to trust, block, or decrypt it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching rules, the system uses the default action.

Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of connection events for monitored traffic. That is, the system always logs the end of the connection to the Defense Center database, regardless of the logging configuration of the rule or default action that later handles the connection. In other words, if a packet matches a Monitor rule, the connection is always logged, even if the packet matches no other rules and you do not enable logging on the default action.

Do Not Decrypt Action: Passing Encrypted Traffic Without Inspection

License: Any

Supported Devices: Series 3

The Do not decrypt action passes encrypted traffic for evaluation by the access control policy’s rules and default action. Because some access control rule conditions require unencrypted traffic, this traffic may match fewer rules. The system cannot perform deep inspection on encrypted traffic, such as intrusion or file inspection.

Blocking Actions: Blocking Encrypted Traffic Without Inspection

License: Any

Supported Devices: Series 3

The Block and Block with reset actions are analogous to the access control rule actions Block and Block with reset. These actions prevent the client and server from establishing the SSL-encrypted session and passing encrypted traffic. Block with reset rules also reset the connection.

Note that the system does not display the configured response page for blocked encrypted traffic. Instead, users requesting prohibited URLs have their connection either reset or time out. See Displaying a Custom Web Page for Blocked URLs for more information.

Decrypt Actions: Decrypting Traffic for Further Inspection

License: Any

Supported Devices: Series 3

The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The system inspects decrypted traffic with access control. Access control rules handle decrypted and unencrypted traffic identically — you can inspect it for discovery data as well as detect and block intrusions, prohibited files, and malware. The system reencrypts allowed traffic before passing it to its destination.

When you configure the Decrypt - Known Key action, you can associate one or more server certificates and paired private keys with the action. If traffic matches the rule, and the certificate used to encrypt the traffic matches the certificate associated with the action, the system uses the appropriate private key to obtain the session encryption and decryption keys. Because you must have access to the private key, this action is best suited to decrypt traffic incoming to servers your organization controls.

Similarly, you can associate one Certificate Authority certificate and private key with the Decrypt - Resign action. If traffic matches this rule, the system re-signs the server certificate with the CA certificate, then acts as a man-in-the-middle. It creates two SSL sessions, one between client and managed device, one between managed device and server. Each session contains different cryptographic session details, and allows the system to decrypt and reencrypt traffic. This action is more suited for outgoing traffic, as you replace the certificate’s private key with one you control to obtain the session keys.

Re-signing a server certificate involves either replacing the certificate’s public key with a CA certificate public key, or replacing the entire certificate. Normally, if you replace an entire server certificate, the client browser warns the certificate is not signed by a trusted authority when establishing the SSL connection. However, if your client’s browser trusts the CA in the policy, the browser does not warn that the certificate is not trusted. If the original server certificate is self-signed, the system replaces the entire certificate, and trusts the re-signing CA, but the user’s browser does not warn that the certificate is self-signed. In this case, replacing only the server certificate public key causes the client browser does warn that the certficate is self-signed.

If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you associate one CA certificate with a Decrypt - Resign action, you cannot create an SSL rule that decrypts multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption algorithm type.

For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign rule only if the action references an EC-based CA certificate; you must add EC-based external certificates and cipher suites to the rule if you want to create certificate and cipher suite rule conditions. Similarly, a Decrypt - Resign rule that references an RSA-based CA certificate matches only outgoing traffic encrypted with an RSA algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all other configured rule conditions match.

Note the following:

- You cannot use the Decrypt - Known Key action in a passive deployment if the cipher suite used to establish the SSL connection applies either the Diffie-Hellman ephemeral (DHE) or the elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchange algorithm. If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a Decrypt - Known Key rule with a cipher suite condition containing either a DHE or an ECDHE cipher suite, the system displays an information icon (

) next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the system displays a warning icon ( ).

- You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment, as the device does not directly inspect traffic. If you create a rule with the Decrypt - Resign action that contains passive or inline (tap mode) interfaces within a security zone, the policy editor displays a warning icon (

) next to the rule. If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a Decrypt - Resign rule, the system displays an information icon ( ) next to the rule. If you later add a zone condition to the SSL rule that contains passive or inline (tap mode) interfaces, the system displays a warning icon ( ). If you apply an SSL policy that contains a Decrypt - Resign rule to a device with passive or inline (tap mode) interfaces, any SSL sessions that match the rule fail.

- If the client does not trust the CA used to re-sign the server certificate, it warns the user that the certificate should not be trusted. To prevent this, import the CA certificate into the client trusted CA store. Alternatively, if your organization has a private PKI, you can issue an intermediate CA certificate signed by the root CA which is automatically trusted by all clients in the organization, then upload that CA certificate to the device.

- The system cannot decrypt traffic encrypted with an anonymous cipher suite. You cannot use either the Decrypt - Resign or Decrypt - Known Key action in an SSL rule if you add an anonymous cipher suite to the Cipher Suite condition.

- The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed device, and the client and server establish a tunneled SSL connection using the CONNECT HTTP method. The Handshake Errors undecryptable action determines how the system handles this traffic. See Setting Default Handling for Undecryptable Traffic for more information.

- You cannot match on Distinguished Name or Certificate conditions when creating an SSL rule with a Decrypt - Known Key action. The assumption is that if this rule matches traffic, the certificate, subject DN, and issuer DN already match the certificate associated with the rule. For more information, see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection.

- If you create an internal CA object and choose to generate a certificate signing request (CSR), you cannot use this CA for a Decrypt - Resign action until you upload the signed certificate to the object. For more information, see Obtaining and Uploading a New Signed Certificate.

- If you configure a rule with the Decrypt - Resign action, and mismatch signature algorithm type for one or more external certificate objects or cipher suites, the policy editor displays an information icon (

) next to the rule. If you mismatch signature algorithm type for all external certificate objects, or all cipher suites, the policy displays a warning icon ( ) next to the rule, and you cannot apply the access control policy associated with the SSL policy. For more information, see Controlling Encrypted Traffic by Certificate and Controlling Encrypted Traffic by Cipher Suite.

- If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive Block with reset , the system blocks the matching connection without interaction and the system does not display a response page.

- If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the preprocessor normalizes decrypted traffic, it may drop a packet and replace it with a trimmed packet. This does not end the SSL session. If the traffic is allowed, the trimmed packet is encrypted as part of the SSL session. For more information on this option, see Normalizing Inline Traffic.

- If your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic by re-signing the server certificate. If you want to allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name.

Managing SSL Rules in a Policy

License: Any

Supported Devices: Series 3

The Rules tab of the SSL policy editor, shown in the following graphic, allows you to add, edit, search, move, enable, disable, delete, and otherwise manage SSL rules within your policy.

For each rule, the policy editor displays its name, a summary of its conditions, and the rule action. Icons represent warnings, errors, and other important information. Disabled rules are grayed out and marked (disabled) beneath the rule name. See Troubleshooting SSL Rules for more information about the icons.

For information on managing SSL rules, see:

- Searching SSL Rules

- Enabling and Disabling SSL Rules

- Changing an SSL Rule’s Position or Category

Searching SSL Rules

License: Any

Supported Devices: Series 3

You can search the list of SSL rules for matching values using an alphanumeric string, including spaces and printable, special characters. The search inspects the rule name and any rule condition you have added to the rule. For rule conditions, the search matches any name or value you can add for each condition type (zone, network, application, and so on). This includes individual object names or values, group object names, individual object names or values within a group, and literal values.

You can use complete or partial search strings. The column for matching values is highlighted for each matching rule. For example, if you search on all or part of the string 100Bao, at a minimum, the Applications column is highlighted for each rule where you have added the 100Bao application. If you also have a rule named 100Bao, both the Name and Applications columns are highlighted.

You can navigate to each previous or next matching rule. A status message displays the current match and the total number of matches.

Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the page where the first match occurs is displayed. Selecting the next match when you are at the last match takes you to the first match, and selecting the previous match when you are at the first match takes you to the last match.

To search for rules:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy editor for the policy you want to search, click the Search Rules prompt, type a search string, then press Enter. You can also use the Tab key or click a blank page area to initiate the search.

Columns for rules with matching values are highlighted, with differentiated highlighting for the indicated (first) match.

Step 2 Find the rules you are interested in:

- To navigate between matching rules, click the next-match (

) or previous-match ( ) icon.

- To refresh the page and clear the search string and any highlighting, click the clear icon (

).

Enabling and Disabling SSL Rules

License: Any

Supported Devices: Series 3

When you create an SSL rule, it is enabled by default. If you disable a rule, the system does not use it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules in an SSL policy, disabled rules are grayed out, although you can still modify them. Note that you can also enable or disable an SSL rule using the rule editor; see Understanding and Creating SSL Rules.

To change an SSL rule’s state:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy editor for the policy that contains the rule you want to enable or disable, right-click the rule and choose a rule state:

- To enable an inactive rule, select State > Enable .

- To disable an active rule , State > Disable .

Step 2 Click Save to save the policy.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Changing an SSL Rule’s Position or Category

License: Any

Supported Devices: Series 3

To help you organize SSL rules, every SSL policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories.

By default, any predefined user role that allows you to modify SSL policies also allows you to move and modify SSL rules within and among rules categories. You can, however, create custom roles that restrict users from moving and modifying rules.

For more information, see:

- Moving an SSL Rule

- Adding a New SSL Rule Category

Moving an SSL Rule

License: Any

Supported Devices: Series 3

Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. By default, any predefined user role that allows you to modify SSL policies also allows you to move SSL rules within and among rules categories. You can, however, create custom roles that restrict users from moving rules in the system-provided categories.

The following procedure explains how to move one or more rules at a time using the SSL policy editor. You can also move individual SSL rules using the rule editor; see Understanding and Creating SSL Rules.

To move a rule:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy editor for the policy that contains the rules you want to move, select the rules by clicking in a blank area for each rule. Use the Ctrl and Shift keys to select multiple rules.

The rules you selected are highlighted.

Step 2 Move the rules. You can cut and paste or drag and drop.

To cut and paste rules into a new location, right-click a selected rule and select Cut. Then, right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or Paste below. Note that you cannot copy and paste SSL rules between two different SSL policies.

Step 3 Click Save to save the policy.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Adding a New SSL Rule Category

License: Any

Supported Devices: Series 3

To help you organize SSL rules, every SSL policy has three system-provided rule categories: Administrator Rules, Standard Rules, and Root Rules. You cannot move, delete, or rename these categories, although you can create custom categories between the Standard Rules and Root Rules.

Adding custom categories allows you to further organize your rules without having to create additional policies. You can rename and delete categories that you add. You cannot move these categories, but you can move rules into, within, and out of them.

You can create custom roles that restrict users from moving and modifying rules in the system-provided categories, based on the user permissions added to the role. For more information, see User Account Privileges.

To add a new category:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy editor for the policy where you want to add a rule category, click Add Category.

Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to set the position of the new category before you add it. You can also right-click an existing rule and select Insert new category.

The Add Category pop-up window appears.

Step 2 Type a unique category Name.

You can enter an alphanumeric name, including spaces and special printable characters, with up to 30 characters.

Step 3 You have the following choices:

- To position the new category immediately above an existing category, select above Category from the first Insert drop-down list, then select the category above which you want to position the rule from the second drop-down list.

- To position the new category rule below an existing rule, select below rule from the drop-down list, then enter an existing rule number. This option is valid only when at least one rule exists in the policy.

- To position the rule above an existing rule, select above rule from the drop-down list, then, enter an existing rule number. This option is valid only when at least one rule exists in the policy.

Step 4 Click OK.

) to delete the category. Rules in a category you delete are added to the category above.

Step 5 Click Save to save the policy.

Troubleshooting SSL Rules

License: Any

Supported Devices: Series 3

Properly creating and ordering SSL rules is a complex task, but one that is essential to building an effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the SSL policy interface has a robust warning and error feedback system for rules.

For each rule, icons in the policy editor mark warnings and errors, as described in the following table. Hover your pointer over the icon to read the warning, error, or informational text.

Table 21-2 SSL Error Icons

Icon

Description

Details

warning

Depending on the issue, you may be able to apply an SSL policy that displays rule or other warnings. In these cases, the misconfigured settings will have no effect. For example, a preempted rule never evaluates traffic. However, if a warning icon marks a licensing error or model mismatch, you cannot apply the policy until you correct the issue.

If you disable a rule with a warning, the warning icon disappears. It reappears if you enable the rule without correcting the underlying issue.

error

If a rule or other SSL policy configuration has an error, you cannot apply the policy until you correct the issue.

information

Information icons convey helpful information about configurations that may affect the flow of traffic. These issues are minor and will not prevent you from applying the policy.

Properly configuring SSL rules can also reduce the resources required to process network traffic. Creating complex rules and mis-ordering rules can affect performance.

For more information, see:

- Understanding SSL Rule Warnings and Errors

- Understanding Rule Preemption and Invalid Configuration Warnings

- Ordering SSL Rules to Improve Performance and Avoid Preemption

Understanding SSL Rule Warnings and Errors

License: feature dependent

Supported Devices: Series 3

Although you can create SSL rules with any license, certain rule conditions and inspection options require that you enable specific licensed capabilities on the targeted device. You cannot apply a policy that uses licensed capabilities to unlicensed devices. The system uses warning icons and confirmation dialogs to designate unlicensed features. For details, hover your pointer over a warning icon.

The following table explains the licenses you must have to use SSL rules.

Table 21-3 License Requirements for SSL Rules

To use rules...

License

Supported Defense Centers

Supported Devices

with zone, network, VLAN, port, certificate, DN, certificate status, cipher suite, or version conditions

Any

Any

Series 3

with network conditions that use geolocation data

FireSIGHT

Any except DC500

Series 3

with application or user conditions

Control

Any, except the DC500 cannot perform user control

Series 3

with category conditions that use URL category and reputation data

URL Filtering

Any except DC500

Series 3

Understanding Rule Preemption and Invalid Configuration Warnings

License: Any

Supported Devices: Series 3

Properly configuring and ordering SSL rules is essential to building an effective deployment. Within an SSL policy, SSL rules can preempt other rules or contain invalid configurations. The system uses warning and error icons to mark these issues.

Understanding Rule Preemption Warnings

The conditions of an SSL rule may preempt a subsequent rule from matching traffic. For example:

Rule 1: do not decrypt Administrators

Rule 2: block Administrators

The second rule above will never block traffic because the first rule will have already allowed the traffic.

Any type of rule condition can preempt a subsequent rule. For example, the VLAN range in the first rule below includes the VLAN in the second rule, so the first rule preempts the second rule:

Rule 1: do not decrypt VLAN 22-33

Rule 2: block VLAN 27

In the following example, Rule 1 matches any VLAN because no VLANs are configured, so Rule 1 preempts Rule 2, which attempts to match VLAN 2:

Rule 1: do not decrypt Source Network 10.4.0.2/16

Rule 2: do not decrypt Source Network 10.4.0.2/16, VLAN 2

A rule also preempts an identical subsequent rule where all configured conditions are the same. For example:

Rule 1: do not decrypt VLAN 1 URL www.example.com

Rule 2: do not decrypt VLAN 1 URL www.example.com

A subsequent rule would not be preempted if any condition is different. For example:

Rule 1: do not decrypt VLAN 1 URL www.example.com

Rule 2: do not decrypt VLAN 2 URL www.example.com

Understanding Invalid Configuration Warnings

Because outside settings that the SSL policy depends on may change, an SSL policy setting that was valid may become invalid. Consider the following examples:

- A rule that contains a URL category condition might be valid until you target a device that does not have a URL Filtering license. At that point, an error icon appears next to the rule, and you cannot apply the policy to that device until you edit or delete the rule, retarget the policy, or enable the appropriate license.

- If you create a Decrypt-Resign rule, and later add a security zone with passive interfaces to a zone condition, the system displays a warning icon next to the rule. Because you cannot decrypt traffic by re-signing a certificate in a passive deployment, the rule has no effect until you remove the passive interfaces from the rule or change the rule action.

- If you add a user to a rule, then change your LDAP user awareness settings to exclude that user, the rule will have no effect because the user is no longer an access-controlled user.

Ordering SSL Rules to Improve Performance and Avoid Preemption

License: Any

Supported Devices: Series 3

Rules in an SSL policy are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that traffic.

Proper SSL rule order reduces the resources required to process network traffic, and prevents rule preemption. Although the rules you create are unique to every organization and deployment, there are a few general guidelines to follow when ordering rules that can optimize performance while still addressing your needs.

Order Rules from Most to Least Critical

First, you must order rules to suit your organization's needs. Place priority rules that must apply to all traffic near the top of the policy. For example, if you want to decrypt outgoing traffic from a single user for further analysis (using a Decrypt-Resign rule), but not decrypt traffic from all other users in the department (using a Do not decrypt rule), place two SSL rules in that order.

Order Rules from Specific to General

You can improve performance by placing specific rules earlier, that is, rules that narrowly define the traffic they handle. This is also important because rules with broad conditions can match many different types of traffic, and can preempt later, more specific rules.

Consider a scenario where a trusted CA (Good CA) mistakenly issued a CA certificate to a malicious entity (Bad CA), but has not yet revoked that certificate. You want to block traffic encrypted with certificates issued by the untrusted CA, but otherwise allow traffic within the trusted CA’s chain of trust. You should upload the CA certificates and all intermediate CA certificates, then order your rules as follows:

Rule 1: Block issuer CN=www.badca.com

Rule 2: Do not decrypt issuer CN=www.goodca.com

If you reverse the rules:

Rule 1: Do not decrypt issuer CN=www.goodca.com

Rule 2: Block issuer CN=www.badca.com

the first rule matches all traffic trusted by Good CA, including traffic trusted by Bad CA. Because no traffic ever matches the second rule, malicious traffic may be allowed instead of blocked.

Order Rules to Allow Traffic from Certificate Pinned Sites

Certificate pinning forces a client's browser to verify that a server's public key certificate matches a certificate the browser already associated with the server before establishing an SSL session. Because the Decrypt - Resign action involves modifying a server certificate before passing it to the client, these modified certificates are rejected if the browser already pinned that certificate.

For example, if a client browser connects to windowsupdate.microsoft.com, a site that uses certificate pinning, and you configure an SSL rule that matches that traffic with a Decrypt - Resign action, the system re-signs the server certificate before passing it to the client browser. Because this modified server certificate does not match the browser's pinned certificate for windowsupdate.microsoft.com, the client browser rejects the connection.

If you want to allow this traffic, configure an SSL rule with the Do not decrypt action to match the server certificate common name or distinguished name. In the SSL policy, order this rule before all Decrypt - Resign rules that also match the traffic. You can retrieve the pinned certificate from the client's browser after a successful connection to the website. You can also view the certificate from the logged connection event, whether the connection succeeded or failed.

Place Rules that Decrypt Traffic Later

Because traffic decryption requires processing resources, placing rules that do not decrypt traffic (Do not decrypt, Block) before rules that do (Decrypt-Known Key, Decrypt-Resign) can improve performance. This is because traffic decryption can command significant resources. In addition, Block rules can divert traffic that the system might otherwise have decrypted or inspected. All other factors being equal, that is, given a set of rules where none is more critical and preemption is not an issue, consider placing them in the following order:

- Monitor rules that log matching connections, but take no other action on traffic

- Block rules that block traffic without further inspection

- Do not decrypt rules that do not decrypt encrypted traffic

- Decrypt-Known Key rules that decrypt incoming traffic with a known private key

- Decrypt-Resign rules that decrypt outgoing traffic by re-signing the server certificate

Configuring SSL Inspection to Improve Performance

License: Any

Supported Devices: Series 3

Complex SSL policies and rules can command significant resources. When you apply an SSL policy, the system evaluates all the rules together and creates an expanded set of criteria that target devices use to evaluate network traffic. A pop-up window may warn that you have exceeded the maximum number of SSL rules supported by a target device. This maximum depends on a number of factors, including the physical memory and the number of processors on the device.

Simplifying Rules

The following guidelines can help you simplify your SSL rules and improve performance:

- When constructing a rule, use as few individual elements in your conditions as possible. For example, in network conditions, use IP address blocks rather than individual IP addresses. In port conditions, use port ranges. Use application filters and URL categories and reputations to perform application control and URL filtering, and LDAP user groups to perform user control.

Note that combining elements into objects that you then use in SSL rule conditions does not improve performance. For example, using a network object that contains 50 individual IP addresses gives you only an organizational—not a performance—benefit over including those IP addresses in the condition individually.

- Restrict rules by security zones whenever possible. If a device’s interfaces are not in one of the zones in a zone-restricted rule, the rule does not affect performance on that device.

- Do not overconfigure rules. If one condition is enough to match the traffic you want to handle, do not use two.

Configuring Traffic Decryption

Tuning Traffic Decryption Using SSL Rules

A basic SSL rule applies its rule action to all encrypted traffic inspected by the device. To better control and decrypt encrypted traffic, you can configure rule conditions to handle and log specific types of traffic. Each SSL rule can contain 0, 1, or more rule conditions; a rule only matches traffic if the traffic matches every condition in that SSL rule.

Note When traffic matches a rule, the device applies the configure rule action to the traffic. When the connection ends, the device logs the traffic if configured to do so. For more information, see Using Rule Actions to Determine Encrypted Traffic Handling and Inspection and Logging Encrypted Connections.

Each rule condition allows you to specify one or more properties of traffic you want to match against; these properties include details of:

- the flow of traffic, including the security zone through which it travels, IP address and port, country of origin or destination, and origin or destination VLAN

- the user associated with a detected IP address

- the traffic payload, including the application detected in the traffic

- the connection encryption, including the SSL/TLS protocol version and cipher suite and server certificate used to encrypt the connection

- the category and reputation of the URL specified in the server certificate’s distinguished name

For more information, see the following sections:

- Logging Decryptable Connections with SSL Rules

- Controlling Encrypted Traffic with Network-Based Conditions

- Controlling Encrypted Traffic by Reputation

- Controlling Traffic Based on Encryption Properties

Controlling Encrypted Traffic with Network-Based Conditions

License: Any

Supported Devices: Series 3

SSL rules within SSL policies exert granular control over encrypted traffic logging and handling. Network-based conditions allow you to manage which encrypted traffic can traverse your network, using one or more of the following criteria:

- source and destination security zones

- source and destination IP addresses or geographical locations

- a packet’s innermost VLAN tag

- source and destination port

You can combine network-based conditions with each other and with other types of conditions to create an SSL rule. These SSL rules can be simple or complex, matching and inspecting traffic using multiple conditions. For detailed information on SSL rules, see Getting Started with SSL Rules.

For more information, see the following sections:

- Controlling Encrypted Traffic by Network Zone

- Controlling Encrypted Traffic by Network or Geographical Location

- Controlling Encrypted VLAN Traffic

- Controlling Encrypted Traffic by Port

Controlling Encrypted Traffic by Network Zone

License: Any

Supported Devices: Series 3

Zone conditions in SSL rules allow you to control encrypted traffic by its source and destination security zones.

A security zone is a grouping of one or more interfaces, which may be located across multiple devices. An option you choose during a device’s initial setup, called its detection mode, determines how the system initially configures the device’s interfaces, and whether those interfaces belong to a security zone.

As a simple example, when you register a device with an Inline detection mode, the Defense Center creates two zones: Internal and External, and assigns the first pair of interfaces on the device to those zones. Hosts connected to the network on the Internal side represent your protected assets.

To extend this scenario, you could deploy additional identically configured devices—managed by the same Defense Center—to protect similar resources in several different locations. Like the first device, each of these devices protects the assets in its Internal security zone.

Tip You are not required to group all internal (or external) interfaces into a single zone. Choose the grouping that makes sense for your deployment and security policies. For more information on creating zones, see Working with Security Zones.

In this deployment, you may decide that although you want these hosts to have unrestricted access to the Internet, you nevertheless want to protect them by decrypting and inspecting incoming encrypted traffic.

To accomplish this with SSL inspection, configure an SSL rule with a zone condition where the Destination Zone is set to Internal. This simple SSL rule matches traffic that leaves the device from any interface in the Internal zone.

If you want to build a more complex rule, you can add a maximum of 50 zones to each of the Sources Zones and Destination Zones in a single zone condition:

- To match encrypted traffic leaving the device from an interface in the zone, add that zone to the Destination Zones .

Because devices deployed passively do not transmit traffic, you cannot use a zone comprised of passive interfaces in a Destination Zone condition.

- To match encrypted traffic entering the device from an interface in the zone, add that zone to the Source Zones .

If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.

Note that just as all interfaces in a zone must be of the same type (all inline, all passive, all switched, or all routed), all zones used in a zone condition for an SSL rule must be of the same type. That is, you cannot write a single rule that matches encrypted traffic to or from zones of different types.

Warning icons indicate invalid configurations, such as zones that contain no interfaces. For details, hover your pointer over the icon.

To control encrypted traffic by zone:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by zone, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Zones tab.

The Zones tab appears.

Step 3 Find and select the zones you want to add from the Available Zones.

To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone name. The list updates as you type to display matching zones.

Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.

You can also drag and drop selected zones.

Step 5 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Network or Geographical Location

License: Any

Supported Devices: Series 3

Network conditions in SSL rules allow you to control and decrypt encrypted traffic by its source and destination IP address. You can either:

- explicitly specify the source and destination IP addresses for the encrypted traffic you want to control, or

- use the geolocation feature, which associates IP addresses with geographical locations, to control encrypted traffic based on its source or destination country or continent

When you build a network-based SSL rule condition, you can manually specify IP address and geographical locations. Alternately, you can configure network conditions with network and geolocation objects, which are reusable and associate a name with one or more IP addresses, address blocks, countries, continents, and so on.

Tip After you create a network or geolocation object, you can use it not only to build SSL rules, but also to represent IP addresses in various other places in the system’s web interface. You can create these objects using the object manager; you can also create network objects on-the-fly while you are configuring SSL rules. For more information, see Managing Reusable Objects.

Note that if you want to write rules to control traffic by geographical location, to ensure you are using up-to-date geolocation data to filter your traffic, Cisco strongly recommends you regularly update the geolocation database (GeoDB) on your Defense Center; see Updating the Geolocation Database.

The following graphic shows the network condition for an SSL rule that blocks encrypted connections originating from your internal network and attempting to access resources either in the Cayman Islands or an offshore holding corporation server at 182.16.0.3.

The example manually specifies the offshore holding corporation’s server IP address, and uses a system-provided Cayman Islands geolocation object to represent Cayman Island IP addresses.

You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single network condition, and you can mix network and geolocation-based configurations:

- To match encrypted traffic from an IP address or geographical location, configure the Source Networks .

- To match encrypted traffic to an IP address or geographical location, configure the Destination Networks .

If you add both source and destination network conditions to a rule, matching encrypted traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.

When building a network condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon.

To control traffic by network or geographical location:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by network, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Networks tab.

The Networks tab appears.

Step 3 Find and select the networks you want to add from the Available Networks, as follows:

- Click the Networks tab to display network objects and groups to add; click the Geolocation tab to display geolocation objects.

- To add a network object on the fly, which you can then add to the condition, click the add icon (

) above the Available Networks list; see Working with Network Objects.

- To search for network or geolocation objects to add, select the appropriate tab, click the Search by name or value prompt above the Available Networks list, then type an object name or the value of one of the object’s components. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.

You can also drag and drop selected objects.

Step 5 Add any source or destination IP addresses or address blocks that you want to specify manually.

Click the Enter an IP address prompt below the Source Networks or Destination Networks list; then type an IP address or address block and click Add.

Step 6 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted VLAN Traffic

License: Any

Supported Devices: Series 3

VLAN conditions in SSL rules allow you to control VLAN-tagged traffic. The system uses the innermost VLAN tag to identify a packet by VLAN.

When you build a VLAN-based SSL rule condition, you can manually specify a VLAN tag from 1 to 4094. Alternately, you can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one or more VLAN tags.

Tip After you create a VLAN tag object, you can use it not only to build SSL rules, but also to represent VLAN tags in various other places in the system’s web interface. You can create VLAN tag objects either using the object manager or on-the-fly while you are configuring access control rules. For more information, see Working with VLAN Tag Objects.

You can add a maximum of 50 items to the Selected VLAN Tags in a single VLAN tag condition. When building a VLAN tag condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon.

To control traffic by VLAN tag:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control traffic by VLAN tag, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the VLAN Tags tab.

The VLAN Tags tab appears.

Step 3 Find and select the VLANs you want to add from the Available VLAN Tags, as follows:

- To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon (

) above the Available VLAN Tags list; see Working with VLAN Tag Objects.

- To search for VLAN tag objects and groups to add, click the Search by name or value prompt above the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule or to add the selected objects to the Selected VLAN Tags list.

You can also drag and drop selected objects.

Step 5 Add any VLAN tags that you want to specify manually.

Click the Enter a VLAN Tag prompt below the Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag from 1 to 4094; use a hyphen to specify a range of VLAN tags.

Step 6 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Port

License: Any

Supported Devices: Series 3

Port conditions in SSL rules allow you to control encrypted traffic by its source and destination TCP port. When you build a port-based SSL rule condition, you can manually specify TCP ports. Alternately, you can configure port conditions with port objects, which are reusable and associate a name with one or more ports.

Tip After you create a port object, you can use it not only to build SSL rules, but also to represent ports in various other places in the system’s web interface. You can create port objects either using the object manager or on-the-fly while you are configuring SSL rules. For more information, see Working with Port Objects.

You can add a maximum of 50 items to each of the Selected Source Ports and Selected Destination Ports lists in a single network condition:

- To match encrypted traffic from a TCP port, configure the Selected Source Ports .

- To match encrypted traffic to a TCP port, configure the Selected Destination Ports .

- To match encrypted traffic both originating from TCP Selected Source Ports and destined for TCP Selected Destination Ports , configure both.

You can only configure the Selected Source Ports and Selected Destination Ports lists with TCP ports. Port objects containing non-TCP ports are greyed out in the Available Ports list.

When building a port condition, warning icons indicate invalid configurations. For example, you can use the object manager to edit in-use port objects so that the rules that use those object groups become invalid. For details, hover your pointer over the icon.

To control traffic by port:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by TCP port, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Ports tab.

The Ports tab appears.

Step 3 Find and select the TCP ports you want to add from the Available Ports, as follows:

- To add a TCP port object on the fly, which you can then add to the condition, click the add icon (

) above the Available Ports list; see Working with Port Objects.

- To search for TCP-based port objects and groups to add, click the Search by name or value prompt above the Available Ports list, then type either the name of the object, or the value of a port in the object. The list updates as you type to display matching objects. For example, if you type 443, the Defense Center displays the system-provided HTTPS port object.

To select a TCP-based port object, click it. To select multiple TCP-based port objects, use the Shift and Ctrl keys, or right-click and then select Select All. If the object includes non-TCP-based ports, you cannot add it to your port condition.

Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.

You can also drag and drop selected objects.

Step 5 Enter a Port under the Selected Source Ports or Selected Destination Ports list to manually specify source or destination ports. You can specify a single port with a value from 0 to 65535.

Step 6 Click Add.

Note that the Defense Center will not add a port to a rule condition that results in an invalid configuration.

Step 7 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic Based on User

License: Control

Supported Devices: Series 3

You can configure SSL rules to match traffic for users retrieved from a Microsoft Active Directory Server. User conditions in SSL rules allow you perform user control—to manage which traffic can traverse your network, by limiting traffic based on the LDAP user logged into a host.

User control works by associating access controlled users with IP addresses. Deployed agents monitor specified users as they log in and out of hosts or authenticate with Active Directory credentials for other reasons. For example, your organization may use services or applications that rely on Active Directory for centralized authentication.

For traffic to match an SSL rule with a user condition, the IP address of either the source or destination host in the monitored session must be associated with a logged in access controlled user. You can control traffic based on individual users or the groups those users belong to.

You can combine user conditions with each other and with other types of conditions to create an SSL rule. These SSL rules can be simple or complex, matching and inspecting traffic using multiple conditions. For detailed information on SSL rules, see Understanding and Creating SSL Rules.

User control requires a Control license and is supported only for LDAP users and groups (access controlled users), using login and logoff records reported by a User Agent monitoring Microsoft Active Directory servers.

Before you can write SSL rules with user conditions, you must configure a connection between the Defense Center and at least one of your organization’s Microsoft Active Directory servers. This configuration, called an authentication object, contains connection settings and authentication filter settings for the server. It also specifies the users you can use in user conditions. For more information, see Retrieving Access-Controlled Users and LDAP User Metadata.

In addition, you must install User Agents. The agents monitor users when they authenticate against Active Directory credentials, and send records of those logins to the Defense Center. These records associate users with IP addresses, which is what allows SSL rules with user conditions to trigger. For more information, see Using User Agents to Report Active Directory Logins.

To control encrypted traffic by user:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by user, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Users tab.

The Users tab appears.

Step 3 To search for users to add, click the Search by name or value prompt above the Available Users list, then type the username. The list updates as you type to display matching users.

To select a user, click it. To select multiple users, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule or to add the selected users to the Selected Users list.

You can also drag and drop selected users.

Step 5 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Reputation

License: Control or URL Filtering

Supported Devices: Series 3

Reputation-based conditions in SSL rules allow you to manage which encrypted traffic can traverse your network, by contextualizing your network traffic and limiting it where appropriate. SSL rules govern the following types of reputation-based control:

- Application conditions allow you to perform application control , which controls application traffic based on not only individual applications, but also applications’ basic characteristics: type, risk, business relevance, and categories.

- URL conditions allow you to control web traffic based on a websites’ assigned category and reputation.

You can combine reputation-based conditions with each other and with other types of conditions to create an SSL rule. These SSL rules can be simple or complex, matching and inspecting traffic using multiple conditions.

Table 22-1 License and Appliance Requirements for Reputation-Based SSL Rules

Requirement

Application Control

URL Filtering (cat. & rep.)

license

Control

URL Filtering

devices

Series 3

Series 3

Defense Centers

Series 3, virtual

Series 3, virtual

For more information, see the following sections:

- Controlling Encrypted Traffic Based on Application

- Controlling Encrypted Traffic by URL Category and Reputation

Controlling Encrypted Traffic Based on Application

License: Control

Supported Devices: Series 3

When the FireSIGHT System analyzes encrypted IP traffic, it can identify and classify commonly used encrypted applications on your network prior to decrypting the encrypted session. The system uses this discovery-based application awareness feature to allow you to control encrypted application traffic on your network.

Application conditions in SSL rules allow you to perform this application control. Within a single SSL rule, there are a few ways you can specify applications whose traffic you want to control:

- You can select individual applications, including custom applications.

- You can use system-provided application filters , which are named sets of applications organized according to its basic characteristics: type, risk, business relevance, and categories.

- You can create and use custom application filters, which group applications (including custom applications) in any way you choose.

Note When you filter application traffic using access control rules, you can use application tags as a criterion. to filter. However, you cannot use application tags to filter encrypted traffic because there is no benefit. All applications that the system can detect in encrypted traffic are tagged SSL Protocol; applications without this tag can only be detected in unencrypted or decrypted traffic.

Application filters allow you to quickly create application conditions for SSL rules. They simplify policy creation and administration, and grant you assurance that the system will control web traffic as expected. For example, you could create an SSL rule that identifies and decrypts all high risk, low business relevance applications in encrypted traffic. If a user attempts to use one of those applications, the session is decrypted and inspected with access control.

In addition, Cisco frequently updates and adds additional detectors via system and vulnerability database (VDB) updates. You can also create your own detectors and assign characteristics (risk, relevance, and so on) to the applications they detect. By using filters based on application characteristics, you can ensure that the system uses the most up-to-date detectors to monitor application traffic.

For traffic to match an SSL rule with an application condition, the traffic must match one of the filters or applications that you add to a Selected Applications and Filters list.

The following graphic shows the application condition for an SSL rule that decrypts a custom group of applications for MyCompany, all applications with high risk and low business relevance, gaming applications, and some individually selected applications.

In a single application condition, you can add a maximum of 50 items to the Selected Applications and Filters list. Each of the following counts as an item:

- One or more filters from the Application Filters list, individually or in custom combination. This item represents set of applications, grouped by characteristic.

- A filter created by saving search of the applications in the Available Applications list. This item represents a set of applications, grouped by substring match.

- An individual application from the Available Applications list.

In the web interface, filters added to a condition are listed above and separately from individually added applications.

Note that when you apply an SSL policy, for each rule with an application condition, the system generates a list of unique applications to match. In other words, you may use overlapping filters and individually specified applications to ensure complete coverage.

For more information, see the following sections:

- Matching Encrypted Traffic with Application Filters

- Matching Traffic from Individual Applications

- Adding an Application Condition to an SSL Rule

- Limitations to Encrypted Application Control

Matching Encrypted Traffic with Application Filters

License: Control

Supported Devices: Series 3

When building an application condition in an SSL rule, use the Application Filters list to create a set of applications, grouped by characteristic, whose traffic you want to match.

For your convenience, the system characterizes each application that it detects using the criteria described in Understanding Application Detection. You can use these criteria as filters or create custom combinations of filters to perform application control.

Note that the mechanism for filtering applications within an SSL rule is the same as that for creating reusable, custom application filters using the object manager; see Working with Application Filters. You can also save many filters you create on-the-fly in access control rules as new, reusable filters. You cannot save a filter that includes another user-created filter because you cannot nest user-created filters.

Understanding How Filters Are Combined

When you select filters, singly or in combination, the Available Applications list updates to display only the applications that meet your criteria. You can select system-provided filters in combination, but not custom filters.

The system links multiple filters of the same filter type with an OR operation. For example, if you select the Medium and High filters under the Risks type, the resulting filter is:

Risk: Medium OR High

If the Medium filter contained 110 applications and the High filter contained 82 applications, the system displays all 192 applications in the Available Applications list.

The system links different types of filters with an AND operation. For example, if you select the Medium and High filters under the Risks type, and the Medium and High filters under the Business Relevance type, the resulting filter is:

Risk: Medium OR High

AND

Business Relevance: Medium OR High

In this case, the system displays only those applications that are included in both the Medium or High Risk type AND the Medium or High Business Relevance type.

Finding and Selecting Filters

To select filters, click the arrow next to a filter type to expand it, then select or clear the check box next to each filter whose applications you want to display or hide. You can also right-click a Cisco-provided filter type (Risks, Business Relevance, Types, or Categories) and select Check All or Uncheck All.

To search for filters, click the Search by name prompt above the Available Filters list, then type a name. The list updates as you type to display matching filters.

After you are done selecting filters, use the Available Applications list to add those filters to the rule; see Matching Traffic from Individual Applications.

Matching Traffic from Individual Applications

License: Control

Supported Devices: Series 3

When building an application condition in an SSL rule, use the Available Applications list to select the applications whose traffic you want to match.

Browsing the List of Applications

When you first start to build the condition the list is unconstrained, and displays every application the system detects, 100 at a time:

- To page through the applications, click the arrows underneath the list.

- To display a pop-up window with summary information about the application’s characteristics, as well as Internet search links that you can follow, click the information icon (

) next to an application.

Finding Applications to Match

To help you find the applications you want to match, you can constrain the Available Applications list in the following ways:

- To search for applications, click the Search by name prompt above the list, then type a name. The list updates as you type to display matching applications.

- To constrain the applications by applying a filter, use the Application Filters list (see Matching Encrypted Traffic with Application Filters). The Available Applications list updates as you apply filters.

Once constrained, an All apps matching the filter option appears at the top of the Available Applications list. This option allows you to add all the applications in the constrained list to the Selected Applications and Filters list, all at once.

Note If you select one or more filters in the Application Filters list and also search the Available Applications list, your selections and the search-filtered Available Applications list are combined using an AND operation. That is, the All apps matching the filter condition includes all the individual conditions currently displayed in the Available Applications list as well as the search string entered above the Available Applications list.

Selecting Single Applications to Match in a Condition

After you find an application you want to match, click to select it. To select multiple applications, use the Shift and Ctrl keys, or right-click and select Select All to select all applications in the current constrained view.

In a single application condition, you can match a maximum of 50 applications by selecting them individually; to add more than 50 you must either create multiple SSL rules or use filters to group applications.

Selecting All Applications Matching a Filter for a Condition

Once constrained by either searching or using the filters in the Application Filters list, the All apps matching the filter option appears at the top of the Available Applications list.

This option allows you to add the entire set of applications in the constrained Available Applications list to the Selected Applications and Filters list, at once. In contrast to adding applications individually, adding this set of applications counts as only one item against the maximum of 50, regardless of the number of individual application that comprise it.

When you build an application condition this way, the name of the filter you add to the Selected Applications and Filters list is a concatenation of the filter types represented in the filter plus the names of up to three filters for each type. More than three filters of the same type are followed by an ellipsis (...). For example, the following filter name includes two filters under the Risks type and four under Business Relevance:

Risks: Medium, High Business Relevance: Low, Medium, High,...

Filter types that are not represented in a filter you add with All apps matching the filter are not included in the name of the filter you add. The instructional text that is displayed when you hover your pointer over the filter name in the Selected Applications and Filters list indicates that these filter types are set to any; that is, these filter types do not constrain the filter, so any value is allowed for these.

You can add multiple instances of All apps matching the filter to an application condition, with each instance counting as a separate item in the Selected Applications and Filters list. For example, you could add all high risk applications as one item, clear your selections, then add all low business relevance applications as another item. This application condition matches applications that are high risk OR have low business relevance.

Adding an Application Condition to an SSL Rule

License: Control

Supported Devices: Series 3

For encrypted traffic to match an SSL rule with an application condition, the traffic must match one of the filters or applications that you add to a Selected Applications and Filters list.

You can add a maximum of 50 items per condition, and filters added to a condition are listed above and separately from individually added applications. When building an application condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon.

To control encrypted application traffic:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control traffic by application, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Applications tab.

The Applications tab appears.

Step 3 Optionally, use filters to constrain the list of applications displayed in the Available Applications list.

Select one or more filters in the Application Filters list. For more information, see Matching Encrypted Traffic with Application Filters.

Step 4 Find and select the applications you want to add from the Available Applications list.

You can search for and select individual applications, or, when the list is constrained, All apps matching the filter. For more information, see Matching Traffic from Individual Applications.

Step 5 Click Add to Rule to add the selected applications to the Selected Applications and Filters list.

You can also drag and drop selected applications and filters. Filters appear under the heading Filters, and applications appear under the heading Applications.

Tip Before you add another filter to this application condition, click Clear All Filters to clear your existing selections.

Step 6 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Limitations to Encrypted Application Control

License: Control

Supported Devices: Series 3

Keep the following points in mind when performing application control.

Encrypted Application Identification

The system can identify unencrypted applications that become encrypted using StartTLS. This includes such applications as SMTPS, POPS, FTPS, TelnetS, and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS client hello message, or the server certificate subject distinguished name value.

Speed of Application Identification

The system cannot perform application control on encrypted traffic before:

- an encrypted connection is established between a client and server, and

- the system identifies the application in the encrypted session

).

After the system completes its identification, the system applies the SSL rule action to the remaining session traffic that matches its application condition.

Automatically Enabling Application Detectors

At least one detector must be enabled (see Activating and Deactivating Detectors) for each application rule condition in the policy. If no detector is enabled for an application, the system automatically enables all system-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

Controlling Encrypted Traffic by URL Category and Reputation

License: URL Filtering

Supported Devices: Series 3

URL conditions in SSL rules allow you to handle and decrypt encrypted website traffic that users on your network can access. The system detects the requested URL based on information passed during the SSL handshake. With a URL Filtering license, you can control access to websites based on the URL’s general classification, or category, and risk level, or reputation.

Note You can handle and decrypt traffic to specific URLs by defining a distinguished name SSL rule condition. The common name attribute in a certificate’s subject distinguished name contains the site’s URL. For more information, see Controlling Encrypted Traffic by Certificate Distinguished Name.

For more information, see:

- Performing Reputation-Based URL Blocking

- Limitations on URL Detection and Blocking

Performing Reputation-Based URL Blocking

License: URL Filtering

Supported Devices: Series 3

With a URL Filtering license, you can control your users’ access to websites based on the category and reputation of requested URLs:

- The URL category is a general classification for the URL. For example, ebay.com belongs to the Auctions category, and monster.com belongs to the Job Search category. A URL can belong to more than one category.

- The URL reputation represents how likely the URL is to be used for purposes that might be against your organization’s security policy. A URL’s risk can range from High Risk (level 1) to Well Known (level 5).

Caution Adding or removing a URL category and reputation condition in an SSL rule restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

URL categories and reputations, which the FireSIGHT System obtains from the Cisco cloud, allow you to quickly create URL conditions for SSL rules. For example, you could create an SSL rule that identifies and blocks all High risk URLs in the Abused Drugs category. If a user attempts to browse to any URL with that category and reputation combination over an encrypted connection, the session is blocked.

Note Before SSL rules with category and reputation-based URL conditions can take effect, you must enable communications with the Cisco cloud. This allows the Defense Center to retrieve URL data. For more information, see Enabling Cloud Communications.

Using category and reputation data from the Cisco cloud simplifies policy creation and administration. It grants you assurance that the system controls encrypted web traffic as expected. Finally, because the cloud is continually updated with new URLs, as well as new categories and risks for existing URLs, you can ensure that the system uses up-to-date information to filter requested URLs. Malicious sites that represent security threats such as malware, spam, botnets, and phishing may appear and disappear faster than you can update and apply new policies.

For example:

- If a rule blocks all gaming sites, as new domains get registered and classified as Gaming , the system can block those sites automatically.

- If a rule blocks all malware, and a blog page gets infected with malware, the cloud can recategorize the URL from Blog to Malware and the system can block that site.

- If a rule blocks high-risk social networking sites, and somebody posts a link on their profile page that contains links to malicious payloads, the cloud can change the reputation of that page from Benign sites to High risk so the system can block it.

Note that if the cloud does not know the category or reputation of a URL, or if the Defense Center cannot contact the cloud, that URL does not trigger SSL rules with category or reputation-based URL conditions. You cannot assign categories or reputations to URLs manually.

The following graphic shows the URL condition for an access control rule that blocks: all malware sites, all high-risk sites, and all non-benign social networking sites.

Tip If you decrypt traffic, then block it with access control, you can give users a chance to bypass the block by clicking through a warning page. See Interactive Blocking Actions: Allowing Users to Bypass Website Blocks for more information.

You can add a maximum of 50 Selected Categories to match in a single URL condition. Each URL category, optionally qualified by reputation, counts as a single item.

The following table summarizes how you build the condition shown above. Note that you cannot qualify a literal URL or URL object with a reputation.

Table 22-2 Example: Building A URL Condition

To block...

Select this Category or URL Object...

And this Reputation...

malware sites, regardless of reputation

Malware Sites

Any

any URL with a high risk (level 1)

Any

1 - High Risk

social networking sites with a risk greater than benign (levels 1 through 3)

Social Network

3 - Benign sites with security risks

When building a URL condition, warning icons indicate invalid configurations. For details, hover your pointer over the icon and see Troubleshooting Access Control Policies and Rules.

Caution Adding or removing a URL category and reputation condition in an SSL rule restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To control traffic by requested URL using category and reputation data:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by URL, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Categories tab.

The Categories tab appears.

Step 3 Find and select the categories of URL you want to add from the Categories list. To match encrypted web traffic regardless of category, select Any category.

To search for categories to add, click the Search by name or value prompt above the Categories list, then type the category name. The list updates as you type to display matching categories.

To select a category, click it. To select multiple categories, use the Shift and Ctrl keys.

Tip Although you can right-click and Select All categories, adding all categories this way exceeds the 50-item maximum for an SSL rule. Instead, use Any.

Step 4 Optionally, qualify your category selections by clicking a reputation level from the Reputations list. If you do not specify a reputation level, the system defaults to Any, meaning all levels.

You can only select one reputation level. When you choose a reputation level, the SSL rule behaves differently depending on its purpose:

- If the rule blocks web access or decrypts traffic (the rule action is Block , Block with reset , Decrypt - Known Key , Decrypt - Resign , or Monitor ) selecting a reputation level also selects all reputations more severe than that level. For example, if you configure a rule to block Suspicious sites (level 2), it also automatically blocks High Risk (level 1) sites.

- If the rule allows web access, subject to access control (the rule action is Do not decrypt ), selecting a reputation level also selects all reputations less severe than that level. For example, if you configure a rule to allow Benign sites (level 4), it also automatically allows Well known (level 5) sites.

If you change the rule action for a rule, the system automatically changes the reputation levels in URL conditions according to the above points.

Step 5 Click Add to Rule or to add the selected items to the Selected Categories list.

You can also drag and drop selected items.

Step 6 Save or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Limitations on URL Detection and Blocking

License: URL Filtering

Supported Devices: Series 3

Keep the following points in mind when performing URL detection and blocking.

Speed of URL Identification

The system cannot categorize URLs before:

- a monitored connection is established between a client and server

- the system identifies the HTTPS application in the session

- the system identifies the requested URL from either the client hello message or the server certificate

).

After the system completes its identification, the system applies the SSL rule action to the remaining session traffic that matches its URL condition.

Due to memory limitations, some device models perform URL filtering with a smaller, less granular, set of categories and reputations. For example, if a parent URL's subsites have different URL categories and reputations, some devices may use the parent URL's data for all subsites. As a specific example, the system might evaluate mail.google.com using the google.com category and reputation. Affected devices include the 71xx Family and the following ASA models: ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5512-X, ASA5515-X, ASA5516-X, and ASA5525-X.

For virtual devices, see the installation guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.

Search Query Parameters in URLs

The system does not use search query parameters in the URL to match URL conditions. For example, consider a scenario where you block all shopping traffic. In that case, using a web search to search for amazon.com is not blocked, but browsing to amazon.com is.

Controlling Traffic Based on Encryption Properties

License: Any

Supported Devices: Series 3

You can create SSL rules that handle and decrypt encrypted traffic based on encrypted connection characteristics. You can detect the protocol version or cipher suite used to encrypt the session, and handle traffic accordingly. You can also detect the server certificate and handle traffic, based on the following certificate characteristics:

- the server certificate itself

- the certificate issuer, whether an issuing CA or if the certificate is self-signed

- the certificate holder

- various certificate statuses, such as whether the certificate is valid, or revoked by the issuing CA

To detect multiple cipher suites in a rule, the certificate issuer, or the certificate holder, you can create reusable cipher suite list and distinguished name objects and add them to your rule. To detect the server certificate and certain certificate statuses, you must create external certificate and external CA objects for the rule.

For more information, see the following sections:

- Controlling Encrypted Traffic by Certificate Distinguished Name

- Controlling Encrypted Traffic by Certificate

- Controlling Encrypted Traffic by Certificate Status

- Controlling Encrypted Traffic by Cipher Suite

- Controlling Traffic by Encryption Protocol Version

Controlling Encrypted Traffic by Certificate Distinguished Name

License: Any

Supported Devices: Series 3

Distinguished name conditions in SSL rules allow you to handle and inspect encrypted traffic based on the CA that issued a server certificate, or the certificate holder. Based on the issuer distinguished name, you can handle traffic based on the CA that issued a site’s server certificate.

When configuring the rule condition, you can manually specify a literal value, reference a distinguished name object, or reference a distinguished name group containing multiple objects.

Note You cannot configure a distinguished name condition if you also select the Decrypt - Known Key action. Because that action requires you to select a server certificate to decrypt traffic, the certificate already matches the traffic. See Decrypt Actions: Decrypting Traffic for Further Inspection for more information.

You can match against multiple subject and issuer distinguished names in a single certificate status rule condition; only one common or distinguished name needs to match to match the rule.

If you add a distinguished name manually, it can contain the common name attribute (CN). If you add a common name without CN= then the system prepends CN= before saving the object.

Table 22-3 Distinguished Name Attributes

Attribute

Description

Allowed Values

C

Country Code

two alphabetic characters

CN

Common Name

up to 64 alphanumeric, backslash (\), hyphen (-), quotation ("), asterisk (*), period (.), or space characters

O

Organization

OU

Organizational Unit

The following graphic illustrates a distinguished name rule condition searching for certificates issued to goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these certificates is allowed, subject to access control.

You can add a maximum of 50 literal values and distinguished name objects to the Subject DNs, and 50 literal values and distinguished name objects to the Issuer DNs, in a single DN condition.

The system-provided DN object group, Sourcefire Undecryptable Sites, contains websites whose traffic the system cannot decrypt. You can add this group to a DN condition to block or not decrypt traffic to or from these websites, without wasting system resources attempting to decrypt that traffic. You can modify individual entries in the group. You cannot delete the group. System updates can modify the entries on this list, but the system preserves user changes.

To inspect encrypted traffic based on certificate subject or issuer distinguished name:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by certificate subject or issuer distinguished name, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the DN tab.

The DN tab appears.

Step 3 Find and select the distinguished names you want to add from the Available DNs, as follows:

- To add a distinguished name object on the fly, which you can then add to the condition, click the add icon (

) above the Available DNs list; see Working with Distinguished Name Objects.

- To search for distinguished name objects and groups to add, click the Search by name or value prompt above the Available DNs list, then type either the name of the object, or a value in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 You have the following options:

- Click Add to Subject to add the selected objects to the Subject DNs list.

- Click Add to Issuer to add the selected objects to the Issuer DNs list.

You can also drag and drop selected objects.

Step 5 Add any literal common names or distinguished names that you want to specify manually.

Click the Enter DN or CN prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished name and click Add.

Step 6 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Certificate

License: Any

Supported Devices: Series 3

Certificate conditions in SSL rules allow you to handle and inspect encrypted traffic based on the server certificate used to encrypt that traffic. You can configure a condition with one or more certificates; traffic matches the rule if the certificate matches any of the condition’s certificates.

When you build a certificate-based SSL rule condition, you can upload a server certificate; you save the certificate as an external certificate object, which is reusable and associates a name with a server certificate. Alternately, you can configure certificate conditions with existing external certificate objects and object groups.

You can search the Available Certificates field in the rule condition based for external certificate objects and object groups based on the following certificate distinguished name characteristics:

- subject or issuer common name (CN)

- subject or issuer organization (O)

- subject or issuer organizational unit (OU)

You can choose to match against multiple certificates in a single certificate rule condition; if the certificate used to encrypt the traffic matches any of the uploaded certificates, the encrypted traffic matches the rule.

You can add a maximum of 50 external certificate objects and external certificate object groups to the Selected Certificates in a single certificate condition.

Note the following:

- You cannot configure a certificate condition if you also select the Decrypt - Known Key action. Because that action requires you to select a server certificate to decrypt traffic, the implication is that the certificate already matches the traffic. See Decrypt Actions: Decrypting Traffic for Further Inspection for more information.

- If you configure a certificate condition with an external certificate object, any cipher suites you add to a cipher suite condition, or internal CA objects you associate with the Decrypt - Resign action, must match the external certificate’s signature algorithm type. For example, if your rule’s certificate condition references an EC-based server certificate, any cipher suites you add, or CA certificates you associate with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in this case, the policy editor displays a warning icon next to the rule. For more information, see Controlling Encrypted Traffic by Cipher Suite and Decrypt Actions: Decrypting Traffic for Further Inspection.

To inspect encrypted traffic based on server certificate:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic based on server certificate, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Certificate tab.

The Certificate tab appears.

Step 3 Find and select the server certificates you want to add from the Available Certificates, as follows;

- To add an external certificate object on the fly, which you can then add to the condition, click the add icon (

) above the Available Certificates list; see Working with External Certificate Objects.

- To search for certificate objects and groups to add, click the Search by name or value prompt above the Available Certificates list, then type either the name of the object, or a value in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule to add the selected objects to the Subject Certificates list.

You can also drag and drop selected objects.

Step 5 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Certificate Status

License: Any

Supported Devices: Series 3

Certificate status conditions in SSL rules allow you to handle and inspect encrypted traffic based on the status of the server certificate used to encrypt the traffic, including whether a certificate is valid, revoked, expired, not yet valid, self-signed, or signed by a trusted CA.

Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates and associated CRLs as objects. You then add these trusted CA objects to an SSL policy’s list of trusted CA certificates.

For each certificate status SSL rule condition you configure, you can match traffic against the presence or absence of a given status. You can select several statuses in one rule condition; if the certificate matches any of the selected statuses, the rule matches the traffic.

For more information, see:

- Trusting External Certificate Authorities

- Matching Traffic on Certificate Status

Trusting External Certificate Authorities

License: Any

Supported Devices: Series 3

You can trust CAs by adding root and intermediate CA certificates to your SSL policy, then use these trusted CAs to verify server certificates used to encrypt traffic. Verified server certificates include certificates signed by trusted CAs.

If a trusted CA certificate contains an uploaded certificate revocation list (CRL), you can also verify whether a trusted CA revoked the encryption certificate. See Adding a Certificate Revocation List to a Trusted CA Object for more information.

After you add trusted CA certificates to the SSL policy, you can configure an SSL rule with various Certificate Status conditions to match against this traffic. See Working with Trusted Certificate Authority Objects and Controlling Encrypted Traffic by Certificate Status for more information.

Tip Upload all certificates within a root CA’s chain of trust to the list of trusted CA certificates, including the root CA certificate and all intermediate CA certificates. Otherwise, it is more difficult to detect trusted certificates issued by intermediate CAs.

When you create an SSL policy, the system populates the Trusted CA Certificates tab with a default Trusted CA object group, Sourcefire Trusted Authorities. You can modify individual entries in the group, and choose whether to include this group in your SSL policy. You cannot delete the group. System updates can modify the entries on this list, but user changes are preserved. See Creating a Basic SSL Policy for more information.

To add trusted CAs to your policy:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy you want to configure.

The SSL policy editor appears.

Step 3 Select the Trusted CA Certificates tab.

The Trusted CA Certificates page appears.

Step 4 Find and select the trusted CAs you want to add from the Available Trusted CAs, as follows:

- To add a trusted CA object on the fly, which you can then add to the condition, click the add icon (

) above the Available Trusted CAs list; see Working with Trusted Certificate Authority Objects.

- To search for trusted CA objects and groups to add, click the Search by name or value prompt above the Available Trusted CAs list, then type either the name of the object, or a value in the object. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 5 Click Add to Rule to add the selected objects to the Selected Trusted CAs list.

You can also drag and drop selected objects.

Step 6 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Matching Traffic on Certificate Status

License: Any

Supported Devices: Series 3

Based on the certificate status rule condition configuration, you can match encrypted traffic based on the status of the server certificate used to encrypt traffic. You can:

- check for a server certificate status

- check that a certificate does not have a status

- skip checking for the presence or absence of a certificate status

You can choose to match against the presence or absence of multiple certificate statuses in a single certificate status rule condition; the certificate needs to only match one of the criteria to match the rule.

Table 22-4 Certificate Status Rule Condition Criteria

Status Check

Status Set to Yes

Status Set to No

Revoked

The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy contains a CRL that revokes the server certificate.

The policy trusts the CA that issued the server certificate, and the CA certificate uploaded to the policy does not contain a CRL that revokes the certificate.

Self-signed

The detected server certificate contains the same subject and issuer distinguished name.

The detected server certificate contains different subject and issuer distinguished names.

Valid

All of the following are true:

- The policy trusts the CA that issued the certificate

- The signature is valid

- The issuer is valid

- None of the policy’s trusted CAs revoked the certificate.

- The current date is between the certificate Valid From and Valid To date

At least one of the following is true:

- The policy does not trust the CA that issued the certificate

- The signature is invalid

- The issuer is invalid

- A trusted CA in the policy revoked the certificate

- The current date is before the certificate Valid From date

- The current date is after the certificate Valid To date

Invalid signature

The certificate’s signature cannot be properly validated against the certificate’s content.

The certificate’s signature is properly validated against the certificate’s content.

Invalid issuer

The issuer CA certificate is not stored in the policy’s list of trusted CA certificates.

The issuer CA certificate is stored in the policy’s list of trusted CA certificates.

Expired

The current date is after the certificate Valid To date.

The current date is before or on the certificate Valid To date.

Not yet valid

The current date is before the certificate Valid From date.

The current date is after or on the certificate Valid From date.

Consider the following example. The organization trusts the Verified Authority certificate authority. The organization does not trust the Spammer Authority certificate authority. The system administrator uploads the Verified Authority certificate and an intermediate CA certificate issued by Verified Authority to the system. Because Verified Authority revoked a certificate it previously issued, the system administrator uploads the CRL that Verified Authority distributed.

The following graphic illustrates a certificate status rule condition checking for valid certificates, those issued by Verified Authority, not on the CRL, and still within the Valid From and Valid To date. Because of the configuration, traffic encrypted with these certificates is not decrypted and inspected with access control.

Note that even though a certificate may match more than one status, the rule only takes an action on the traffic once.

To inspect encrypted traffic by server certificate status:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic based on server certificate status, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Cert Status tab.

The Cert Status tab appears.

Step 3 For each certificate status, you have the following options:

- Select Yes to match against the presence of that certificate status.

- Select No to match against the absence of that certificate status.

- Select Do Not Match to not match that certificate status.

Step 4 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Encrypted Traffic by Cipher Suite

License: Any

Supported Devices: Series 3

Cipher suite conditions in SSL rules allow you to handle and inspect encrypted traffic based on the cipher suite used to negotiate the encrypted session. Cisco provides predefined cipher suites you can add to a cipher suite rule condition. You can also add cipher suite list objects containing multiple cipher suites. For more information on cipher suite lists, see Working with Cipher Suite Lists.

Note You cannot add new cipher suites. You can neither modify nor delete predefined cipher suites.

You can add a maximum of 50 cipher suites and cipher suite lists to the Selected Cipher Suites in a single Cipher Suite condition.

Note the following:

- If you add cipher suites not supported for your deployment, you cannot apply the access control policy associated with the SSL policy. For example, passive deployments do not support decrypting traffic with the any of the ephemeral Diffie-Hellman (DHE) or ephemeral elliptic curve Diffie-Hellman (ECDHE) cipher suites. Creating a rule with these cipher suites prevents you from applying your access control policy.

- If you configure a cipher suite condition with a cipher suite, any external certificate objects you add to a certificate condition, or internal CA objects you associate with the Decrypt - Resign action, must match the cipher suite’s signature algorithm type. For example, if your rule’s cipher suite condition references an EC-based cipher suite, any server certificates you add, or CA certificates you associate with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in this case, the policy editor displays a warning icon next to the rule. For more information, see Controlling Encrypted Traffic by Cipher Suite and Decrypt Actions: Decrypting Traffic for Further Inspection.

- The system cannot decrypt traffic encrypted with an anonymous cipher suite. You cannot use either the Decrypt - Resign or Decrypt - Known Key action in an SSL rule if you add an anonymous cipher suite to the Cipher Suite condition.

To inspect encrypted traffic by cipher suite:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by cipher suite, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Cipher Suite tab.

The Cipher Suite tab appears.

Step 3 Find and select the cipher suites you want to add from the Available Cipher Suites, as follows;

- To add a cipher suite list on the fly, which you can then add to the condition, click the add icon (

) above the Available Cipher Suites list; see Working with Cipher Suite Lists.

- To search for cipher suites and lists to add, click the Search by name or value prompt above the Available Cipher Suites list, then type either the name of the cipher suite, or a value in the cipher suite. The list updates as you type to display matching cipher suites.

To select a cipher suite, click it. To select multiple cipher suites, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Rule to add the selected cipher suites to the Selected Cipher Suites list.

You can also drag and drop selected cipher suites.

Step 5 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Controlling Traffic by Encryption Protocol Version

License: Any

Supported Devices: Series 3

Session conditions in SSL rules allow you to inspect encrypted traffic based on the SSL or TLS version used to encrypt the traffic. You can choose to match against traffic encrypted with SSL version 3.0, or TLS version 1.0, 1.1, or 1.2. By default, all protocol versions are selected when you create a rule; if you select multiple versions, encrypted traffic that matches any of the selected versions matches the rule. You must select at least one protocol version when saving the rule condition.

Note You cannot select SSL v2.0 in a version rule condition; the system does not support decrypting traffic encrypted with SSL version 2.0. You can configure an undecryptable action to allow or block this traffic without further inspection. For more information, see Logging Decryptable Connections with SSL Rules.

To inspect encrypted traffic by SSL or TLS version:

Access: Admin/Access Admin/Network Admin

Step 1 In the SSL policy where you want to control encrypted traffic by encryption protocol version, create a new SSL rule or edit an existing rule.

For detailed instructions, see Understanding and Creating SSL Rules.

Step 2 In the SSL rule editor, select the Version tab.

The Version tab appears.

Step 3 Select the protocol versions you want to match against: SSL v3.0, TLS v1.0, TLS v1.1, or TLS v1.2.

Step 4 Add or continue editing the rule.

You must apply the access control policy associated with the SSL policy for your changes to take effect; see Applying an Access Control Policy.

Understanding Network Analysis and Intrusion Policies

Network analysis and intrusion policies work together as part of the FireSIGHT System’s intrusion detection and prevention feature. The term intrusion detection generally refers to the process of passively analyzing network traffic for potential intrusions and storing attack data for security analysis. The term intrusion prevention includes the concept of intrusion detection, but adds the ability to block or alter malicious traffic as it travels across your network.

In an intrusion prevention deployment, when the system examines packets:

- A network analysis policy governs how traffic is decoded and preprocessed so that it can be further evaluated, especially for anomalous traffic that might signal an intrusion attempt.

- An intrusion policy uses intrusion and preprocessor rules (sometimes referred to collectively as intrusion rules ) to examine the decoded packets for attacks based on patterns. Intrusion policies are paired with variable sets , which allow you to use named values to accurately reflect your network environment.

Both network analysis and intrusion policies are invoked by a parent access control policy, but at different times. As the system analyzes traffic, the network analysis (decoding and preprocessing) phase occurs before and separately from the intrusion prevention (additional preprocessing and intrusion rules) phase. Together, network analysis and intrusion policies provide broad and deep packet inspection. They can help you detect, alert on, and protect against network traffic that could threaten the availability, integrity, and confidentiality of hosts and their data.

The FireSIGHT System is delivered with several similarly named network analysis and intrusion policies (for example, Balanced Security and Connectivity) that complement and work with each other. By using system-provided policies, you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states, as well as provides the initial configurations for preprocessors and other advanced settings.

You can also create custom network analysis and intrusion policies. You can tune settings in custom policies to inspect traffic in the way that matters most to you so that you can improve both the performance of your managed devices and your ability to respond effectively to the events they generate.

You create, edit, save, and manage network analysis and intrusion policies using similar policy editors in the web interface. When you are editing either type of policy, a navigation panel appears on the left side of the web interface; the right side displays various configuration pages.

This chapter contains a brief overview of the types of configurations the network analysis and intrusion policies govern, explains how the policies work together to examine traffic and generate records of policy violations, and provides basic information on navigating the policy editors. This chapter also explains the benefits and limitations of using custom versus system-provided policies. For more information, see the following sections:

- Understanding How Policies Examine Traffic For Intrusions

- Comparing System-Provided with Custom Policies

- Using the Navigation Panel

- Resolving Conflicts and Committing Policy Changes

To customize your intrusion deployment, see the following for your next steps:

- Working with Variable Sets explains how to configure the system’s intrusion variables to accurately reflect your network environment. Even if you do not use custom policies, Cisco strongly recommends you modify the default variables in the default variable set. Advanced users can create and use custom variable sets for pairing with one or more custom intrusion policies.

- Getting Started with Intrusion Policies explains how to create and edit a simple custom intrusion policy.

- Controlling Traffic Using Intrusion and File Policies explains how to configure the system to use intrusion policies to examine only the traffic you are interested in, by associating intrusion policies with a parent access control policy. It also explains how to configure advanced intrusion policy performance options.

- Configuring Advanced Transport/Network Settings explains how to configure advanced transport and network preprocessor settings that apply globally to all traffic handled by the target devices of an access control policy. You configure these advanced settings in an access control policy rather than in a network analysis or intrusion policy.

- Getting Started with Network Analysis Policies explains how to create and edit a simple custom network analysis policy.

- Customizing Preprocessing with Network Analysis Policies explains how to change the default network analysis policy. For advanced users, this section also explains how to tailor preprocessing to specific security zones, networks, and VLANs by assigning custom network analysis policies to preprocess matching traffic.

- Using Layers in a Network Analysis or Intrusion Policy explain how, in larger organizations or complex deployments, you can use building blocks called policy layers to more efficiently manage multiple network analysis or intrusion policies.

Understanding How Policies Examine Traffic For Intrusions

License: Protection

When the system analyzes traffic as part of your access control deployment, the network analysis (decoding and preprocessing) phase occurs before and separately from the intrusion prevention (intrusion rules and advanced settings) phase.

In an inline deployment, the system can block traffic without further inspection at almost any step in the illustrated process. Security Intelligence, the SSL policy, network analysis policies, file policies, and intrusion policies can all either drop or modify traffic. Only the network discovery policy, which passively inspects packets, cannot affect the flow of traffic.

Similarly, at each step of the process, a packet could cause the system to generate an event. Intrusion and preprocessor events (sometimes referred to collectively as intrusion events) are indications that a packet or its contents may represent a security risk.

Tip The diagram does not reflect that access control rules handle encrypted traffic when your SSL inspection configuration allows it to pass, or if you do not configure SSL inspection. By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured. For more information, see Understanding Traffic Decryption and Using the SSL Preprocessor.

Note that for a single connection, although the system selects a network analysis policy before an access control rule as shown in the diagram, some preprocessing (notably application layer preprocessing) occurs after access control rule selection. This does not affect how you configure preprocessing in custom network analysis policies.

For more information, see:

- Decoding, Normalizing, and Preprocessing: Network Analysis Policies

- Access Control Rules: Intrusion Policy Selection

- Intrusion Inspection: Intrusion Policies, Rules, and Variable Sets

- Intrusion Event Generation

Decoding, Normalizing, and Preprocessing: Network Analysis Policies

License: Protection

Without decoding and preprocessing, the system could not appropriately evaluate traffic for intrusions because protocol differences would make pattern matching impossible. As shown in the diagram in Understanding How Policies Examine Traffic For Intrusions, network analysis policies govern these traffic-handling tasks:

- after traffic is filtered by Security Intelligence

- after encrypted traffic is decrypted by an optional SSL policy

- before traffic can be inspected by file or intrusion policies

A network analysis policy governs packet processing in phases. First the system decodes packets through the first three TCP/IP layers, then continues with normalizing, preprocessing, and detecting protocol anomalies:

- The packet decoder converts packet headers and payloads into a format that can be easily used by the preprocessors and later, intrusion rules. Each layer of the TCP/IP stack is decoded in turn, beginning with the data link layer and continuing through the network and transport layers. The packet decoder also detects various anomalous behaviors in packet headers. For more information, see Understanding Packet Decoding.

- In inline deployments, the inline normalization preprocessor reformats (normalizes) traffic to minimize the chances of attackers evading detection. It prepares packets for examination by other preprocessors and intrusion rules, and helps ensure that the packets the system processes are the same as the packets received by the hosts on your network. For more information, see Normalizing Inline Traffic.

Tip In a passive deployment, Cisco recommends that you configure adaptive profiles at the access control policy level, instead of inline normalization at the network analysis level. For more information, see Tuning Preprocessing in Passive Deployments.

- Various network and transport layers preprocessors detect attacks that exploit IP fragmentation, perform checksum validation, and perform TCP and UDP session preprocessing; see Configuring Transport & Network Layer Preprocessing.

Note that some advanced transport and network preprocessor settings apply globally to all traffic handled by the target devices of an access control policy. You configure these in the access control policy rather than in a network analysis policy; see Configuring Advanced Transport/Network Settings.

- Various application-layer protocol decoders normalize specific types of packet data into formats that the intrusion rules engine can analyze. Normalizing application-layer protocol encodings allows the system to effectively apply the same content-related intrusion rules to packets whose data is represented differently, and to obtain meaningful results. For more information, see Using Application Layer Preprocessors.

- The Modbus and DNP3 SCADA preprocessors detect traffic anomalies and provide data to intrusion rules. Supervisory Control and Data Acquisition (SCADA) protocols monitor, control, and acquire data from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment, electric power distribution, airport and shipping systems, and so on. For more information, see Configuring SCADA Preprocessing.

- Several preprocessors allow you to detect specific threats, such as Back Orifice, portscans, SYN floods and other rate-based attacks; see Detecting Specific Threats.

Note that you configure the sensitive data preprocessor, which detects sensitive data such as credit card numbers and Social Security numbers in ASCII text, in intrusion policies; see Detecting Sensitive Data.

In a newly created access control policy, one default network analysis policy governs preprocessing for all traffic for all intrusion policies invoked by the same parent access control policy. Initially, the system uses the Balanced Security and Connectivity network analysis policy as the default, but you can change it to another system-provided or custom network analysis policy. In a more complex deployment, advanced users can tailor traffic preprocessing options to specific security zones, networks, and VLANs by assigning different custom network analysis policies to preprocess matching traffic. For more information, see Comparing System-Provided with Custom Policies.

Access Control Rules: Intrusion Policy Selection

License: Protection

After initial preprocessing, access control rules (when present) evaluate traffic. In most cases, the first access control rule that a packet matches is the rule that handles that traffic; you can monitor, trust, block, or allow matching traffic.

When you allow traffic with an access control rule, the system can inspect the traffic for discovery data, malware, prohibited files, and intrusions, in that order. Traffic not matching any access control rule is handled by the access control policy’s default action, which can also inspect for discovery data and intrusions.

Note All packets, regardless of which network analysis policy preprocesses them, are matched to configured access control rules—and thus are potentially subject to inspection by intrusion policies—in top-down order. For more information, see Limitations of Custom Policies.

The diagram in Understanding How Policies Examine Traffic For Intrusions shows the flow of traffic through a device in an inline, intrusion prevention and AMP deployment, as follows:

- Access Control Rule A allows matching traffic to proceed. The traffic is then inspected for discovery data by the network discovery policy, for prohibited files and malware by File Policy A, and then for intrusions by Intrusion Policy A.

- Access Control Rule B also allows matching traffic. However, in this scenario, the traffic is not inspected for intrusions (or files or malware), so there are no intrusion or file policies associated with the rule. Note that by default, traffic that you allow to proceed is inspected by the network discovery policy; you do not need to configure this.

- In this scenario, the access control policy’s default action allows matching traffic. The traffic is then inspected by the network discovery policy, and then by an intrusion policy. You can (but do not have to) use a different intrusion policy when you associate intrusion policies with access control rules or the default action.

The example in the diagram does not include any blocking or trusting rules because the system does not inspect blocked or trusted traffic. For more information, see Using Rule Actions to Determine Traffic Handling and Inspection and Setting Default Handling and Inspection for Network Traffic.

Intrusion Inspection: Intrusion Policies, Rules, and Variable Sets

License: Protection

You can use intrusion prevention as the system’s last line of defense before traffic is allowed to proceed to its destination. Intrusion policies govern how the system inspects traffic for security violations and, in inline deployments, can block or alter malicious traffic. The main function of intrusion policies is to manage which intrusion and preprocessor rules are enabled and how they are configured.

Intrusion and Preprocessor Rules

An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit vulnerabilities on your network; the system uses an intrusion rule to analyze network traffic to check if it matches the criteria in the rule. The system compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in a rule, the rule triggers.

The system includes the following types of rules created by the VRT:

- shared object intrusion rules , which are compiled and cannot be modified (except for rule header information such as source and destination ports and IP addresses)

- standard text intrusion rules , which can be saved and modified as new custom instances of the rule.

- preprocessor rules , which are rules associated with preprocessors and packet decoder detection options in the network analysis policy. You cannot copy or edit preprocessor rules. Most preprocessor rules are disabled by default; you must enable them to use preprocessors to generate events and, in an inline deployment, drop offending packets.

When the system processes packets according to an intrusion policy, first a rule optimizer classifies all activated rules in subsets based on criteria such as: transport layer, application protocol, direction to or from the protected network, and so on. Then, the intrusion rules engine selects the appropriate rule subsets to apply to each packet. Finally, a multi-rule search engine performs three different types of searches to determine if the traffic matches the rule:

- The protocol field search looks for matches in particular fields in an application protocol.

- The generic content search looks for ASCII or binary byte matches in the packet payload.

- The packet anomaly search looks for packet headers and payloads that, rather than containing specific content, violate well-established protocols.

In a custom intrusion policy, you can tune detection by enabling and disabling rules, as well as by writing and adding your own standard text rules. You can also use FireSIGHT recommendations to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets.

Variable Sets

Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Most variables in a set represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions and dynamic rule states.

The system provides a single default variable set, which is comprised of predefined default variables. Most system-provided shared object rules and standard text rules use these predefined default variables to define networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network. In addition, specialized rules often use other predefined variables. For example, rules that detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.

Tip Even if you use system-provided intrusion policies, Cisco strongly recommends you modify key default variables in the default set. When you use variables that accurately reflect your network environment, processing is optimized and the system can monitor relevant systems for suspicious activity. Advanced users can create and use custom variable sets for pairing with one or more custom intrusion policies. For more information, see Optimizing Predefined Default Variables.

Intrusion Event Generation

License: Protection

When the system identifies a possible intrusion, it generates an intrusion or preprocessor event (sometimes collectively called intrusion events). Managed devices transmit their events to the Defense Center, where you can view the aggregated data and gain a greater understanding of the attacks against your network assets. In an inline deployment, managed devices can also drop or replace packets that you know to be harmful.

Each intrusion event in the database includes an event header and contains information about the event name and classification; the source and destination IP addresses; ports; the process that generated the event; and the date and time of the event, as well as contextual information about the source of the attack and its target. For packet-based events, the system also logs a copy of the decoded packet header and payload for the packet or packets that triggered the event.

The packet decoder, the preprocessors, and the intrusion rules engine can all cause the system to generate an event. For example:

- If the packet decoder (configured in the network analysis policy) receives an IP packet that is less than 20 bytes, which is the size of an IP datagram without any options or payload, the decoder interprets this as anomalous traffic. If, later, the accompanying decoder rule in the intrusion policy that examines the packet is enabled, the system generates a preprocessor event.

- If the IP defragmentation preprocessor encounters a series of overlapping IP fragments, the preprocessor interprets this as a possible attack and, when the accompanying preprocessor rule is enabled, the system generates a preprocessor event.

- Within the intrusion rules engine, most standard text rules and shared object rules are written so that they generate intrusion events when triggered by packets.

As the database accumulates intrusion events, you can begin your analysis of potential attacks. The system provides you with the tools you need to review intrusion events and evaluate whether they are important in the context of your network environment and your security policies.

Comparing System-Provided with Custom Policies

License: Protection

Creating a new access control policy is one of the first steps in managing traffic flow using the FireSIGHT System. By default, a newly created access control policy invokes system-provided network analysis and intrusion policies to examine traffic.

The following diagram shows how a newly created access control policy in an inline, intrusion-prevention deployment initially handles traffic. The preprocessing and intrusion prevention phases are highlighted.

Note how:

- A default network analysis policy governs the preprocessing of all traffic handled by the access control policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default.

- The default action of the access control policy allows all non-malicious traffic, as determined by the system-provided Balanced Security and Connectivity intrusion policy . Because the default action allows traffic to pass, the discovery feature can examine it for host, application, and user data before the intrusion policy can examine and potentially block malicious traffic.

- The policy uses default Security Intelligence options (global whitelist and blacklist only), does not decrypt encrypted traffic with an SSL policy, and does not perform special handling and inspection of network traffic using access control rules.

A simple step you can take to tune your intrusion prevention deployment is to use a different set of system-provided network analysis and intrusion policies as your defaults. Cisco delivers several pairs of these policies with the FireSIGHT System.

Or, you can tailor your intrusion prevention deployment by creating and using custom policies. You may find that the preprocessor options, intrusion rule, and other advanced settings configured in those policies do not address the security needs of your network. By tuning your network analysis and intrusion policies you can configure, at a very granular level, how the system processes and inspects the traffic on your network for intrusions.

For more information, see:

- Understanding the System-Provided Policies

- Benefits of Custom Policies

- Limitations of Custom Policies

Understanding the System-Provided Policies

License: Protection

Cisco delivers several pairs of network analysis and intrusion policies with the FireSIGHT System. By using system-provided network analysis and intrusion policies, you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states, as well as provides the initial configurations for preprocessors and other advanced settings.

No system-provided policy covers every network profile, traffic mix, or defensive posture. Each covers common cases and network setups that provide a starting point for a well-tuned defensive policy. Although you can use system-provided policies as-is, Cisco strongly recommends that you use them as the base for custom policies that you tune to suit your network.

Tip Even if you use system-provided network analysis and intrusion policies, you should configure the system’s intrusion variables to accurately reflect your network environment. At a minimum, modify key default variables in the default set; see Optimizing Predefined Default Variables.

As new vulnerabilities become known, the VRT releases intrusion rule updates. These rule updates can modify any system-provided network analysis or intrusion policy, and can provide new and updated intrusion rules and preprocessor rules, modified states for existing rules, and modified default policy settings. Rule updates may also delete rules from system-provided policies and provide new rule categories, as well as modify the default variable set.

If a rule update affects your deployment, the web interface marks affected intrusion and network analysis policies as out of date, as well as their parent access control policies. You must reapply an updated policy for its changes to take effect.

For your convenience, you can configure rule updates to automatically reapply affected intrusion policies, either alone or in combination with affected access control policies. This allows you to easily and automatically keep your deployment up-to-date to protect against recently discovered exploits and intrusions.

To ensure up-to-date preprocessing settings, you must reapply access control policies, which also reapplies any associated SSL, network analysis, and file policies that are different from those currently running, and can also can update default values for advanced preprocessing and performance options. For more information, seeImporting Rule Updates and Local Rule Files.

Cisco delivers the following network analysis and intrusion policies with the FireSIGHT System:

Balanced Security and Connectivity network analysis and intrusion policies

These policies are built for both speed and detection. Used together, they serve as a good starting point for most organizations and deployment types. The system uses the Balanced Security and Connectivity policies and settings as defaults in most cases.

Connectivity Over Security network analysis and intrusion policies

These policies are built for organizations where connectivity (being able to get to all resources) takes precedence over network infrastructure security. The intrusion policy enables far fewer rules than those enabled in the Security over Connectivity policy. Only the most critical rules that block traffic are enabled.

Security Over Connectivity network analysis and intrusion policies

These policies are built for organizations where network infrastructure security takes precedence over user convenience. The intrusion policy enables numerous network anomaly intrusion rules that could alert on or drop legitimate traffic.

Maximum Detection network analysis and intrusion policies

These policies are built for organizations where network infrastructure security is given even more emphasis than is given by the Security Over Connectivity policies, with the potential for even greater operational impact. For example, the intrusion policy enables rules in a large number of threat categories including malware, exploit kit, old and common vulnerabilities, and known in-the-wild exploits.

No Rules Active intrusion policy

In the No Rules Active intrusion policy, all intrusion rules and advanced settings are disabled. This policy provides a starting point if you want to create your own intrusion policy instead of basing it on the enabled rules in one of the other system-provided policies.

Benefits of Custom Policies

License: Protection

You may find that the preprocessor options, intrusion rules, and other advanced settings configured in the system-provided network analysis and intrusion policies do not fully address the security needs of your organization.

Building custom policies can improve the performance of the system in your environment and can provide a focused view of the malicious traffic and policy violations occurring on your network. By creating and tuning custom policies you can configure, at a very granular level, how the system processes and inspects the traffic on your network for intrusions.

All custom policies have a base policy, also called a base layer, which defines the default settings for all configurations in the policy. A layer is a building block that you can use to efficiently manage multiple network analysis or intrusion policies; see Using Layers in a Network Analysis or Intrusion Policy.

In most cases, you base custom policies on system-provided policies, but you can use another custom policy. However, all custom policies have a system-provided policy as the eventual base in a policy chain. Because rule updates can modify system-provided policies, importing a rule update may affect you even if you are using a custom policy as your base. If a rule update affects your deployment, the web interface marks affected policies as out of date. For more information, see Allowing Rule Updates to Modify a System-Provided Base Policy.

In addition to custom policies that you create, the system provides two custom intrusion and two custom network analysis policies: Initial Inline Policy and Initial Passive Policy. These policies use the appropriate Balanced Security and Connectivity policy as their base. The only difference between them is their drop behavior, which enables traffic blocking and modification in the inline policies and disables it in the passive policies. You can edit and use these system-provided custom policies.

For more information, see:

- Benefits of a Custom Network Analysis Policy

- Benefits of Custom Intrusion Policies

Benefits of a Custom Network Analysis Policy

License: Protection

By default, one network analysis policy preprocesses all unencrypted traffic handled by the access control policy. That means that all packets are decoded and preprocessed according to the same settings, regardless of the intrusion policy (and therefore intrusion rule set) that later examines them.

Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default. A simple way to tune preprocessing is to create and use a custom network analysis policy as the default; see Setting the Default Network Analysis Policy for Access Control.

Tuning options available vary by preprocessor, but some of the ways you can tune preprocessors and decoders include:

- You can disable preprocessors that do not apply to the traffic you are monitoring. For example, the HTTP Inspect preprocessor normalizes HTTP traffic. If you are confident that your network does not include any web servers using Microsoft Internet Information Services (IIS), you can disable the preprocessor option that looks for IIS-specific traffic and thereby reduce system processing overhead.

Note If you disable a preprocessor in a custom network analysis policy, but the system needs to use that preprocessor to later evaluate packets against an enabled intrusion or preprocessor rule, the system automatically enables and uses the preprocessor although the preprocessor remains disabled in the network analysis policy web interface.

- Specify ports, where appropriate, to focus the activity of certain preprocessors. For example, you can identify additional ports to monitor for DNS server responses or encrypted SSL sessions, or ports on which you decode telnet, HTTP, and RPC traffic.

For advanced users with complex deployments, you can create multiple network analysis policies, each tailored to preprocess traffic differently. Then, you can configure the system to use those policies to govern the preprocessing of traffic using different security zones, networks, or VLANs. (Note that ASA FirePOWER devices cannot restrict preprocessing by VLAN.)

Note Tailoring preprocessing using custom network analysis policies—especially multiple network analysis policies—is an advanced task. Because preprocessing and intrusion inspection are so closely related, you must be careful to allow the network analysis and intrusion policies examining a single packet to complement each other. For more information, see Limitations of Custom Policies.

Benefits of Custom Intrusion Policies

License: Protection

In a newly created access control policy initially configured to perform intrusion prevention, the default action allows all traffic, but first inspects it with the system-provided Balanced Security and Connectivity intrusion policy. Unless you add access control rules or change the default action, all traffic is inspected by that intrusion policy; see the diagram in Comparing System-Provided with Custom Policies.

To customize your intrusion prevention deployment, you can create multiple intrusion policies, each tailored to inspect traffic differently. Then, configure an access control policy with rules that specify which policy inspects which traffic. Access control rules can be simple or complex, matching and inspecting traffic using multiple criteria including security zone, network or geographical location, VLAN, port, application, requested URL, or user. The scenario in Understanding How Policies Examine Traffic For Intrusions shows a deployment where traffic is inspected by one of two intrusion policies.

The main function of intrusion policies is to manage which intrusion and preprocessor rules are enabled and how they are configured, as follows:

- Within each intrusion policy, you should verify that all rules applicable to your environment are enabled, and improve performance by disabling rules that are not applicable to your environment. In an inline deployment, you can specify which rules should drop or modify malicious packets. For more information, see Setting Rule States.

- FireSIGHT recommendations allow you to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets; see Tailoring Intrusion Protection to Your Network Assets.

- You can modify existing rules and write new standard text rules as needed to catch new exploits or to enforce your security policies; see Understanding and Writing Intrusion Rules.

Other customizations you might make to an intrusion policy include:

- The sensitive data preprocessor detects sensitive data such as credit card numbers and Social Security numbers in ASCII text. Note that other preprocessors that detect specific threats (back orifice attacks, several portscan types, and rate-based attacks that attempt to overwhelm your network with excessive traffic) are configured in network analysis policies. For more information, see Detecting Specific Threats.

- Global thresholds cause the system to generate events based on how many times traffic matching an intrusion rule originates from or is targeted to a specific address or address range within a specified time period. This helps prevent the system from being overwhelmed with a large number of events. For more information, see Globally Limiting Intrusion Event Logging.

- Suppressing intrusion event notifications and setting thresholds for individual rules or entire intrusion policies can also can prevent the system from being overwhelmed with a large number of events. For more information, see Filtering Intrusion Event Notification Per Policy.

- In addition to the various views of intrusion events within the web interface, you can enable logging to syslog facilities or send event data to an SNMP trap server. Per policy, you can specify intrusion event notification limits, set up intrusion event notification to external logging facilities, and configure external responses to intrusion events. Note that in addition to these per-policy alerting configurations, you can globally enable or disable email alerting on intrusion events for each rule or rule group. Your email alert settings are used regardless of which intrusion policy processes a packet. For more information, see Configuring External Alerting for Intrusion Rules.

Limitations of Custom Policies

License: Protection

Because preprocessing and intrusion inspection are so closely related, you must be careful that your configuration allows the network analysis and intrusion policies processing and examining a single packet to complement each other.

By default, the system uses one network analysis policy to preprocess all traffic handled by managed devices using a single access control policy. The following diagram shows how a newly created access control policy in an inline, intrusion-prevention deployment initially handles traffic. The preprocessing and intrusion prevention phases are highlighted.

Notice how a default network analysis policy governs the preprocessing of all traffic handled by the access control policy. Initially, the system-provided Balanced Security and Connectivity network analysis policy is the default.

A simple way to tune preprocessing is to create and use a custom network analysis policy as the default, as summarized in Benefits of a Custom Network Analysis Policy. However, if you disable a preprocessor in a custom network analysis policy but the system needs to evaluate preprocessed packets against an enabled intrusion or preprocessor rule, the system automatically enables and uses the preprocessor although it remains disabled in the network analysis policy web interface.

Note In order to get the performance benefits of disabling a preprocessor, you must make sure that none of your intrusion policies have enabled rules that require that preprocessor.

An additional challenge arises if you use multiple custom network analysis policies. For advanced users with complex deployments, you can tailor preprocessing to specific security zones, networks, and VLANs by assigning custom network analysis policies to preprocess matching traffic. (Note that ASA FirePOWER devices cannot restrict preprocessing by VLAN.) To accomplish this, you add custom network analysis rules to your access control policy. Each rule has an associated network analysis policy that governs the preprocessing of traffic that matches the rule.

Tip You configure network analysis rules as an advanced setting in an access control policy. Unlike other types of rules in the FireSIGHT System, network analysis rules invoke—rather than being contained by—network analysis policies.

The system matches packets to any configured network analysis rules in top-down order by rule number. Traffic that does not match any network analysis rule is preprocessed by the default network analysis policy. While this allows you a great deal of flexibility in preprocessing traffic, keep in mind that all packets, regardless of which network analysis policy preprocessed them, are subsequently matched to access control rules—and thus to potential inspection by intrusion policies—in their own process. In other words, preprocessing a packet with a particular network analysis policy does not guarantee that the packet will be examined with any particular intrusion policy. You must carefully configure your access control policy so it invokes the correct network analysis and intrusion policies to evaluate a particular packet.

The following diagram shows in focused detail how the network analysis policy (preprocessing) selection phase occurs before and separately from the intrusion prevention (rules) phase. For simplicity, the diagram eliminates the discovery and file/malware inspection phases. It also highlights the default network analysis and default-action intrusion policies.

In this scenario, an access control policy is configured with two network analysis rules and a default network analysis policy:

- Network Analysis Rule A preprocesses matching traffic with Network Analysis Policy A. Later, you want this traffic to be inspected by Intrusion Policy A.

- Network Analysis Rule B preprocesses matching traffic with Network Analysis Policy B. Later, you want this traffic to be inspected by Intrusion Policy B.

- All remaining traffic is preprocessed with the default network analysis policy. Later, you want this traffic to be inspected by the intrusion policy associated with the access control policy’s default action.

After the system preprocesses traffic, it can examine the traffic for intrusions. The diagram shows an access control policy with two access control rules and a default action:

- Access Control Rule A allows matching traffic. The traffic is then inspected by Intrusion Policy A.

- Access Control Rule B allows matching traffic. The traffic is then inspected by Intrusion Policy B.

- The access control policy’s default action allows matching traffic. The traffic is then inspected by the default action’s intrusion policy.

Each packet’s handling is governed by a network analysis policy and intrusion policy pair, but the system does not coordinate the pair for you. Consider a scenario where you misconfigure your access control policy so that Network Analysis Rule A and Access Control Rule A do not process the same traffic. For example, you could intend the paired policies to govern the handling of traffic on a particular security zone, but you mistakenly use different zones in the two rules’ conditions. This could cause traffic to be incorrectly preprocessed. For this reason, tailoring preprocessing using network analysis rules and custom policies is an advanced task.

Note that for a single connection, although the system selects a network analysis policy before an access control rule, some preprocessing (notably application layer preprocessing) occurs after access control rule selection. This does not affect how you configure preprocessing in custom network analysis policies.

Using the Navigation Panel

License: Protection

Network analysis and intrusion policies use similar web interfaces to edit and save changes to their configurations; see:

- Editing Network Analysis Policies

- Editing Intrusion Policies

A dividing line separates the navigation panel into links to policy settings you can configure with (below) or without (above) direct interaction with policy layers. To navigate to any settings page, click its name in the navigation panel. Dark shading of an item in the navigation panel highlights your current settings page. For example, in the illustration above the Policy Information page would be displayed to the right of the navigation panel.

Policy Information

in the navigation panel when the policy contains unsaved changes. The icon disappears when you save your changes.

Rules (intrusion policy only)

The Rules page in an intrusion policy allows you to configure rule states and other settings for shared object rules, standard text rules, and preprocessor rules. For more information, see Tuning Intrusion Policies Using Rules.

FireSIGHT Recommendations (intrusion policy only)

The FireSIGHT Recommendations page in an intrusion policy allows you to associate the operating systems, servers, and client application protocols detected on your network with intrusion rules specifically written to protect those assets. This allows you to tailor your intrusion policy to the specific needs of your monitored network. For more information, see Tailoring Intrusion Protection to Your Network Assets.

Settings (network analysis policy) and Advanced Settings (intrusion policy)

The Settings page in a network analysis policy allows you to enable or disable preprocessors and access preprocessor configuration pages. Expanding the Settings link displays sublinks to individual configuration pages for all enabled preprocessors in the policy. For more information, see Configuring Preprocessors in a Network Analysis Policy.

The Advanced Settings page in an intrusion policy allows you to enable or disable advanced settings and access configuration pages for those advanced settings. Expanding the Advanced Settings link displays sublinks to individual configuration pages for all enabled advanced settings in the policy. For more information, see Configuring Advanced Settings in an Intrusion Policy.

Policy Layers

The Policy Layers page displays a summary of the layers that comprise your network analysis or intrusion policy. Expanding the Policy Layers link displays sublinks to summary pages for the layers in your policy. Expanding each layer sublink displays further sublinks to the configuration pages for all rules, preprocessors, or advanced settings that are enabled in the layer. For more information, see Using Layers in a Network Analysis or Intrusion Policy.

Resolving Conflicts and Committing Policy Changes

License: Protection

) your changes before the system recognizes them.

Note After you save, you must apply a network analysis or intrusion policy for your changes to take effect. If you apply a policy without saving, the system uses the most recently saved configuration. Although you can reapply an intrusion policy independently, network analysis policies are applied with their parent access control policy.

Resolving Editing Conflicts

The Network Analysis Policy page (Policies > Access Control, then click Network Analysis Policy) and Intrusion Policy page (Policies > Intrusion Policy > Intrusion Policy) display whether each policy has unsaved changes, as well as information about who is currently editing the policy. Cisco recommends that only one person edit a policy at a time. If you are performing simultaneous editing, the consequences are as follows:

- If you are editing a network analysis or intrusion policy at the same time another user is editing the same policy, and the other user saves their changes to the policy, you are warned when you commit the policy that you will overwrite the other user’s changes.

- If you are editing the same network analysis or intrusion policy via multiple web interface instances as the same user, and you save your changes for one instance, you cannot save your changes for the other instance.

Resolving Configuration Dependencies

To perform their particular analysis, many preprocessors and intrusion rules require that traffic first be decoded or preprocessed in a certain way, or have other dependencies. When you save a network analysis or intrusion policy, the system either automatically enables required settings, or warns you that disabled settings will have no effect on traffic, as follows:

- You cannot save an intrusion policy if you added an SNMP rule alert but did not configure SNMP alerting. You must either configure SNMP alerting or disable the rule alert, then save again.

- You cannot save an intrusion policy if it includes enabled sensitive data rules but you have not enabled the sensitive data preprocessor. You must either allow the system to enable the preprocessor and save the policy, or disable the rules and save again.

- If you disable a required preprocessor in a network analysis policy, you can still save the policy. However, the system automatically uses the disabled preprocessor with its current settings, even though the preprocessor remains disabled in the web interface. For more information, see Limitations of Custom Policies.

- If you disable inline mode in a network analysis policy but enable the Inline Normalization preprocessor, you can still save the policy. However, the system warns you that normalization settings will be ignored. Disabling inline mode also causes the system to ignore other settings that allow preprocessors to modify or block traffic, including checksum verification and rate-based attack prevention. For more information, see Allowing Preprocessors to Affect Traffic in Inline Deployments and Normalizing Inline Traffic.

Committing, Discarding, and Caching Policy Changes

While editing a network analysis or intrusion policy, if you exit the policy editor without saving your changes, the system caches those changes. Your changes are cached even when you log out of the system or experience a system crash. The system cache can store unsaved changes for one network analysis and one intrusion policy per user; you must commit or discard your changes before editing another policy of the same type. The system discards the cached changes when you edit another policy without saving your changes to the first policy, or when you import an intrusion rule update.

You can commit or discard policy changes on the Policy Information page of either the network analysis or intrusion policy editor; see Editing Network Analysis Policies and Editing Intrusion Policies.

Table 23-1 Committing Changes to a Network Analysis or Intrusion Policy

To...

On the Policy Information page, you can...

save changes to the policy

click Commit Changes.

Settings in the system policy govern whether you are prompted (or required) to comment on your network analysis or intrusion policy changes when you commit them. The system policy also governs whether changes and comments are recorded in the audit log. For more information, see Configuring Network Analysis Policy Preferences and Configuring Intrusion Policy Preferences.

discard all unsaved changes

click Discard Changes, then click OK to discard your changes and go to the Intrusion Policy page. If you do not want to discard your changes, click Cancel to return to the Policy Information page.

exit the policy, but cache changes

select any menu or other path to another page. On exiting, click Leave page when prompted, or click Stay on page to remain in the advanced editor.

Using Layers in a Network Analysis or Intrusion Policy

Larger organizations with many managed devices may have many intrusion policies and network analysis policies to support the unique needs of different departments, business units or, in some instances, different companies. Configurations in both policy types are contained in building blocks called layers, which you can use to efficiently manage multiple policies.

Layers in intrusion and network analysis policies work in essentially the same way. You can create and edit either policy type without consciously using layers. You can modify your policy configurations and, if you have not added user layers to your policy, the system automatically includes your changes in a single configurable layer that is initially named My Changes. Optionally, you can also add up to 200 layers where you can configure any combination of settings. You can copy, merge, move, and delete user layers and, most important, share individual user layers with other policies of the same type.

See the following sections for more information:

- Understanding the Layer Stack describes the user-configurable and built-in layers that comprise a basic policy.

- Managing Layers explains how to use layers in your policies.

Understanding the Layer Stack

License: Protection

A network analysis or intrusion policy where you do not add layers includes the built-in, read-only base policy layer and a single user-configurable layer that is initially named My Changes. You can copy, merge, move, or delete any user-configurable layer and set any user-configurable layer to be shared by other policies of the same type.

Each policy layer contains complete configurations for either all preprocessors in a network analysis policy or all intrusion rules and advanced settings in an intrusion policy. The lowest, base policy layer includes all the settings from the base policy you selected when you created the policy. A setting in a higher layer takes precedence over the same setting in a lower layer. Features not explicitly set in a layer inherit their settings from the next highest layer where they are explicitly set.

The system flattens the layers, that is, it applies only the cumulative effect of all settings, when it handles network traffic.

Tip You can create an intrusion or network analysis policy based solely on the default settings in the base policy and, optionally in the case of an intrusion policy, using FireSIGHT rule state recommendations.

Note the following points when working with multiple layers:

- When the highest layer in your policy is a read-only layer, or a shared layer as described in Sharing Layers Between Policies, the system automatically adds a user-configurable layer as the highest layer in your intrusion policy if you do either of the following:

– modify a rule action (that is, a rule state, event filtering, dynamic state, or alerting) on the intrusion policy Rules page. See Tuning Intrusion Policies Using Rules for more information.

– enable, disable, or modify any preprocessor, intrusion rule, or advanced setting.

All settings in the system-added layer are inherited except for the changes that resulted in the new layer.

- When the highest layer is a shared layer, the system adds a layer when you take either of the following actions:

– share the highest layer with other policies

– add a shared layer to your policy

- Regardless of whether you allow rule updates to modify your policy, changes in a rule update never override changes you make in a layer. This is because changes in a rule update are made in the base policy, which determines the default settings in your base policy layer; your changes are always made in a higher layer, so they override any changes that a rule update makes to your base policy. See Importing Rule Updates and Local Rule Files for more information.

See the following sections for more information:

- Understanding the Base Layer

- Understanding the FireSIGHT Recommendations Layer

Understanding the Base Layer

License: Protection

The base layer, also referred to as the base policy, of an intrusion or network analysis policy defines the default settings for all configurations in the policy, and is the lowest layer in the policy. When you create a new policy and change a setting without adding new layers, the change is stored in the My Changes layer, and overrides—but does not change—the setting in the base policy.

See the following sections for more information:

- Understanding System-Provided Base Policies

- Understanding Custom Base Policies

- Changing the Base Policy

- Allowing Rule Updates to Modify a System-Provided Base Policy

Understanding System-Provided Base Policies

License: Protection

Cisco delivers several pairs of network analysis and intrusion policies with the FireSIGHT System. By using system-provided network analysis and intrusion policies, you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states, as well as provides the initial configurations for preprocessors and other advanced settings. You can use these system-provided policies as-is, or you can use them as the base for custom policies.

If you use a system-provided policy as your base, importing rule updates may modify settings in your base policy. However, you can configure a custom policy to not automatically make these changes to its system-provided base policy. This allows you to update system-provided base policies manually, on a schedule independent of rule update imports. In either case, changes that a rule update makes to your base policy do not change or override settings in your My Changes or any other layer. For more information, see Allowing Rule Updates to Modify a System-Provided Base Policy.

System-provided intrusion and network analysis policies are similarly named but contain different configurations. For example, the Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. For more information, see Understanding the System-Provided Policies.

Understanding Custom Base Policies

License: Protection

If you do not want to use a system-provided policy as the base policy in your network analysis or intrusion policy, you can use a custom policy as your base. You can tune settings in custom policies to inspect traffic in ways that matter most to you so you can improve both the performance of your managed devices and your ability to respond effectively to the events they generate.

You can chain up to five custom policies, with four of the five using one of the other four previously created policies as its base policy; the fifth must use a system-provided policy as its base.

Changes you make to a custom policy that you use as the base for another policy are automatically used as the default settings the of policy that uses the base. Additionally, because all policies have a system-provided policy as the eventual base in a policy chain, importing a rule update may affect your policy even if you use a custom base policy. If the first custom policy in a chain (the one that uses the system-provided policy as its base) allows rule updates to modify its base policy, your policy may be affected. For information on changing this setting, see Allowing Rule Updates to Modify a System-Provided Base Policy.

Regardless of how they are made, changes to your base policy—whether by a rule update or when you modify a custom policy that you use as a base policy—do not change or override settings in your My Changes or any other layer.

Changing the Base Policy

License: Protection

You can select a different base policy for your network analysis or intrusion policy and, optionally, allow rule updates to modify a system-provided base policy, without affecting modifications in higher layers.

To change the base policy:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Information in the navigation panel.

The Policy Information page appears.

Step 2 Select a base policy from the Base Policy drop-down list.

Step 3 Optionally, if you choose a system-provided base policy, click Manage Base Policy to specify whether intrusion rule updates can automatically modify your base policy.

For more information, see Allowing Rule Updates to Modify a System-Provided Base Policy.

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Allowing Rule Updates to Modify a System-Provided Base Policy

License: Protection

Rule updates that you import provide system-provided policies with modified network analysis preprocessor settings, modified intrusion policy advanced settings, new and updated intrusion rules, and modified states for existing rules. Rule updates can also delete rules and provide new rule categories and default variables. See Importing Rule Updates and Local Rule Files for more information.

Rule updates always modify system-provided policies with any changes to preprocessors, advanced settings, and rules. Changes to default variables and rule categories are handled at the system level. See Understanding System-Provided Base Policies for more information.

When you use a system-provided policy as your base policy, you can allow rule updates to modify your base policy which, in this case, is a copy of the system-provided policy. If you allow rule updates to update your base policy, a new rule update makes the same changes in your base policy that it makes to the system-provided policy that you use as your base policy. If you have not modified the corresponding setting, a setting in your base policy determines the setting in your policy. However, rule updates do not override changes you make in your policy.

If you do not allow rule updates to update your base policy, you can manually update your base policy after importing one or more rule updates.

Rule updates always delete intrusion rules that VRT deletes, regardless of the rule state in your intrusion policy or whether you allow rule updates to update your base intrusion policy. Until you reapply your changes to network traffic, rules in your currently applied intrusion policies behave as follows:

- Disabled rules remain disabled.

- Rules set to Generate Events continue to generate events when triggered.

- Rules set to Drop and Generate Events continue to generate events and drop offending packets when triggered.

Rule updates do not modify a custom base policy unless both of the following conditions are met:

- You allow rule updates to modify the system-provided base policy of the parent policy, that is, the policy that originated the custom base policy.

- You have not made changes in the parent policy that override the corresponding settings in the parent’s base policy.

When both conditions are met, changes in the rule update are passed to the child policy, that is, the policy using the custom base policy, when you save the parent policy.

For example, if a rule update enables a previously disabled intrusion rule, and you have not modified the rule’s state in the parent intrusion policy, the modified rule state is passed to the base policy when you save the parent policy.

Likewise, if a rule update modifies a default preprocessor setting and you have not modified the setting in the parent network analysis policy, the modified setting is passed to the base policy when you save the parent policy.

See Changing the Base Policy for more information.

To allow rule updates to modify a system-provided base policy:

Access: Admin/Intrusion Admin

Step 1 While editing a policy that uses a system-provided policy as its base policy, click Policy Information in the navigation panel.

The Policy Information page appears.

Step 2 Click Manage Base Policy.

The Base Policy summary page appears.

Step 3 Select or clear the Update when a new Rule Update is installed check box.

When you save your policy with the check box cleared and then import a rule update, an Update Now button appears on the Base Policy summary page and the status message on the page updates to inform you that the policy is out of date. Optionally, you can click Update Now to update your base policy with the changes in the most recently imported rule update.

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Understanding the FireSIGHT Recommendations Layer

License: Protection

When you generate rule state recommendations in an intrusion policy, you can choose whether to automatically modify rule states based on the recommendations. See Tailoring Intrusion Protection to Your Network Assetsfor more information.

Note that this layer is unique to intrusion policies.

If you subsequently choose not to use recommended rule states, the system removes the FireSIGHT Recommendations layer. You cannot manually delete this layer, but you can add and remove it by choosing to use or not use recommended rule states.

Adding the FireSIGHT Recommendations layer adds a FireSIGHT Recommendations link under Policy Layers in the navigation panel. This link leads you to a read-only view of the FireSIGHT Recommendations layer page where you can access a recommendation-filtered view of the Rules page in read-only mode. See Tuning Intrusion Policies Using Rules for more information on working with rules on the Rules page.

Using recommended rule states also adds a Rules sublink beneath the FireSIGHT Recommendations link in the navigation panel. The Rules sublink provides access to a read-only display of the Rules page in the FireSIGHT Recommendations layer. Note the following in this view:

- When there is no rule state icon in the state column, the state is inherited from the base policy.

- When there is no rule state icon in the FireSIGHT Recommendations column in this or other Rules page views, there is no recommendation for this rule.

Tip When a rule state is not recommended, the rule’s overhead rating was higher than the setting for Recommendation Threshold (By Rule Overhead) when recommendations were generated. See Understanding Rule Overhead for more information.

Managing Layers

License: Protection

The Policy Layers page provides a single-page summary of the complete layer stack for your network analysis or intrusion policy. On this page you can add shared and unshared layers, copy, merge, move, and delete layers, access the summary page for each layer, and access configuration pages for enabled, disabled, and overridden configurations within each layer.

For each layer, you can view the following information:

- whether the layer is a built-in, shared user, or unshared user layer

- which layers contain the highest, that is the effective, preprocessor or advanced setting configurations, by feature name

- in an intrusion policy, the number of intrusion rules whose states are set in the layer, and the number of rules set to each rule state.

The feature name in the summary for each layer indicates which configurations are enabled, disabled, overridden, or inherited in the layer, as follows:

When the feature is...

The feature name is...

enabled in the layer

written in plain text

disabled in the layer

struck out

overridden by the configuration in a higher layer

written in italic text

inherited from a lower layer

not present

This page also provides a summary of the net effect of all enabled preprocessors (network analysis) or advanced settings (intrusion) and, for intrusion policies, intrusion rules.

The following table lists the actions available on the Policy Layers page.

See Sharing Layers Between Policies, Configuring Preprocessors and Advanced Settings in Layers, and Configuring Intrusion Rules in Layers for information on actions you can take on the summary page for a layer.

Table 24-1 Network Analysis and Intrusion Policy Layer Configuration Actions

To...

You can...

display the Policy Information page

click Policy Summary.

See Tuning Intrusion Policies Using Rules, Getting Started with Network Analysis Policies, and Getting Started with Intrusion Policies for information on the actions you can take on the Policy Information page.

display the summary page for a layer

) to access the read-only summary page for a shared layer.

access a layer-level preprocessor or advanced setting configuration page

click the feature name in the row for the layer. Note that configuration pages are read-only in the base policy and in shared layers. See Configuring Preprocessors and Advanced Settings in Layers for more information.

access a layer-level rule configuration page filtered by rule state type

) in the summary for the layer. No rules are displayed if the layer contains no rules set to the selected rule state.

add a layer to your policy

see Adding a Layer.

add a shared layer from another policy

see Sharing Layers Between Policies.

change a layer’s name or description

see Changing a Layer's Name and Description.

move, copy, or delete a layer

see Moving, Copying, and Deleting Layers.

merge a layer into the next layer beneath it

see Merging Layers.

To use the Policy Layers page:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers summary page appears.

Step 2 You can take any of the actions in the Network Analysis and Intrusion Policy Layer Configuration Actions table.

Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Adding a Layer

License: Protection

You can add up to 200 layers to a network analysis or intrusion policy. When you add a layer, it appears as the highest layer in your policy. The initial state is Inherit for all features and, in an intrusion policy, no event filtering, dynamic state, or alerting rule actions are set.

To add a layer to your network analysis or intrusion policy:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

) next to User Layers.

The Add Layer pop-up window appears.

Step 3 Type a unique layer Name and click OK.

The new layer appears as the topmost layer under User Layers.

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Changing a Layer's Name and Description

License: Protection

You can change the name of a user-configurable layer in your network analysis or intrusion policy and, optionally, add or modify a description that is visible when you edit the layer.

To change a layer’s name and add or modify its description:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

) next to the user layer you want to edit.

The summary page for the layer appears.

Step 3 You can take the following actions:

- Modify the layer Name .

- Add or modify the layer Description .

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Moving, Copying, and Deleting Layers

License: Protection

You can copy, move, or delete a user layer in your network analysis or intrusion policy, including the initial My Changes layer. Note the following considerations:

- When you copy a layer, the copy appears as the highest layer.

- Copying a shared layer creates an unshared copy which, optionally, you can then share with other policies.

- You cannot delete a shared layer; a layer with sharing enabled that you have not shared with another policy is not a shared layer.

To copy, move, or delete a layer:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

Step 2 You can take the following actions:

- To copy a layer, click the copy icon (

) for the layer you want to copy.

The page refreshes and a copy of the layer appears as the highest layer.

- To move a layer up or down within the User Layers page area, click any open area in the layer summary and drag until the position arrow (

) points to a line above or below a layer where you want to move the layer.

The screen refreshes and the layer appears in the new location.

- To delete a layer, click the delete icon (

) for the layer you want to delete, then click OK

The page refreshes and the layer is deleted.

Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Merging Layers

License: Protection

You can merge a user-configurable layer in your network analysis or intrusion policy with the next user layer beneath it. A merged layer retains all settings that were unique to either layer, and accepts the settings from the higher layer if both layers included settings for the same preprocessor, intrusion rule, or advanced setting. The merged layer retains the name of the lower layer.

In the policy where you create a shared layer that you add to other policies, you can merge an unshared layer immediately above the shared layer with the shared layer, but you cannot merge the shared layer with an unshared layer beneath it.

In a policy where you add a shared layer that you created in another policy, you can merge the shared layer into an unshared layer immediately beneath it and the resulting layer is no longer shared; you cannot merge an unshared layer into a shared layer beneath it.

To merge a user layer with a user layer beneath it:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

.

The page refreshes and the layer is merged with the layer beneath it.

Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Sharing Layers Between Policies

License: Protection

You can share a user-configurable layer with other policies of the same type (intrusion or network analysis). When you modify a configuration within a shared layer and then commit your changes, the system updates all policies that use the shared layer and provides you with a list of all affected policies. You can only modify shared layer feature configurations in the policy where you created the layer.

The master policy in the figure includes a company-wide layer with settings applicable to the policies at Site A and Site B. It also includes site-specific layers for each policy. For example, in the case of a network analysis policy Site A might not have web servers on the monitored network and would not require the protection or processing overhead of the HTTP Inspect preprocessor, but both sites would likely require TCP stream preprocessing. You could enable TCP stream processing in the company-wide layer that you share with both sites, disable the HTTP Inspect preprocessor in the site-specific layer that you share with Site A, and enable the HTTP Inspect preprocessor in the site-specific layer that you share with Site B. By editing configurations in a higher layer in the site-specific policies, you could also further tune the policy for each site if necessary with any configuration adjustments.

It is unlikely that the flattened net settings in the example master policy would be useful for monitoring traffic, but the time saved in configuring and updating the site-specific policies makes this a useful application of policy layers.

Many other layer configurations are possible. For example, you could define policy layers by company, by department, by network, or even by user. In the case of an intrusion policy, you could also include advanced settings in one layer and rule settings in another.

Tip You cannot add a shared layer to a policy when your base policy is a custom policy where the layer you want to share was created. When you attempt to save your changes, an error message indicates that the policy includes a circular dependency. See Understanding Custom Base Policies for more information.

To share a layer with other policies, you must do the following:

- Enable sharing on the layer summary page of the layer you want to share.

- Add the shared layer on the Policy Layers page of the policy where you want to share it.

You cannot disable sharing for a layer that is in use in another policy; you must first delete the layer from the other policy or delete the other policy.

To enable or disable sharing a layer with other policies:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

) next to the layer you want to share with other policies.

The summary page for the layer appears.

Step 3 Select (enable) or clear (disable) the Sharing check box.

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

To add a shared layer to your policy:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, click Policy Layers in the navigation panel.

The Policy Layers page appears.

) next to User Layers.

The Add Shared Layer pop-up window appears.

Step 3 Select the shared layer you want to add from the Add Shared Layer drop-down list, then click OK.

The Policy Layers summary page appears and the shared layer you selected appears as the highest layer in your policy.

If there are no shared layers in any other policies, no drop-down list appears; click OK or Cancel on the pop-up window to return to the Policy Layers summary page.

Step 4 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Configuring Intrusion Rules in Layers

License: Protection

In an intrusion policy, you can set the rule state, event filtering, dynamic state, alerting, and rule comments for a rule in any user-configurable layer. After accessing the layer where you want to make your changes, you add settings on the Rules page for the layer the same as you would on the intrusion policy Rules page; see Tuning Intrusion Policies Using Rules.

You can view individual layer settings on the Rules page for the layer, or view the net effect of all settings on the policy view of the Rules page. When you modify rule settings on the policy view of the Rules page, you are modifying the highest user-configurable layer in the policy. You can switch to another layer using the layer drop-down list on any Rules page.

The following table describes the effects of configuring the same type of setting in multiple layers.

Table 24-2 Layer Rule Settings

You can set...

Of this setting type...

To...

one

rule state

override a rule state set for the rule in a lower layer, and ignore all thresholds, suppressions, rate-based rule states, and alerts for that rule configured in lower layers. See Setting Rule States for more information.

If you want a rule to inherit its state from the base policy or a lower layer, set the rule state to Inherit. Note that when you are working on the intrusion policy Rules page, you cannot set a rule state to Inherit.

Note also that rule state settings are color-coded when you view them on the Rules page for a specific layer: rules whose effective state is set in a lower layer are highlighted in yellow; rules whose effective state is set in a higher layer are highlighted in red; rules whose effective state is set in the current layer are not highlighted. Because the intrusion policy Rules page is a composite view of the net effect of all rule settings, rule states are not color-coded on this page.

one

threshold

SNMP alert

override a setting of the same type for the rule in a lower layer. Note that setting a threshold overwrites any existing threshold for the rule in the layer. See Configuring Event Thresholding and Adding SNMP Alerts for more information.

one or more

suppression

rate-based rule state

cumulatively combine settings of the same type for each selected rule down to the first layer where a rule state is set for the rule. Settings below the layer where a rule state is set are ignored. See Configuring Suppression Per Intrusion Policy and Adding Dynamic Rule States for more information.

one or more

comment

add a comment to a rule. Comments are rule-specific, not policy- or layer-specific. You can add one or more comments to a rule in any layer. See Adding a Rule Comment for a Rule for more information.

For example, if you set a rule state to Drop and Generate Events in one layer and to Disabled in a higher layer, the intrusion policy Rules page shows that the rule is disabled.

In another example, if you set a source-based suppression for a rule to 192.168.1.1 in one layer, and you also set a destination-based suppression for the rule to 192.168.1.2 in another layer, the Rules page shows that the cumulative effect is to suppress events for the source address 192.168.1.1 and the destination address 192.168.1.2. Note that suppression and rate-based rule state settings cumulatively combine settings of the same type for each selected rule down to the first layer where a rule state is set for the rule. Settings below the layer where a rule state is set are ignored.

To modify rules in a layer:

Access: Admin/Intrusion Admin

Step 1 While editing your intrusion policy, expand Policy Layers in the navigation panel and expand the policy layer you want to modify.

Step 2 Click Rules immediately beneath the policy layer you want to modify.

The Rules page for the layer appears.

You can modify any of the settings in the Layer Rule Settings table. See Tuning Intrusion Policies Using Rules for more information on configuring intrusion rules.

To delete an individual setting from an editable layer, double-click the rule message on the Rules page for the layer to display rule details. Click Delete next to the setting you want to delete, then click OK twice.

Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Removing Multi-Layer Rule Settings

License: Protection

You can select one or more rules on the intrusion policy Rules page and then simultaneously remove a specific type of event filter, dynamic state, or alerting from multiple layers in your intrusion policy.

The system removes the setting type downward through each layer where it is set until it removes all the settings or encounters a layer where a rule state is set for the rule. If it encounters a layer where a rule state is set, it removes the setting from that layer and stops removing the setting type.

When the system encounters the setting type in a shared layer or in the base policy, and if the highest layer in the policy is editable, the system copies the remaining settings and rule state for the rule to that editable layer. Otherwise, if the highest layer in the policy is a shared layer, the system creates a new editable layer above the shared layer and copies the remaining settings and rule state for the rule to that editable layer.

Note Removing rule settings derived from a shared layer or the base policy causes any changes to this rule from lower layers or the base policy to be ignored. To stop ignoring changes from lower layers or the base policy, set the rule state to Inherit on the summary page for the topmost layer. See Setting Rule States for more information.

To remove rule settings in multiple layers:

Access: Admin/Intrusion Admin

Step 1 While editing your intrusion policy, click Rules immediately beneath Policy Information in the navigation panel.

Tip You can also select Policy from the layer drop-down list on the Rules page for any layer, or select Manage Rules on the Policy Information page.

The intrusion policy Rules page appears.

Step 2 Select the rule or rules from which you want to remove multiple settings. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

See Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy for information on locating rules.

Step 3 You have the following options:

- To remove all thresholds for a rule, select Event Filtering > Remove Thresholds .

- To remove all suppression for a rule, select Event Filtering > Remove Suppressions .

- To remove all rate-based rule states for a rule, select Dynamic State > Remove Rate-Based Rule States .

- To remove all SNMP alert settings for a rule, select Alerting > Remove SNMP Alerts .

A confirmation pop-up window appears.

Note Removing rule settings derived from a shared layer or the base policy causes any changes to this rule from lower layers or the base policy to be ignored. To stop ignoring changes from lower layers or the base policy, set the rule state to Inherit on the summary page for the topmost layer. See Setting Rule States for more information.

Step 4 Click OK.

The system removes the selected setting and copies the remaining settings for the rule to the highest editable layer in the policy. See the introduction to this procedure for conditions that affect how the system copies the remaining settings.

Step 5 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Accepting Rule Changes from a Custom Base Policy

License: Protection

When a custom network analysis or intrusion policy where you have not added layers uses another custom policy as its base policy, you must set a rule to inherit its rule state if:

- you delete an event filter, dynamic state, or SNMP alert set for the rule in the base policy, and

- you want the rule to accept subsequent changes that you make to it in the other custom policy that you use as your base policy

The following procedure explains how to accomplish this. See Removing Multi-Layer Rule Settings to accept settings for these rules in a policy where you have added layers.

To accept rule changes in a policy where you have not added layers:

Access: Admin/Intrusion Admin

Step 1 While editing your intrusion policy, expand the Policy Layers link in the navigation panel, then expand the My Changes link.

Step 2 Click the Rules link immediately beneath My Changes.

The Rules page for the My Changes layer appears.

Step 3 Select the rule or rules whose settings you want to accept. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

See Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy for information on locating rules.

Step 4 Select Inherit from the Rule State drop-down list.

Step 5 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Configuring Preprocessors and Advanced Settings in Layers

License: Protection

You use similar mechanisms to configure preprocessors in a network analysis policy and advanced settings in an intrusion policy. You can enable and disable preprocessors on the network analysis Settings page and intrusion policy advanced settings on the intrusion policy Advanced Settings page. These pages also provide summaries of the effective states for all relevant features. For example, if the network analysis SSL preprocessor is disabled in one layer and enabled in a higher layer, the Settings page shows it as enabled. Changes made on these pages appear in the top layer of the policy.

You can also enable or disable preprocessors or advanced settings and access their configuration pages on the summary page for a user-configurable layer. On this page you can modify the layer name and description and configure whether to share the layer with other policies of the same type; see Sharing Layers Between Policies for more information. You can switch to the summary page for another layer by selecting the layer name beneath Policy Layers in the navigation panel.

) appears next to the feature on the summary page for the layer; these disappear when you disable the feature in the layer or set it to Inherit.

Setting the state (enabled or disabled) for a preprocessor or advanced setting overrides the state and configuration settings for that feature in lower layers. If you want a preprocessor or advanced setting to inherit its state and configuration from the base policy or a lower layer, set it to Inherit. Note that the Inherit selection is not available when you are working in the Settings or Advanced Settings page.

Color-coding on each layer summary page indicates as follows whether the effective configuration is in a higher, lower, or the current layer:

- red - the effective configuration is in a higher layer

- yellow - the effective configuration is in a lower layer

- unshaded - the effective configuration is in the current layer

Because the Settings and Advanced Settings pages are composite views of all relevant settings, these page do not use color coding to indicate the positions of effective configurations.

The system uses the configuration in the highest layer where the feature is enabled. Unless you explicitly modify the configuration, the system uses the default configuration. For example, if you enable and modify the network analysis DCE/RPC preprocessor in one layer, and you also enable but do not modify it in a higher layer, the system uses the default configuration in the higher layer.

Note that the Back Orifice preprocessor has no user-configurable options.

Table 24-3 Layer Summary Page Actions

To...

You can...

modify the layer name or description

type a new value for Name or Description.

share the layer with other intrusion policies

select Allow this layer to be used by other policies.

See Sharing Layers Between Policies for more information.

enable or disable a preprocessor/advanced setting in the current layer

click Enabled or Disabled next to the feature.
) appears on the summary page next to the feature.
Disabling removes the sublink and edit icon.

inherit the preprocessor/advanced setting state and configuration from the settings in the highest layer below the current layer

click Inherit.

The page refreshes and, if the feature was enabled, the feature sublink in the navigation panel and the edit icon no longer appear.

access the configuration page for an enabled preprocessor/advanced setting

) or the feature sublink to modify the current configuration.

To modify preprocessors/advanced settings in a user layer:

Access: Admin/Intrusion Admin

Step 1 While editing your policy, expand Policy Layers in the navigation panel, then click the name of the layer you want to modify.

The summary page for the layer appears.

Step 2 You can take any of the actions in the Layer Summary Page Actions table.

Step 3 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Customizing Traffic Preprocessing

Many of the advanced settings in an access control policy govern intrusion detection and prevention configurations that require specific expertise to configure. Advanced settings typically require little or no modification and are not common to every deployment.

This chapter explains how to set the following preferences:

- Setting the Default Intrusion Policy for Access Control explains how to change the access control policy’s default intrusion policy, which is used to initially inspect traffic before the system can determine exactly how to inspect that traffic

- Customizing Preprocessing with Network Analysis Policies explains how to tailor certain traffic preprocessing options to specific security zones, networks, and VLANs by assigning custom network analysis policies to preprocess matching traffic.

Other chapters describe policy-wide preprocessing and performance options for access control policies. For more information, see:

- Configuring Advanced Transport/Network Settings

- Tuning Preprocessing in Passive Deployments

- Tuning Intrusion Prevention Performance

- Tuning File and Malware Inspection Performance and Storage

Setting the Default Intrusion Policy for Access Control

License: Any

Each access control policy uses its default intrusion policy to initially inspect traffic before the system can determine exactly how to inspect that traffic. This is needed because sometimes the system must process the first few packets in a connection, allowing them to pass, before it can decide which access control rule (if any) will handle the traffic. However, so that these packets do not reach their destination uninspected, you can use an intrusion policy—called the default intrusion policy—to inspect them and generate intrusion events.

A default intrusion policy is especially useful when performing application control and URL filtering, because the system cannot identify applications or filter URLs before a connection is fully established between the client and the server. For example, if a packet matches all the other conditions in an access control rule with an application or URL condition, it and subsequent packets are allowed to pass until the connection is established and application or URL identification is complete, usually 3 to 5 packets.

The system inspects these allowed packets with the default intrusion policy, which can generate events and, if placed inline, block malicious traffic. After the system identifies the access control rule or default action that should handle the connection, the remaining packets in the connection are handled and inspected accordingly.

When you create an access control policy, its default intrusion policy depends on the default action you first chose. Initial default intrusion policies for access control are as follows:

- Balanced Security and Connectivity (a system-provided policy) is the default intrusion policy for an access control policy where you first chose the Intrusion Prevention default action.

- No Rules Active is the default intrusion policy for an access control policy where you first chose the Block all traffic or Network Discovery default action. Although choosing this option disables intrusion inspection on the allowed packets described above, it can improve performance if you are not interested in intrusion data.

Note If you are not performing intrusion inspection (for example, in a discovery-only deployment where you are not licensed for Protection), keep the No Rules Active policy as your default intrusion policy. For more information, see IPS or Discovery-Only Performance Considerations.

Note that if you change your default action after you create the access control policy, the default intrusion policy does not automatically change. To change it manually, use the access control policy’s advanced options.

To change an access control policy’s default intrusion policy:

Access: Admin/Access Admin/Network Admin

) next to the Network Analysis and Intrusion Policies section.

The Network and Analysis Policies dialog box appears.

Step 2 From the Intrusion Policy used before Access Control rule is determined drop-down list, select a default intrusion policy. You can choose a system- or user-created policy.

) to edit the policy in a new window. You cannot edit system-provided policies.

Step 3 Choose the variable set matched with the selected policy.

). If you do not change the variable set, the system uses a default set. For more information, see Working with Variable Sets.

Step 4 Click OK to save your changes.

You must apply the access control policy for your changes to take effect.

Customizing Preprocessing with Network Analysis Policies

License: Any

Supported Devices: feature dependent

Network analysis policies govern how traffic is decoded and preprocessed so that it can be further evaluated, especially for anomalous traffic that might signal an intrusion attempt. This traffic preprocessing occurs after Security Intelligence blacklisting and traffic decryption, but before intrusion policies inspect packets in detail. By default, the system-provided Balanced Security and Connectivity network analysis policy applies to all traffic handled by an access control policy.

Tip The system-provided Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy governs mostly intrusion rules.

A simple way to tune preprocessing is to create and use a custom network analysis policy as the default; see Creating a Custom Network Analysis Policy. Tuning options available vary by preprocessor.

For advanced users with complex deployments, you can create multiple network analysis policies, each tailored to preprocess traffic differently. Then, you can configure the system to use those policies to govern the preprocessing of traffic using different security zones, networks, or VLANs. (Note that ASA FirePOWER devices cannot restrict preprocessing by VLAN.)

To accomplish this, you add custom network analysis rules to your access control policy. Each rule has:

- a set of rule conditions that identifies the specific traffic you want to preprocess

- an associated network analysis policy that you want to use to preprocess traffic that meets all the rules’ conditions

When it is time for the system to preprocess traffic, it matches packets to network analysis rules in top-down order by rule number. Traffic that does not match any network analysis rules is preprocessed by the default network analysis policy.

Note If you disable a preprocessor but the system needs to evaluate preprocessed packets against an enabled intrusion or preprocessor rule, the system automatically enables and uses the preprocessor although it remains disabled in the network analysis policy web interface. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. Because preprocessing and intrusion inspection are so closely related, you must be careful that you allow the network analysis and intrusion policies examining a single packet to complement each other. For more information, see Limitations of Custom Policies.

For more information, see the following sections:

- Setting the Default Network Analysis Policy for Access Control

- Specifying Traffic to Preprocess Using Network Analysis Rules

- Managing Network Analysis Rules

Setting the Default Network Analysis Policy for Access Control

License: Any

By default, the system-provided Balanced Security and Connectivity network analysis policy applies to all traffic handled by an access control policy. If you add network analysis rules to tailor traffic preprocessing options, the default network analysis policy preprocesses all traffic not handled by those rules.

An access control policy’s advanced settings allow you to change this default policy.

To change an access control policy’s default network analysis policy:

Access: Admin/Access Admin/Network Admin

) next to the Network Analysis and Intrusion Policies section.

The Network and Analysis Policies dialog box appears.

Step 2 From the Default Network Analysis Policy drop-down list, select a default network analysis policy. You can choose a system- or user-created policy.

) to edit the policy in a new window. You cannot edit system-provided policies.

Step 3 Click OK to save your changes,.

You must apply the access control policy for your changes to take effect.

Specifying Traffic to Preprocess Using Network Analysis Rules

License: Any

Supported Devices: feature dependent

Within your access control policy’s advanced settings, you can use network analysis rules to tailor preprocessing configurations to network traffic. Similar to access control rules, network analysis rules are numbered, starting at 1.

When it is time for the system to preprocess traffic, it matches packets to network analysis rules in top-down order by ascending rule number, and preprocesses traffic according to the first rule where all the rule’s conditions match. The conditions you can add to a rule are described in the following table.

Table 25-1 Network Analysis Rule Condition Types

This Condition...

Matches Traffic...

Details

Zones

entering or leaving a device via an interface in a specific security zone

A security zone is a logical grouping of one or more interfaces according to your deployment and security policies. Interfaces in a zone may be located across multiple devices. To build a zone condition, see Preprocessing Traffic Per Zone.

Networks

by its source or destination IP address, country, or continent

You can explicitly specify IP addresses. To build a network condition, see Preprocessing Traffic Per Network.

VLAN Tags

tagged by VLAN

The system uses the innermost VLAN tag to identify a packet by VLAN. Note that the ASA FirePOWER cannot restrict preprocessing by VLAN. To build a VLAN condition, see Preprocessing Traffic Per VLAN.

If you do not configure a particular condition for a rule, the system does not match traffic based on that criterion. For example, a rule with a network condition but no zone condition evaluates traffic based on its source or destination IP address, regardless of its ingress or egress interface. Traffic that does not match any network analysis rules is preprocessed by the default network analysis policy.

To add a custom network analysis rule:

Access: Admin/Access Admin/Network Admin

) next to the Intrusion and Network Analysis Policies section.

The Network and Analysis Policies dialog box appears. If you have not added any custom network analysis rules, the web interface indicates that you have No Custom Rules, otherwise it displays how many you have configured.

Tip Click Network Analysis Policy List to display the Network Analysis Policy page in a new window. Use this page to view and edit your custom network analysis policies; see Managing Network Analysis Policies

Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.

The dialog box expands to show the custom rules, if any.

Step 3 Click Add Rule.

The network analysis rule editor appears.

Step 4 Build your rule’s conditions. You can restrict NAP preprocessing using the following criteria:

- Preprocessing Traffic Per Zone

- Preprocessing Traffic Per Network

- Preprocessing Traffic Per VLAN

Step 5 Associate a network analysis policy with the rule by clicking the Network Analysis tab and choosing a policy from the Network Analysis Policy drop-down list.

) to edit the policy in a new window. You cannot edit system-provided policies.

Step 6 Click Add.

The rule is added after any other rules. To change the rule’s evaluation order, see Managing Network Analysis Rules.

Preprocessing Traffic Per Zone

License: Any

Zone conditions in network analysis rules allow you to preprocess traffic by its source and destination security zones. A security zone is a grouping of one or more interfaces, which may be located across multiple devices in a way that makes sense for your deployment and security policies. For more information on creating zones, see Working with Security Zones.

You can add a maximum of 50 zones to each of the Source Zones and Destination Zones in a single zone condition:

- To match traffic leaving the device from an interface in the zone, add that zone to Destination Zones . Note that because devices deployed passively do not transmit traffic, you cannot use a zone comprised of passive interfaces in a Destination Zone condition.

- To match traffic entering the device from an interface in the zone, add that zone to Source Zones .

If you add both source and destination zone conditions to a rule, matching traffic must originate from one of the specified source zones and egress through one of the destination zones.

Note that just as all interfaces in a zone must be of the same type (all inline, all passive, all switched, or all routed), all zones used in a zone condition for an network analysis rule must be of the same type. That is, you cannot write a single rule that matches traffic to or from zones of different types.

) indicate invalid configurations, such as zones that contain no interfaces. For details, hover your pointer over the icon.

To preprocess traffic by zone:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy where you want to preprocess traffic by zone, create a new network analysis rule or edit an existing rule.

For detailed instructions, see Specifying Traffic to Preprocess Using Network Analysis Rules.

Step 2 In the network analysis rule editor, select the Zones tab.

The Zones tab appears.

Step 3 Find and select the zones you want to add from the Available Zones.

To search for zones to add, click the Search by name prompt above the Available Zones list, then type a zone name. The list updates as you type to display matching zones.

Click to select a zone. To select multiple zones, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected zones to the appropriate list.

You can also drag and drop selected zones.

Step 5 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Preprocessing Traffic Per Network

License: Any

Network conditions in network analysis rules allow you to preprocess traffic by its source and destination IP address. You can manually specify the source and destination IP addresses for the traffic you want to preprocess, or you can configure network conditions with network objects, which are reusable and associate a name with one or more IP addresses and address blocks.

Tip After you create a network object, you can use it not only to build network analysis rules, but also to represent IP addresses in various other places in the system’s web interface. You can create these objects using the object manager; you can also create network objects on-the-fly while you are configuring network analysis rules. For more information, see Working with Network Objects.

You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single network condition:

- To match traffic from an IP address, configure Source Networks .

- To match traffic to an IP address, configure Destination Networks .

If you add both source and destination network conditions to a rule, matching traffic must originate from one of the specified IP addresses and be destined for one of the destination IP addresses.

) indicate invalid configurations. For details, hover your pointer over the icon.

To preprocess traffic by network:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy where you want to preprocess traffic by network, create a new network analysis rule or edit an existing rule.

For detailed instructions, see Specifying Traffic to Preprocess Using Network Analysis Rules.

Step 2 In the network analysis rule editor, select the Networks tab.

The Networks tab appears.

Step 3 Find and select the networks you want to add from the Available Networks, as follows:

- To add a network object on the fly, which you can then add to the condition, click the add icon (

) above the Available Networks list; see Working with Network Objects.

- To search for networks to add, click the Search by name or value prompt above the Available Networks list, then type an object name or the value of one of the object’s components. The list updates as you type to display matching objects.

To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All.

Step 4 Click Add to Source or Add to Destination to add the selected objects to the appropriate list.

You can also drag and drop selected objects.

Step 5 Add any source or destination IP addresses or address blocks that you want to specify manually.

Click the Enter an IP address prompt below the Source Networks or Destination Networks list; then type an IP address or address block and click Add.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Preprocessing Traffic Per VLAN

License: Any

Supported Devices: Any except ASA FirePOWER

VLAN conditions in network analysis rules allow you to control how VLAN-tagged traffic is preprocessed. The system uses the innermost VLAN tag to identify a packet by VLAN. Note that ASA FirePOWER devices cannot restrict preprocessing by VLAN.

When you build a VLAN-based network analysis condition, you can manually specify VLAN tags. Alternately, you can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one or more VLAN tags.

Tip After you create a VLAN tag object, you can use it not only to build network analysis rules, but also to represent VLAN tags in various other places in the system’s web interface. You can create VLAN tag objects either using the object manager or on-the-fly while you are configuring network analysis rules. For more information, see Working with VLAN Tag Objects.

) indicate invalid configurations. For details, hover your pointer over the icon.

To preprocess traffic by VLAN tag:

Access: Admin/Access Admin/Network Admin

Step 1 In the access control policy where you want to preprocess traffic by VLAN tag, create a new network analysis rule or edit an existing rule.

For detailed instructions, see Specifying Traffic to Preprocess Using Network Analysis Rules.

Step 2 In the network analysis rule editor, select the VLAN Tags tab.

The VLAN Tags tab appears.

Step 3 Find and select the VLANs you want to add from the Available VLAN Tags, as follows:

- To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon (

) above the Available VLAN Tags list; see Working with VLAN Tag Objects.

- To search for VLAN tag objects and groups to add, click the Search by name or value prompt above the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in the object. The list updates as you type to display matching objects.

- To select an object, click it. To select multiple objects, use the Shift and Ctrl keys, or right-click and then select Select All .

Step 4 Click Add to Rule or drag and drop to add the selected objects to the Selected VLAN Tags list.

Step 5 Add any VLAN tags that you want to specify manually.

Click the Enter a VLAN tag prompt below the Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag from 1 to 4094; use a hyphen to specify a range of VLAN tags.

Step 6 Save or continue editing the rule.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy on page 369.

Managing Network Analysis Rules

License: Any

A network analysis rule is simply a set of configurations and conditions that specifies how you preprocess traffic that matches those qualifications. You create and edit network analysis rules in the advanced options in an existing access control policy. Each rule belongs to only one policy.

To edit a custom network analysis rule:

Access: Admin/Access Admin/Network Admin

) next to the Intrusion and Network Analysis Policies section.

The Network and Analysis Policies dialog box appears. If you have not added any custom network analysis rules, the web interface indicates that you have No Custom Rules; otherwise, it displays how many you have configured.

Step 2 Next to Network Analysis Rules, click the statement that indicates how many custom rules you have.

The dialog box expands to show the custom rules, if any.

Step 3 Edit your custom rules. You have the following options:

- To edit a rule’s conditions, or change the network analysis policy invoked by the rule, click the edit icon (

) next to the rule.

- To change a rule’s order of evaluation, click and drag the rule to the correct location. To select multiple rules, use the Shift and Ctrl keys.

- To delete a rule, click the delete icon (

) next to the rule.

Tip Right-clicking a rule displays a context menu that allows you to cut, copy, paste, edit, and add new network analysis rules.

Step 4 Click OK to save your changes.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Getting Started with Network Analysis Policies

Network analysis policies govern many traffic preprocessing options, and are invoked by advanced settings in your access control policy. Network analysis-related preprocessing occurs after Security Intelligence blacklisting and SSL decryption, but before intrusion or file inspection begins.

By default, the system uses the Balanced Security and Connectivity network analysis policy to preprocess all traffic handled by an access control policy. However, you can choose a different default network analysis policy to perform this preprocessing. For your convenience, the system provides a choice of several non-modifiable network analysis policies, which are tuned for a specific balance of security and connectivity by the Cisco Vulnerability Research Team (VRT). You can also replace this default policy with a custom network analysis policy with custom preprocessing settings.

Tip System-provided intrusion and network analysis policies are similarly named but contain different configurations. For example, the Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy governs mostly intrusion rules. Understanding Network Analysis and Intrusion Policies provides an overview of how network analysis and intrusion policies work together to examine your traffic, as well as some basics on using the navigation panel, resolving conflicts, and committing changes.

You can also tailor traffic preprocessing options to specific security zones, networks, and VLANs by creating multiple custom network analysis policies, then assigning them to preprocess different traffic. (Note that ASA FirePOWER devices cannot restrict preprocessing by VLAN.)

Note Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. The system does not coordinate the policies for you. For more information, see Limitations of Custom Policies.

This chapter explains how to create a simple custom network analysis policy. This chapter also contains basic information on managing network analysis policies: editing, comparing, and so on. For more information, see:

- Creating a Custom Network Analysis Policy

- Managing Network Analysis Policies

- Allowing Preprocessors to Affect Traffic in Inline Deployments

- Generating a Report of Current Network Analysis Settings

- Comparing Two Network Analysis Policies or Revisions

Creating a Custom Network Analysis Policy

License: Protection

When you create a new network analysis policy you must give it a unique name, specify a base policy, and choose an inline mode.

The base policy defines the network analysis policy’s default settings. Modifying a setting in the new policy overrides—but does not change—the settings in the base policy. You can use either a system-provided or custom policy as your base policy. For more information, see Understanding the Base Layer.

The network analysis policy’s inline mode allows preprocessors to modify (normalize) and drop traffic to minimize the chances of attackers evading detection. Note that in passive deployments, the system cannot affect traffic flow regardless of the inline mode. For more information, see Allowing Preprocessors to Affect Traffic in Inline Deployments.

To create a network analysis policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

You can create and edit network analysis as well as intrusion policies if your FireSIGHT System user account’s role is restricted to Intrusion Policy or Modify Intrusion Policy. To access the Network Analysis Policy page, select Policies > Intrusion, then click Network Analysis Policy. For more information, see Managing Custom User Roles.

Step 2 Click Create Policy.

If you have unsaved changes in another policy, click Cancel when prompted to return to the Network Analysis Policy page. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Create Network Analysis Policy pop-up window appears.

Step 3 Give the policy a unique Name and, optionally, a Description.

Step 4 Specify the initial Base Policy.

You can use either a system-provided or custom policy as your base policy.

Step 5 Specify whether you want to allow preprocessors to affect traffic in an inline deployment:

- To allow preprocessors to affect traffic, enable Inline Mode .

- To prevent preprocessors from affecting traffic, disable Inline Mode .

Step 6 Create the policy:

- Click Create Policy to create the new policy and return to the Network Analysis Policy page. The new policy has the same settings as its base policy.

- Click Create and Edit Policy to create the policy and open it for editing in the advanced network analysis policy editor; see Editing Network Analysis Policies.

Managing Network Analysis Policies

License: Protection

On the Network Analysis Policy page (Policies > Access Control, then click Network Analysis Policy) you can view your current custom network analysis policies, along with the following information:

- the time and date the policy was last modified (in local time) and the user who modified it

- whether the Inline Mode setting is enabled, which allows preprocessors to affect traffic

- which access control policies and devices are using the network analysis policy to preprocess traffic

- whether a policy has unsaved changes, as well as information about who (if anyone) is currently editing the policy

In addition to custom policies that you create, the system provides two custom policies: Initial Inline Policy and Initial Passive Policy. These two network analysis policies use the Balanced Security and Connectivity network analysis policy as their base. The only difference between them is their inline mode, which allows preprocessors to affect traffic in the inline policy and disables it in the passive policy. You can edit and use these system-provided custom policies.

Options on the Network Analysis Policy page allow you to take the actions in the following table.

Table 26-1 Network Analysis Policy Management Actions

To...

You can...

See...

create a new network analysis policy

click Create Policy.

Creating a Custom Network Analysis Policy.

edit an existing network analysis policy

).

Editing Network Analysis Policies.

view a PDF report that lists the current configuration settings in a network analysis policy

).

Generating a Report of Current Network Analysis Settings

compare the settings of two network analysis policies or two revisions of the same policy

click Compare Policies.

Comparing Two Network Analysis Policies or Revisions.

delete a network analysis policy

), then confirm that you want to delete the policy. You cannot delete a network analysis policy if an access control policy references it.

Note that you can create and edit network analysis as well as intrusion policies if your FireSIGHT System user account’s role is restricted to Intrusion Policy or Modify Intrusion Policy. To access the Network Analysis Policy page, select Policies > Intrusion, then click Network Analysis Policy. For more information, see Managing Custom User Roles.

Editing Network Analysis Policies

License: Protection

Table 26-2 Network Analysis Policy Editing Actions

To...

You can...

See...

allow preprocessors to modify or drop traffic

select the Inline Mode check box on the Policy Information page.

Allowing Preprocessors to Affect Traffic in Inline Deployments

change the base policy

select a base policy from the Base Policy drop-down list on the Policy Information page.

Changing the Base Policy

view the settings in the base policy

click Manage Base Policy on the Policy Information page.

Understanding the Base Layer

enable, disable, or edit the settings for a preprocessor

click Settings in the navigation panel.

Configuring Preprocessors in a Network Analysis Policy

manage policy layers

click Policy Layers in the navigation panel.

Using Layers in a Network Analysis or Intrusion Policy

When tailoring a network analysis policy, especially when disabling preprocessors, keep in mind that some preprocessors and intrusion rules require that traffic first be decoded or preprocessed in a certain way. If you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Note Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. For more information, see Limitations of Custom Policies.

The system caches one network analysis policy per user. While editing a network analysis policy, if you select any menu or other path to another page, your changes stay in the system cache even if you leave the page. In addition to the actions you can perform in the table above, Understanding Network Analysis and Intrusion Policies provides information on using the navigation panel, resolving conflicts, and committing changes.

To edit a network analysis policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the network analysis policy you want to configure.

The network analysis policy editor appears, focused on the Policy Information page and with a navigation panel on the left.

Step 3 Edit your policy. Take any of the actions summarized above.

Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Allowing Preprocessors to Affect Traffic in Inline Deployments

License: Protection

In an inline deployment, some preprocessors can modify and block traffic. For example:

- The inline normalization preprocessor normalizes packets to prepare them for analysis by other preprocessors and the intrusion rules engine. You can also use the preprocessor’s Allow These TCP Options and Block Unrecoverable TCP Header Anomalies options to block certain packets. For more information, see Normalizing Inline Traffic.

- The system can drop packets with invalid checksums; see Verifying Checksums.

- The system can drop packets matching rate-based attack prevention settings; see Preventing Rate-Based Attacks.

For a preprocessor configured in the network analysis policy to affect traffic, you must enable and correctly configure the preprocessor, as well as correctly deploy managed devices inline, that is, with inline interface sets. Finally, you must enable the network analysis policy’s Inline Mode setting.

If you want to assess how your configuration would function in an inline deployment without actually modifying traffic, you can disable inline mode. In passive deployments or inline deployments in tap mode, the system cannot affect traffic regardless of the inline mode.

Note that disabling inline mode can affect intrusion event performance statistics graphs. With inline mode enabled in an inline deployment, the Intrusion Event Performance page (Overview > Summary > Intrusion Event Performance) displays graphs that represent normalized and blocked packets. If you disable inline mode, or in a passive deployment, many of the graphs display data about the traffic the system would have normalized or dropped. For more information, see Generating Intrusion Event Performance Statistics Graphs.

Tip In an inline deployment, Cisco recommends that you enable inline mode and configure the inline normalization preprocessor with the Normalize TCP Payload option enabled. In a passive deployment,Cisco recommends you configure adaptive profiles.

To allow preprocessors to affect traffic in an inline deployment:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

The Policy Information page appears.

Step 3 Specify whether you want to allow preprocessors to affect traffic:

- To allow preprocessors to affect traffic, enable Inline Mode .

- To prevent preprocessors from affecting traffic, disable Inline Mode .

Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Configuring Preprocessors in a Network Analysis Policy

License: Protection

Preprocessors prepare traffic to be further inspected by normalizing traffic and identifying protocol anomalies. Preprocessors can generate preprocessor events (see Reading Preprocessor Events) when packets trigger preprocessor options that you configure. The base policy for your network analysis policy determines which preprocessors are enabled by default and the default configuration for each.

When you select Settings in the navigation panel of a network analysis policy, the policy lists its preprocessors by type. On the Settings page, you can enable or disable preprocessors in your network analysis policy, as well as access preprocessor configuration pages.

A preprocessor must be enabled for you to configure it. When you enable a preprocessor, a sublink to the configuration page for the preprocessor appears beneath the Settings link in the navigation panel, and an Edit link to the configuration page appears next to the preprocessor on the Settings page.

Tip To revert a preprocessor’s configuration to the settings in the base policy, click Revert to Defaults on a preprocessor configuration page. When prompted, confirm that you want to revert.

When you disable a preprocessor, the sublink and Edit link no longer appear, but your configurations are retained. Note that to perform their particular analysis, many preprocessors and intrusion rules require that traffic first be decoded or preprocessed in a certain way. If you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Note In most cases, preprocessors require specific expertise to configure and typically require little or no modification. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. For more information, see Limitations of Custom Policies.

Modifying a preprocessor configuration requires an understanding of the configuration and its potential impact on your network. The following sections provide links to specific configuration details for each preprocessor.

Application Layer Preprocessors

Table 26-3 Application Layer Preprocessor Settings

For information on...

See...

DCE/RPC Configuration

Decoding DCE/RPC Traffic

DNS Configuration

Detecting Exploits in DNS Name Server Responses

FTP and Telnet Configuration

Decoding FTP and Telnet Traffic

HTTP Configuration

Decoding HTTP Traffic

Sun RPC Configuration

Using the Sun RPC Preprocessor

SIP Configuration

Decoding the Session Initiation Protocol

GTP Command Channel Configuration

Configuring the GTP Command Channel

IMAP Configuration

Decoding IMAP Traffic

POP Configuration

Decoding POP Traffic

SMTP Configuration

Decoding SMTP Traffic

SSH Configuration

Detecting Exploits Using the SSH Preprocessor

SSL Configuration

Using the SSL Preprocessor

SCADA Preprocessors

Table 26-4 SCADA Preprocessor Settings

For information on...

See...

Modbus Configuration

Configuring the Modbus Preprocessor

DNP3 Configuration

Configuring the DNP3 Preprocessor

Transport/Network Layer Preprocessors

Table 26-5 Transport and Network Layer Preprocessor Settings

For information on...

See...

Checksum Verification

Verifying Checksums

Inline Normalization

Normalizing Inline Traffic

IP Defragmentation

Defragmenting IP Packets

Packet Decoding

Understanding Packet Decoding

TCP Stream Configuration

Using TCP Stream Preprocessing

UDP Stream Configuration

Using UDP Stream Preprocessing

Note that some advanced transport and network preprocessor settings apply globally to all networks, zones, and VLANs where you apply your access control policy. You configure these advanced settings in an access control policy rather than in a network analysis policy; see Configuring Advanced Transport/Network Settings.

Specific Threat Detection

Table 26-6 Specific Threat Detection Settings

For information on...

See...

Back Orifice Detection

Detecting Back Orifice

Portscan Detection

Detecting Portscans

Rate-Based Attack Prevention

Preventing Rate-Based Attacks

Note that you configure the sensitive data preprocessor, which detects sensitive data such as credit card numbers and Social Security numbers in ASCII text, in intrusion policies. For more information, see Detecting Sensitive Data.

Generating a Report of Current Network Analysis Settings

License: Protection

A network analysis policy report is a record of the policy configuration at a specific point in time. The system combines the settings in the base policy with the settings of the policy layers, and makes no distinction between which settings originated in the base policy or policy layer.

Table 26-7 Network Analysis Policy Report Sections

Section

Description

Policy Information

Provides the name and description of the policy, the name of the user who last modified the policy, and the date and time the policy was last modified. Also indicates whether inline normalization can be enabled, the current rule update version, and whether the base policy is locked to the current rule update.

Settings

Lists all enabled preprocessor settings and their configurations.

You can also generate a comparison report that compares two network analysis policies, or two revisions of the same policy. For more information, see Comparing Two Network Analysis Policies or Revisions.

To view a network analysis policy report:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy for which you want to generate a report. Remember to commit any changes before you generate a network analysis policy report; only committed changes appear in the report.

The system generates the report. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Comparing Two Network Analysis Policies or Revisions

License: Protection

To review policy changes for compliance with your organization’s standards or to optimize system performance, you can examine the differences between two network analysis policies. You can compare any two network analysis policies or two revisions of the same network analysis policy. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies or policy revisions.

There are two tools you can use to compare network analysis policies or policy revisions:

- The comparison view displays only the differences between two network analysis policies or network analysis policy revisions in a side-by-side format; the name of each policy or policy revision appears in the title bar on the left and right sides of the comparison view.

You can use this to view and navigate both policy revisions on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two network analysis policies or network analysis policy revisions in a format similar to the network analysis policy report, but in PDF format.

You can use this to save, copy, print and share your policy comparisons for further examination.

For more information on understanding and using the policy comparison tools, see:

- Using the Network Analysis Policy Comparison View

- Using the Network Analysis Policy Comparison Report

Using the Network Analysis Policy Comparison View

License: Protection

The comparison view displays both policies or policy revisions in a side-by-side format, with each policy or policy revision identified by name in the title bar on the left and right sides of the comparison view. The time of last modification and the last user to modify are displayed with the policy name.

Differences between the two policies are highlighted:

- Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy but not the other.

You can perform any of the actions in the following table.

The window displays the name of the layer that contains the preprocessor configuration.

Table 26-8 Network Analysis Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

determine which layer contains the configuration for a specific preprocessor

) next to the configuration you want to view.

generate a new policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the Network Analysis Policy Comparison Report for more information.

generate a policy comparison report

click Comparison Report.

The policy comparison report creates a PDF document that lists only the differences between the two policies or policy revisions.

Using the Network Analysis Policy Comparison Report

License: Protection

A network analysis policy comparison report is a record of all differences between two network analysis policies or two revisions of the same network analysis policy identified by the network analysis policy comparison view, presented as a PDF. You can use this report to further examine the differences between two network analysis policy configurations and to save and disseminate your findings.

You can generate a network analysis policy comparison report from the comparison view for any policies to which you have access. Remember to save any changes before you generate a policy report; only saved changes appear in the report.

The format of the policy comparison report is the same as the policy report with one exception: the policy report contains all configurations in the policy, and the policy comparison report lists only those configurations that differ between the policies. A network analysis policy comparison report contains the sections described in Table 26-7.

Tip You can use a similar procedure to compare SSL, access control, intrusion, file, system, or health policies.

To compare two network analysis policies or policy revisions:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

The page refreshes and the Policy A and Policy B drop-down lists appear.

- To compare two revisions of the same policy, select Other Revision.

The page refreshes and the Policy, Revision A, and Revision B drop-down lists appear.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing two revision of the same policy, select the Policy, then select the timestamped revisions you want to compare from the Revision A and Revision B drop-down lists.

Step 5 Click OK to display the policy comparison view.

The comparison view appears.

Step 6 Optionally, click Comparison Report to generate the network analysis policy comparison report.

The network analysis policy comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Using Application Layer Preprocessors

You configure application layer preprocessors in a network analysis policy, which prepares traffic for inspection using the rules enabled in an intrusion policy. See Understanding Network Analysis and Intrusion Policies for more information.

Application-layer protocols can represent the same data in a variety of ways. Cisco provides application layer protocol decoders that normalize specific types of packet data into formats that the intrusion rules engine can analyze. Normalizing application-layer protocol encodings allows the rules engine to effectively apply the same content-related rules to packets whose data is represented differently and obtain meaningful results.

When an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses it with its current configuration even though it remains disabled in the network analysis policy’s web interface. For more information, see Limitations of Custom Policies.

Caution Some users with custom user roles cannot access the network analysis policy via the standard menu path ( Policies > Access Control > Network Analysis Policy). These users can access the network analysis policy through the intrusion policy: Policies > Intrusion > Intrusion Policy > Network Analysis Policy. For more information on custom user roles, see Managing Custom User Roles.

Note that preprocessors do not generate events in most cases unless you enable the accompanying preprocessor rules in an intrusion policy. See Setting Rule States for more information.

See the following sections for more information:

- Decoding DCE/RPC Traffic describes the DCE/RPC preprocessor and explains how to configure it to prevent evasion attempts and detect anomalies in DCE/RPC traffic.

- Detecting Exploits in DNS Name Server Responses describes the DNS preprocessor and explains how to configure it to detect any of three specific exploits in DNS name server responses.

- Decoding FTP and Telnet Traffic describes the FTP/Telnet decoder and explains how to configure it to normalize and decode FTP and Telnet traffic.

- Decoding HTTP Traffic describes the HTTP decoder and explains how to configure it to normalize HTTP traffic.

- Using the Sun RPC Preprocessor describes the RPC decoder and explains how to configure it to normalize RPC traffic.

- Decoding the Session Initiation Protocol explains how you can use the SIP preprocessor to decode and detect anomalies in SIP traffic.

- Configuring the GTP Command Channel explains how you can use the GTP preprocessor to provide the rules engine with GTP command channel messages extracted by the packet decoder.

- Decoding IMAP Traffic explains how you can use the IMAP preprocessor to decode and detect anomalies in IMAP traffic.

- Decoding POP Traffic explains how you can use the POP preprocessor to decode and detect anomalies in POP traffic.

- Decoding SMTP Traffic describes the SMTP decoder and explains how to configure it to decode and normalize SMTP traffic.

- Detecting Exploits Using the SSH Preprocessor explains how to identify and process exploits in SSH-encrypted traffic.

- Using the SSL Preprocessor explains how you can use the SSL preprocessor to identify encrypted traffic and eliminate false positives by stopping inspection of that traffic.

- Configuring SCADA Preprocessing explains how you can use the Modbus and DNP3 preprocessors to detect anomalies in corresponding traffic and provide data to the intrusion rules engine for inspection of certain protocol fields.

Decoding DCE/RPC Traffic

License: Protection

The DCE/RPC protocol allows processes on separate network hosts to communicate as if the processes were on the same host. These inter-process communications are commonly transported between hosts over TCP and UDP. Within the TCP transport, DCE/RPC might also be further encapsulated in the Windows Server Message Block (SMB) protocol or in Samba, an open-source SMB implementation used for inter-process communication in a mixed environment comprised of Windows and UNIX- or Linux-like operating systems. In addition, Windows IIS web servers on your network might use IIS RPC over HTTP, which provides distributed communication through a firewall, to proxy TCP-transported DCE/RPC traffic.

Note that descriptions of DCE/RPC preprocessor options and functionality include the Microsoft implementation of DCE/RPC known as MSRPC; descriptions of SMB options and functionality refer to both SMB and Samba.

Although most DCE/RPC exploits occur in DCE/RPC client requests targeted for DCE/RPC servers, which could be practically any host on your network that is running Windows or Samba, exploits can also occur in server responses. The DCE/RPC preprocessor detects DCE/RPC requests and responses encapsulated in TCP, UDP, and SMB transports, including TCP-transported DCE/RPC using version 1 RPC over HTTP. The preprocessor analyzes DCE/RPC data streams and detects anomalous behavior and evasion techniques in DCE/RPC traffic. It also analyzes SMB data streams and detects anomalous SMB behavior and evasion techniques.

The DCE/RPC preprocessor also desegments SMB and defragments DCE/RPC in addition to the IP defragmentation provided by the IP defragmentation preprocessor and the TCP stream reassembly provided by the TCP stream preprocessor. See Using TCP Stream Preprocessing and Defragmenting IP Packets.

Finally, the DCE/RPC preprocessor normalizes DCE/RPC traffic for processing by the rules engine. See DCE/RPC Keywords for information on using specific DCE/RPC rule keywords to detect DCE/RPC services, operations, and stub data.

You configure the DCE/RPC preprocessor by modifying any of the global options that control how the preprocessor functions, and by specifying one or more target-based server policies that identify the DCE/RPC servers on your network by IP address and by either the Windows or Samba version running on them.

You must enable DCE/RPC preprocessor rules, which have a generator ID (GID) of 132 or 133, if you want these rules to generate events. See Setting Rule States for more information.

See the following sections for more information:

- Selecting Global DCE/RPC Options

- Understanding Target-Based DCE/RPC Server Policies

- Understanding DCE/RPC Transports

- Selecting DCE/RPC Target-Based Policy Options

- Configuring the DCE/RPC Preprocessor

Selecting Global DCE/RPC Options

License: Protection

Global DCE/RPC preprocessor options control how the preprocessor functions. Except for the Memory Cap Reached option, modifying these options could have a negative impact on performance or detection capability. You should not modify them unless you have a thorough understanding of the preprocessor and the interaction between the preprocessor and enabled DCE/RPC rules. In particular, make sure that the Maximum Fragment Size option and Reassembly Threshold option are greater than or equal to the depth to which the rules need to detect. For more information, see Constraining Content Matches and Using Byte_Jump and Byte_Test.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Maximum Fragment Size

When Enable Defragmentation is selected, specifies the maximum DCE/RPC fragment length allowed from 1514 to 65535 bytes. The preprocessor truncates larger fragments for processing purposes to the specified size before defragmenting but does not alter the actual packet. A blank field disables this option.

Reassembly Threshold

When Enable Defragmentation is selected, 0 disables this option, or 1 to 65535 bytes specifies a minimum number of fragmented DCE/RPC bytes and, if applicable, segmented SMB bytes to queue before sending a reassembled packet to the rules engine. A low value increases the likelihood of early detection but could have a negative impact on performance. You should test for performance impact if you enable this option.

Enable Defragmentation

Specifies whether to defragment fragmented DCE/RPC traffic. When disabled, the preprocessor still detects anomalies and sends DCE/RPC data to the rules engine, but at the risk of missing exploits in fragmented DCE/RPC data.

Although this option provides the flexibility of not defragmenting DCE/RPC traffic, most DCE/RPC exploits attempt to take advantage of fragmentation to hide the exploit. Disabling this option would bypass most known exploits, resulting in a large number of false negatives.

Memory Cap Reached

Detects when the maximum memory limit allocated to the preprocessor is reached or exceeded. When the maximum memory cap is reached or exceeded, the preprocessor frees all pending data associated with the session that caused the memory cap event and ignores the rest of that session.

You can enable rule 133:1 to generate events for this option. See Setting Rule States for more information.

Auto-Detect Policy on SMB Session

Detects the Windows or Samba version that is identified in SMB Session Setup AndX requests and responses. When the detected version is different from the Windows or Samba version configured for the Policy configuration option, the detected version overrides the configured version for that session only. See Understanding Target-Based DCE/RPC Server Policies for more information.

For example, if you set Policy to Windows XP and the preprocessor detects Windows Vista, the preprocessor uses a Windows Vista policy for that session. Other settings remain in effect.

When the DCE/RPC transport is not SMB (that is, when the transport is TCP or UDP), the version cannot be detected and the policy cannot be automatically configured.

To enable this option, select one of the following from the drop-down list:

– Select Client to inspect server-to-client traffic for the policy type.

– Select Server to inspect client-to-server traffic for the policy type.

– Select Both to inspect server-to-client and client-to-server traffic for the policy type.

Understanding Target-Based DCE/RPC Server Policies

License: Protection

You can create one or more target-based server policies to configure the DCE/RPC preprocessor to inspect DCE/RPC traffic the same as a specified type of server would process it. Target-based policy configuration includes identifying the Windows or Samba version running on hosts you identify on your network, enabling transport protocols and specifying the ports carrying DCE/RPC traffic to those hosts, and setting other server-specific options.

Windows and Samba DCE/RPC implementations differ significantly. For example, all versions of Windows use the DCE/RPC context ID in the first fragment when defragmenting DCE/RPC traffic, and all versions of Samba use the context ID in the last fragment. As another example, Windows Vista uses the opnum (operation number) header field in the first fragment to identify a specific function call, and Samba and all other Windows versions use the opnum field in the last fragment.

There are also significant differences in Windows and Samba SMB implementations. For example, Windows recognizes the SMB OPEN and READ commands when working with named pipes, but Samba does not recognize these commands.

When you enable the DCE/RPC preprocessor, you automatically enable a default target-based policy. Optionally, you can add target-based policies that target other hosts running different Windows or Samba versions by selecting the correct version from the Policy drop-down list. The default target-based policy applies to any host not included in another target-based policy.

In each target-based policy, you can enable one or more transports and specify detection ports for each. You can also enable and specify auto-detection ports. See Understanding DCE/RPC Transports for more information.

You can also configure other target-based policy options. You can set the preprocessor to detect when there is an attempt to connect to one or more shared SMB resources that you identify. You can configure the preprocessor to detect files in SMB traffic, and to inspect a specified number of bytes in a detected file. You can also modify an advanced option that should be modified only by a user with SMB protocol expertise; this option lets you set the preprocessor to detect when a number of chained SMB AndX commands exceed a specified maximum number.

In each target-based policy, you can:

- enable one or more transports and specify detection ports for each.

- enable and specify auto-detection ports . See Understanding DCE/RPC Transports for more information.

- set the preprocessor to detect when there is an attempt to connect to one or more shared SMB resources that you identify.

- configure the preprocessor to detect files in SMB traffic, and to inspect a specified number of bytes in a detected file.

- modify an advanced option that should be modified only by a user with SMB protocol expertise; this option lets you set the preprocessor to detect when a number of chained SMB AndX commands exceed a specified maximum number.

Note that you can enable the Auto-Detect Policy on SMB Session global option to automatically override the policy type configured for a targeted policy on a per session basis when SMB is the DCE/RPC transport. See Auto-Detect Policy on SMB Session.

In addition to enabling SMB traffic file detection in the DCE/RPC preprocessor, you can configure a file policy to optionally capture and block these files, or submit them to the Collective Security Intelligence Cloud for dynamic analysis. Within that policy, you must create a file rule with an Action of Detect Files or Block Files and a selected Application Protocol of Any or NetBIOS-ssn (SMB). See Creating a File Policy and Working with File Rules for more information.

Understanding DCE/RPC Transports

License: Protection

In each target-based policy, you can enable one or more of the TCP, UDP, SMB, and RPC over HTTP transports. When you enable a transport, you must also specify one or more detection ports, that is, ports that are known to carry DCE/RPC traffic. Optionally, you can also enable and specify auto-detection ports, that is, ports that the preprocessor tests first to determine if they carry DCE/RPC traffic and continues processing only when it detects DCE/RPC traffic.

Cisco recommends that you use the default detection ports, which are either well-known ports or otherwise commonly-used ports for each protocol. You would add detection ports only if you detected DCE/RPC traffic on a non-default port.

When you enable auto-detection ports, ensure that they are set to the port range from 1024 to 65535 to cover the entire ephemeral port range. Note that it is unlikely that you would enable or specify auto-detection ports for the RPC over HTTP Proxy Auto-Detect Ports option or the SMB Auto-Detect Ports option because there is little likelihood that traffic for either would occur or even be possible except on the specified default detection ports. Note also that auto-detection occurs only for ports not already identified by transport detection ports. See Selecting DCE/RPC Target-Based Policy Options for recommendations for enabling or disabling auto-detection ports for each transport.

You can specify ports for one or more transports in any combination in a Windows target-based policy to match the traffic on your network, but you can only specify ports for the SMB transport in a Samba target-based policy.

Note that you must enable at least one DCE/RPC transport in the default target-based policy except when you have added a DCE/RPC target-based policy that has at least one transport enabled. For example, you might want to specify the hosts for all DCE/RPC implementations and not have the default target-based policy apply to unspecified hosts, in which case you would not enable a transport for the default target-based policy.

See the following sections for more information:

- Understanding Connectionless and Connection-Oriented DCE/RPC Traffic

- Understanding the RPC over HTTP Transport

Understanding Connectionless and Connection-Oriented DCE/RPC Traffic

License: Protection

DCE/RPC messages comply with one of two distinct DCE/RPC Protocol Data Unit (PDU) protocols:

- the connection-oriented DCE/RPC PDU protocol

The DCE/RPC preprocessor detects connection-oriented DCE/RPC in the TCP, SMB, and RPC over HTTP transports.

- the connectionless DCE/RPC PDU protocol

The DCE/RPC preprocessor detects connectionless DCE/RPC in the UDP transport.

The two DCE/RPC PDU protocols have their own unique headers and data characteristics. For example, the connection-oriented DCE/RPC header length is typically 24 bytes and the connectionless DCE/RPC header length is fixed at 80 bytes. Also, correct fragment order of fragmented connectionless DCE/RPC cannot be handled by a connectionless transport and, instead, must be ensured by connectionless DCE/RPC header values; in contrast, the transport protocol ensures correct fragment order for connection-oriented DCE/RPC. The DCE/RPC preprocessor uses these and other protocol-specific characteristics to monitor both protocols for anomalies and other evasion techniques, and to decode and defragment traffic before passing it to the rules engine.

Note the following in the figure:

- The well-known TCP or UDP port 135 identifies DCE/RPC traffic in the TCP and UDP transports.

- The figure does not include RPC over HTTP.

For RPC over HTTP, connection-oriented DCE/RPC is transported directly over TCP as shown in the figure after an initial setup sequence over HTTP. See Understanding the RPC over HTTP Transport for more information.

- The DCE/RPC preprocessor typically receives SMB traffic on the well-known TCP port 139 for the NetBIOS Session Service or the similarly implemented well-known Windows port 445.

Because SMB has many functions other than transporting DCE/RPC, the preprocessor first tests whether the SMB traffic is carrying DCE/RPC traffic, stops processing if it is not, and continues processing if it is.

- IP encapsulates all DCE/RPC transports.

- TCP transports all connection-oriented DCE/RPC.

- UDP transports connectionless DCE/RPC.

Understanding the RPC over HTTP Transport

License: Protection

The Microsoft IIS proxy server and the DCE/RPC server can be on the same host or on different hosts. Separate proxy and server options provide for both cases. Note the following in the figure:

- The DCE/RPC server monitors port 593 for DCE/RPC client traffic, but the firewall blocks port 593.

Firewalls typically block port 593 by default.

- RPC over HTTP transports DCE/RPC over HTTP using well-known HTTP port 80, which firewalls are likely to permit.

- Example 1 shows that you would select the RPC over HTTP proxy option to monitor traffic between the DCE/RPC client and the Microsoft IIS RPC proxy server.

- Example 2 shows that you would select the RPC over HTTP server option when the Microsoft IIS RPC proxy server and the DCE/RPC server are located on different hosts and the device monitors traffic between the two servers.

- Traffic is comprised solely of connection-oriented DCE/RPC over TCP after RPC over HTTP completes the proxied setup between the DCE/RPC client and server.

Selecting DCE/RPC Target-Based Policy Options

License: Protection

Each target-based policy allows you to specify the various options below. Note that, except for the Memory Cap Reached and Auto-Detect Policy on SMB Session options, modifying these options could have a negative impact on performance or detection capability. You should not modify them unless you have a thorough understanding of the preprocessor and the interaction between the preprocessor and enabled DCE/RPC rules.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Networks

The host IP addresses where you want to apply the DCE/RPC target-based server policy.

You can specify a single IP address or address block, or a comma-separated list of either or both. You can specify up to 255 total profiles including the default policy. For information on specifying IPv4 and IPv6 address blocks in the FireSIGHT System, see .

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Policy

The Windows or Samba DCE/RPC implementation used by the targeted host or hosts on your monitored network segment. See Understanding Target-Based DCE/RPC Server Policies for detailed information on these policies.

Note that you can enable the Auto-Detect Policy on SMB Session global option to automatically override the setting for this option on a per session basis when SMB is the DCE/RPC transport. See Auto-Detect Policy on SMB Session.

SMB Invalid Shares

A case-insensitive, alphanumeric text string that identifies one or more SMB shared resources; the preprocessor will detect when there is an attempt to connect to a shared resource that you specify. You can specify multiple shares in a comma-separated list and, optionally, you can enclose shares in quotes, which was required in previous software versions but is no longer required; for example:

"C$", D$, "admin", private

The preprocessor detects invalid shares in SMB traffic when you have enabled both SMB ports and SMB traffic detection.

Note that in most cases you should append a dollar sign to a drive named by Windows that you identify as an invalid share. For example, identify drive C as C$ or "C$".

You can enable rule 133:26 to generate events for this option. See Setting Rule States for more information.

SMB Maximum AndX Chain

The maximum number between 0 and 255 of chained SMB AndX commands to permit. Typically, more than a few chained AndX commands represent anomalous behavior and could indicate an evasion attempt. Specify 1 to permit no chained commands or 0 to disable detecting the number of chained commands.

Note that the preprocessor first counts the number of chained commands and generates an event if accompanying SMB preprocessor rules are enabled and the number of chained commands equals or exceeds the configured value. It then continues processing.

Note Only someone who is expert in the SMB protocol should modify the default setting for this option.

You can enable rule 133:20 to generate events for this option. See Setting Rule States for more information.

RPC proxy traffic only

When RPC over HTTP Proxy Ports is enabled, indicates whether detected client-side RPC over HTTP traffic is proxy traffic only or might include other web server traffic. For example, port 80 could carry both proxy and other web server traffic.

When this option is disabled, both proxy and other web server traffic are expected. Enable this option, for example, if the server is a dedicated proxy server. When enabled, the preprocessor tests traffic to determine if it carries DCE/RPC, ignores the traffic if it does not, and continues processing if it does. Note that enabling this option adds functionality only if the RPC over HTTP Proxy Ports check box is also enabled.

RPC over HTTP Proxy Ports

Enables detection of DCE/RPC traffic tunneled by RPC over HTTP over each specified port when your managed device is positioned between the DCE/RPC client and the Microsoft IIS RPC proxy server. See Understanding the RPC over HTTP Transport.

When enabled, you can add any ports where you see DCE/RPC traffic, although this is unlikely to be necessary because web servers typically use the default port for both DCE/RPC and other traffic. When enabled, you would not enable RPC over HTTP Proxy Auto-Detect Ports, but you would enable the RPC Proxy Traffic Only when detected client-side RPC over HTTP traffic is proxy traffic only and does not include other web server traffic.

RPC over HTTP Server Ports

Enables detection of DCE/RPC traffic tunneled by RPC over HTTP on each specified port when the Microsoft IIS RPC proxy server and the DCE/RPC server are located on different hosts and the device monitors traffic between the two servers. See Understanding the RPC over HTTP Transport.

Typically, when you enable this option you should also enable RPC over HTTP Server Auto-Detect Ports with a port range from 1025 to 65535 for that option even if you are not aware of any proxy web servers on your network. Note that the RPC over HTTP server port is sometimes reconfigured, in which case you should add the reconfigured server port to port list for this option.

TCP Ports

Enables detection of DCE/RPC traffic in TCP on each specified port.

Legitimate DCE/RPC traffic and exploits might use a wide variety of ports, and other ports above port 1024 are common. Typically, when this option is enabled you should also enable TCP Auto-Detect Ports with a port range from 1025 to 65535 for that option.

UDP Ports

Enables detection of DCE/RPC traffic in UDP on each specified port.

Legitimate DCE/RPC traffic and exploits might use a wide variety of ports, and other ports above port 1024 are common. Typically, when this option is enabled you should also enable UDP Auto-Detect Ports with a port range from 1025 to 65535 for that option.

SMB Ports

Enables detection of DCE/RPC traffic in SMB on each specified port.

You could encounter SMB traffic using the default detection ports. Other ports are rare. Typically, use the default settings.

RPC over HTTP Proxy Auto-Detect Ports

Enables auto-detection of DCE/RPC traffic tunneled by RPC over HTTP on the specified ports when your managed device is positioned between the DCE/RPC client and the Microsoft IIS RPC proxy server. See Understanding the RPC over HTTP Transport.

When enabled, you would typically specify a port range from 1025 to 65535 to cover the entire range of ephemeral ports.

RPC over HTTP Server Auto-Detect Ports

Enables auto-detection of DCE/RPC traffic tunneled by RPC over HTTP on the specified ports when the Microsoft IIS RPC proxy server and the DCE/RPC server are located on different hosts and the device monitors traffic between the two servers. See Understanding the RPC over HTTP Transport.

TCP Auto-Detect Ports

Enables auto-detection of DCE/RPC traffic in TCP on the specified ports.

UDP Auto-Detect Ports

Enables auto-detection of DCE/RPC traffic in UDP on each specified port.

SMB Auto-Detect Ports

Enables auto-detection of DCE/RPC traffic in SMB.

SMB File Inspection

Enables inspection of SMB traffic for file detection. You have the following options:

– Select Off to disable file inspection.

– Select Only to inspect file data without inspecting the DCE/RPC traffic in SMB. Selecting this option can improve performance over inspecting both files and DCE/RPC traffic.

– Select On to inspect both files and the DCE/RPC traffic in SMB. Selecting this option can impact performance.

Inspection of SMB traffic for the following is not supported:

– files transferred in SMB 2.x and SMB 3.x

– files transferred in an established TCP or SMB session before this option is enabled and the policy applied

– files transferred concurrently in a single TCP or SMB session

– files transferred across multiple TCP or SMB sessions

– files transferred with non-contiguous data, such as when message signing is negotiated

– files transferred with different data at the same offset, overlapping the data

– files opened on a remote client for editing that the client saves to the file server

SMB File Inspection Depth

If SMB File Inspection is set to Only or On, the number of bytes inspected when a file is detected in SMB traffic. Specify one of the following:

– an integer from 1 to 2147483647 (about 2GB)

– 0 to inspect the entire file

– -1 to disable file inspection

Enter a value in this field equal to or smaller than the one defined in your access control policy. If you set a value for this option larger than the one defined for Limit the number of bytes inspected when doing file type detection, the system uses the access control policy setting as the functional maximum.See Tuning File and Malware Inspection Performance and Storage for more information.

If SMB File Inspection is set to Off, this field is disabled.

Configuring the DCE/RPC Preprocessor

License: Protection

You can configure DCE/RPC preprocessor global options and one or more target-based server policies.

The preprocessor does not generate events unless you enable rules with generator ID (GID) 133. See Selecting Global DCE/RPC Options and Selecting DCE/RPC Target-Based Policy Options for rules associated with specific detection options; see also Setting Rule States.

In addition, most DCE/RPC preprocessor rules generate events against anomalies and evasion techniques detected in SMB, connection-oriented DCE/RPC, or connectionless DCE/RPC traffic. The following table identifies the rules that you can enable for each type of traffic.

Table 27-1 Traffic-Associated DCE/RPC Rules

Traffic

Preprocessor Rule GID:SID

SMB

133:2 through 133:26, and 133:48 through 133:57

Connection-Oriented DCE/RPC

133:27 through 133:39

Detect Connectionless DCE/RPC

133:40 through 133:43

To configure the DCE/RPC preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether DCE/RPC Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The DCE/RPC Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can modify any of the options described in Selecting Global DCE/RPC Options.

Step 6 You have two options:

- Add a new target-based policy. Click the add icon (

) next to Servers on the left side of the page. The Add Target pop-up window appears. Specify a one or more IP addresses in the Server Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

You can configure up to 255 policies, including the default policy.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of servers on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the profile you added.

- Modify the settings for an existing target-based policy. Click the configured address for a policy you have added under Servers on the left side of the page, or click default .

) next to the policy you want to remove.

Step 7 You can modify any of the following target-based policy options:

- To specify the host or hosts where you want to apply the DCE/RPC target-based server policy, enter a single IP address or address block, or a comma-separated list of either or both in the Networks field.

You can specify up to 255 total profiles including the default policy. Note that you cannot modify the setting for Networks in the default policy. The default policy applies to all servers on your network that are not identified in another policy.

- To specify the type of policy you want to apply to the specified host or hosts on your network segment, select one of the Windows or Samba policy types from the Policy drop-down list.

Note that you can enable the Auto-Detect Policy on SMB Session global option to automatically override the setting for this option on a per session basis when SMB is the DCE/RPC transport. See Auto-Detect Policy on SMB Session.

- To set the preprocessor to detect when there is an attempt to connect to specified shared SMB resources, enter a single or comma-separated list of the case-insensitive strings that identify the shared resources in the SMB Invalid Shares field. Optionally, enclose individual strings in quotes, which was required in previous software versions but is no longer required.

For example, to detect shared resources named C$, D$, admin, and private, you could enter:

"C$", D$, "admin", private

Note that to detect SMB invalid shares, you must also enable SMB Ports or SMB Auto-Detect Ports, and enable the global SMB Traffics option.

Note also that in most cases you should append a dollar sign to a drive named by Windows that you identify as an invalid share. For example, you would enter C$ or "C$" to identify drive C.

- To inspect files detected in DCE/RPC traffic in SMB without analyzing the DCE/RPC traffic, from the SMB File Inspection drop-down list, select Only . To inspect files detected in DCE/RPC traffic in SMB as well as the DCE/RPC traffic, from the SMB File Inspection drop-down list, select On . Enter a number of bytes to inspect in a detected file in the SMB File Inspection Depth field. Enter 0 to inspect detected files in their entirety.

- To specify a maximum number of chained SMB AndX commands to permit, enter 0 to 255 in the SMB Maximum AndX Chains field. Specify 1 to permit no chained commands. Specify 0 or leave this option blank to disable this feature.

Note Only someone who is expert in the SMB protocol should modify the setting for the SMB Maximum AndX Chains option.

- To enable the processing of DCE/RPC traffic over ports known to carry DCE/RPC traffic for a Windows policy transport, select or clear the check box next to a detection transport and, optionally, add or delete ports for the transport.

Select one or any combination of RPC over HTTP Proxy Ports, RPC over HTTP Server Ports, TCP Ports, and UDP Ports for a Windows policy. Select RPC Proxy Traffic Only when RPC over HTTP proxy is enabled and detected client-side RPC over HTTP traffic is proxy traffic only; that is, when it does not include other web server traffic.

Select SMB Ports for a Samba policy.

In most cases, use the default settings. See Understanding DCE/RPC Transports, Understanding the RPC over HTTP Transport, and Selecting DCE/RPC Target-Based Policy Options for more information.

You can type a single port, a range of port numbers separated by a dash (-), or a comma-separated list of port numbers and ranges.

- To test whether specified ports carry DCE/RPC traffic and continue processing when they do, select or clear the check box next to an auto-detection transport and, optionally, add or delete ports for the transport.

Select one or any combination of RPC over HTTP Server Auto-Detect Ports, TCP Auto-Detect Ports, and UDP Auto-Detect Ports for a Windows policy.

Note that you would rarely, if ever, select RPC over HTTP Proxy Auto-Detect Ports or SMB Auto-Detect Ports.

Typically, specify a port range from 1025 to 65535 for auto-detection ports that you enable to cover the entire range of ephemeral ports. See Understanding DCE/RPC Transports, Understanding the RPC over HTTP Transport, and Selecting DCE/RPC Target-Based Policy Options for more information.

See Selecting DCE/RPC Target-Based Policy Options for more information.

Step 8 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Detecting Exploits in DNS Name Server Responses

License: Protection

The DNS preprocessor inspects DNS name server responses for the following specific exploits:

- Overflow attempts on RData text fields

- Obsolete DNS resource record types

- Experimental DNS resource record types

See the following sections for more information:

- Understanding DNS Preprocessor Resource Record Inspection

- Detecting Overflow Attempts in RData Text Fields

- Detecting Obsolete DNS Resource Record Types

- Detecting Experimental DNS Resource Record Types

- Configuring the DNS Preprocessor

Understanding DNS Preprocessor Resource Record Inspection

License: Protection

The most common type of DNS name server response provides one or more IP addresses that correspond to domain names in the query that prompted the response. Other types of server responses provide, for example, the destination for an email message or the location of a name server that can provide information not available from the server originally queried.

A DNS response is comprised of a message header, a Question section that contains one or more requests, and three sections that respond to requests in the Question section (Answer, Authority, and Additional Information). Responses in these three sections reflect the information in resource records (RR) maintained on the name server. The following table describes these three sections.

Table 27-2 DNS Name Server RR Responses

This section...

Includes...

For example...

Answer

Optionally, one or more resource records that provide a specific answer to a query

The IP address corresponding to a domain name

Authority

Optionally, one or more resource records that point to an authoritative name server

The name of an authoritative name server for the response

Additional Information

Optionally, one or more resource records that provided additional information related to the Answer sections

The IP address of another server to query

Theoretically, any type of resource record can be used in the Answer, Authority, or Additional Information section of a name server response message. The DNS preprocessor inspects any resource record in each of the three response sections for the exploits it detects.

The Type and RData resource record fields are of particular importance to the DNS preprocessor. The Type field identifies the type of resource record. The RData (resource data) field provides the response content. The size and content of the RData field differs depending on the type of resource record.

DNS messages typically use the UDP transport protocol but also use TCP when the message type requires reliable delivery or the message size exceeds UDP capabilities. The DNS preprocessor inspects DNS server responses in both UDP and TCP traffic.

The DNS preprocessor does not inspect TCP sessions picked up in midstream, and ceases inspection if a session loses state because of dropped packets.

The typical port to configure for the DNS preprocessor is well-known port 53, which DNS name servers use for DNS messages in both UDP and TCP.

Detecting Overflow Attempts in RData Text Fields

License: Protection

When the resource record type is TXT (text), the RData field is a variable-length ASCII text field.

When selected, the DNS preprocessor Detect Overflow attempts on RData Text fields option detects a specific vulnerability identified by entry CVE-2006-3441 in MITRE’s Current Vulnerabilities and Exposures database. This is a known vulnerability in Microsoft Windows 2000 Service Pack 4, Windows XP Service Pack 1 and Service Pack 2, and Windows Server 2003 Service Pack 1. An attacker can exploit this vulnerability and take complete control of a host by sending or otherwise causing the host to receive a maliciously crafted name server response that causes a miscalculation in the length of an RData text field, resulting in a buffer overflow.

You should enable this feature when your network might include hosts running operating systems that have not been upgraded to correct this vulnerability.

You can enable rule 131:3 to generate events for this option. See Setting Rule States for more information.

Detecting Obsolete DNS Resource Record Types

License: Protection

RFC 1035 identifies several resource record types as obsolete. Because these are obsolete record types, some systems do not account for them and may be open to exploits. You would not expect to encounter these record types in normal DNS responses unless you have purposely configured your network to include them.

Table 27-3 Obsolete DNS Resource Record Types

RR Type

Code

Description

3

MD

a mail destination

4

MF

a mail forwarder

You can enable rule 131:1 to generate events for this option. See Setting Rule States for more information.

Detecting Experimental DNS Resource Record Types

License: Protection

RFC 1035 identifies several resource record types as experimental. Because these are experimental record types, some systems do not account for them and may be open to exploits. You would not expect to encounter these record types in normal DNS responses unless you have purposely configured your network to include them.

Table 27-4 Experimental DNS Resource Record Types

RR Type

Code

Description

7

MB

a mailbox domain name

8

MG

a mail group member

9

MR

a mail rename domain name

10

NUL

a null resource record

You can enable rule 131:2 to generate events for this option. See Setting Rule States for more information.

Configuring the DNS Preprocessor

License: Protection

Use the following procedure to configure the DNS preprocessor. For more information on configuring the options on this page, see Detecting Overflow Attempts in RData Text Fields, Detecting Obsolete DNS Resource Record Types, and Detecting Experimental DNS Resource Record Types.

To configure the DNS preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether DNS Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The DNS Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, you can modify any of the following in the Settings area:

- Specify the source port or ports the DNS preprocessor should monitor for DNS server responses in the Ports field. Separate multiple ports with commas.

- Select the Detect Overflow Attempts on RData Text fields check box to enable detection of buffer overflow attempts in RData text fields.

- Select the Detect Obsolete DNS RR Types check box to enable detection of obsolete resource record types.

- Select the Detect Experimental DNS RR Types check box to detect experimental resource record types.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Decoding FTP and Telnet Traffic

License: Protection

The FTP/Telnet decoder analyzes FTP and telnet data streams, normalizing FTP and telnet commands before processing by the rules engine.

You must enable FTP and telnet preprocessor rules, which have generator IDs (GIDs) of 125 and 126, if you want these rules to generate events. See Setting Rule States for more information.

For more information, see the following topics:

- Understanding Global FTP and Telnet Options

- Configuring Global FTP/Telnet Options

- Understanding Telnet Options

- Configuring Telnet Options

- Understanding Server-Level FTP Options

- Configuring Server-Level FTP Options

- Understanding Client-Level FTP Options

- Configuring Client-Level FTP Options

Understanding Global FTP and Telnet Options

License: Protection

You can set global options to determine whether the FTP/Telnet decoder performs stateful or stateless inspection of packets, whether the decoder detects encrypted FTP or telnet sessions, and whether the decoder continues to check a data stream after it encounters encrypted data.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Stateful Inspection

When selected, causes the FTP/Telnet decoder to save state and provide session context for individual packets and only inspects reassembled sessions. When cleared, analyzes each individual packet without session context.

To check for FTP data transfers, this option must be selected.

Detect Encrypted Traffic

Detects encrypted telnet and FTP sessions.

You can enable rules 125:7 and 126:2 to generate events for this option. See Setting Rule States for more information.

Continue to Inspect Encrypted Data

Instructs the preprocessor to continue checking a data stream after it is encrypted, looking for eventual decrypted data.

Configuring Global FTP/Telnet Options

License: Protection

You need to configure global options for the FTP/Telnet decoder to control whether stateless or stateful inspection is performed, encrypted traffic is detected, and whether the decoder should continue to check for decrypted data in a data stream that it has identified as encrypted. For more information on global settings, see Understanding Global FTP and Telnet Options.

To configure global options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The FTP and Telnet Configuration page appears.

A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Tip For more information on configuring the other options on this page, see Configuring Telnet Options, Configuring Server-Level FTP Options, and Configuring Client-Level FTP Options.

Step 5 Optionally, you can modify any of the following in the Global Settings page area:

- Select Stateful Inspection to examine reassembled TCP streams containing FTP packets. Clear Stateful Inspection to inspect only unreassembled packets.

- Select Detect Encrypted Traffic to detect encrypted traffic. Clear Detect Encrypted Traffic to ignore encrypted traffic.

- If needed, select Continue to Inspect Encrypted Data to continue checking a stream after it becomes encrypted, in case it becomes decrypted again and can be processed.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Telnet Options

License: Protection

You can enable or disable normalization of telnet commands by the FTP/Telnet decoder, enable or disable a specific anomaly case, and set the threshold number of Are You There (AYT) attacks to permit.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Ports

Indicates the ports whose telnet traffic you want to normalize. In the interface, list multiple ports separated by commas.

Normalize

Normalizes telnet traffic to the specified ports.

Detect Anomalies

Enables detection of Telnet SB (subnegotiation begin) without the corresponding SE (subnegotiation end).

Telnet supports subnegotiation, which begins with SB (subnegotiation begin) and must end with an SE (subnegotiation end). However, certain implementations of Telnet servers will ignore the SB without a corresponding SE. This is anomalous behavior that could be an evasion case. Because FTP uses the Telnet protocol on the control connection, it is also susceptible to this behavior.

You can enable rule 126:3 to generate an event when this anomaly is detected in Telnet traffic, and rule 125:9 when it is detected on the FTP command channel. See Setting Rule States for more information.

Are You There Attack Threshold Number

Detects when the number of consecutive AYT commands exceeds the specified threshold. Cisco recommends that you set the AYT threshold to a value no higher than 20.

You can enable rule 126:1 to generate events for this option. See Setting Rule States for more information.

Configuring Telnet Options

License: Protection

You can enable or disable normalization, enable or disable a specific anomaly case, and control the threshold number of Are You There (AYT) attacks to permit. For additional information on telnet options, see Understanding Telnet Options.

To configure telnet options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The FTP and Telnet Configuration page appears.

A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Tip For more information on configuring the other options on this page, see Configuring Global FTP/Telnet Options, Configuring Server-Level FTP Options, and Configuring Client-Level FTP Options.

Step 5 Optionally, you can modify any of the following in the Telnet Settings page area:

- Specify the port or ports where telnet traffic should be decoded in the Ports field. Telnet typically connects to TCP port 23. Separate multiple ports with commas.

Caution Because encrypted traffic (SSL) cannot be decoded, adding port 22 (SSH) could yield unexpected results.

- Select or clear the Normalize Telnet Protocol Options check box to enable or disable telnet normalization.

- Select or clear the Detect Anomalies Telnet Protocol Options check box to enable or disable anomaly detection.

- Specify an Are You There Attack Threshold Number of consecutive AYT commands to permit.

Tip Cisco recommends that you set the AYT threshold to a value no higher than the default value.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Server-Level FTP Options

License: Protection

You can set options for decoding on multiple FTP servers. Each server profile you create contains the server IP address and the ports on the server where traffic should be monitored. You can specify which FTP commands to validate and which to ignore for a particular server, and set maximum parameter lengths for commands. You can also set the specific command syntax the decoder should validate against for particular commands and set alternate maximum command parameter lengths.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Networks

Use this option to specify one or more IP addresses of FTP servers.

You can specify a single IP address or address block, or a comma-separated list comprised of either or both. You can configure up to 1024 characters, and you can specify up to 255 profiles including the default profile. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or address block for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Ports

Use this option to specify the ports on the FTP server where the managed device should monitor traffic. In the interface, list multiple ports separated by commas.

File Get Commands

Use this option to define the FTP commands used to transfer files from server to client. Do not change these values unless directed to do so by Support.

File Put Commands

Use this option to define the FTP commands used to transfer files from client to server. Do not change these values unless directed to do so by Support.

Additional FTP Commands

Use this line to specify the additional commands that the decoder should detect. Separate additional commands by spaces.

Default Max Parameter Length

Use this option to detect the maximum parameter length for commands where an alternate maximum parameter length has not been set.

You can enable rule 125:3 to generate events for this option. See Setting Rule States for more information.

Alternate Max Parameter Length

Use this option to specify commands where you want to detect a different maximum parameter length, and to specify the maximum parameter length for those commands. Click Add to add lines where you can specify a different maximum parameter length to detect for particular commands.

Check Commands for String Format Attacks

Use this option to check the specified commands for string format attacks.

You can enable rule 125:5 to generate events for this option. See Setting Rule States for more information.

Command Validity

Use this option to enter a valid format for a specific command. See Creating FTP Command Parameter Validation Statements for information on creating FTP command parameter validation statements to validate the syntax of a parameter received as part of an FTP communication. Click Add to add a command validation line.

You can enable rules 125:2 and 125:4 to generate events for this option. See Setting Rule States for more information.

Ignore FTP Transfers

Use this option to improve performance on FTP data transfers by disabling all inspection other than state inspection on the data transfer channel.

Detect Telnet Escape Codes within FTP Commands

Use this option to detect when telnet commands are used over the FTP command channel.

You can enable rule 125:1 to generate events for this option. See Setting Rule States for more information.

Ignore Erase Commands during Normalization

When Detect Telnet Escape Codes within FTP Commands is selected, use this option to ignore telnet character and line erase commands when normalizing FTP traffic. The setting should match how the FTP server handles telnet erase commands. Note that newer FTP servers typically ignore telnet erase commands, while older servers typically process them.

Troubleshooting Options: Log FTP Command Validation Configuration

Support might ask you during a troubleshooting call to configure your system to print the configuration information for each FTP command listed for the server.

Caution Changing the setting for this troubleshooting option affects performance and should be done only with Support guidance.

Creating FTP Command Parameter Validation Statements

License: Protection

When setting up a validation statement for an FTP command, you can specify a group of alternative parameters by separating the parameters with spaces. You can also create a binary OR relationship between two parameters by separating them with a pipe character (|) in the validation statement. Surrounding parameters by square brackets ([]) indicates that those parameters are optional. Surrounding parameters with curly brackets ({}) indicates that those parameters are required.

You can create FTP command parameter validation statements to validate the syntax of a parameter received as part of an FTP communication. See Understanding Server-Level FTP Options for more information.

Table 27-5 FTP Command Parameters

If you use...

The following validation occurs...

int

The represented parameter must be an integer.

number

The represented parameter must be an integer between 1 and 255.

char _chars

The represented parameter must be a single character and a member of the characters specified in the _chars argument.

For example, defining the command validity for MODE with the validation statement char SBC checks that the parameter for the MODE command comprises the character S (representing Stream mode), the character B (representing Block mode), or the character C (representing Compressed mode).

date _datefmt

If _datefmt contains #, the represented parameter must be a number.

If _datefmt contains C, the represented parameter must be a character.

If _datefmt contains literal strings, the represented parameter must match the literal string.

string

The represented parameter must be a string.

host_port

The represented parameter must be a valid host port specifier as defined by RFC 959, the File Transfer Protocol specification by the Network Working Group.

You can combine the syntax in the table above as needed to create parameter validation statements that correctly validate each FTP command where you need to validate traffic.

Note When you include a complex expression in a TYPE command, surround it by spaces. Also, surround each operand within the expression by spaces. For example, type char A | B , not char A|B.

Configuring Server-Level FTP Options

License: Protection

You can configure several options at the server level. For each FTP server you add, you can specify the ports to be monitored, the commands to validate, the default maximum parameter length for commands, alternate parameter lengths for specific commands, and validation syntax for particular commands. You can also choose whether to check for string format attacks and telnet commands on the FTP channel and whether to print configuration information with each command. For additional information on server-level FTP options, see Understanding Server-Level FTP Options.

To configure server-level FTP options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The FTP and Telnet Configuration page appears.

A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Tip For more information on configuring the other options on this page, see Configuring Global FTP/Telnet Options, Configuring Telnet Options, and Configuring Client-Level FTP Options.

Step 5 You have two options:

- Add a new server profile. Click the add icon (

) next to FTP Server on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses for the client in the Server Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. You can specify up to 1024 characters, and you can configure up to 255 policies, including the default policy. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of FTP servers on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the profile you added.

- Modify the settings for an existing server profile. Click the configured address for a profile you have added under FTP Server on the left side of the page, or click default .

) next to the profile you want to remove.

Step 6 Optionally, you can modify any of the following in the Configuration page area:

- Modify the address or addresses listed in the Networks field and click any other area of the page.

The highlighted address updates on the left side of the page.

Note that you cannot modify the setting for Network in the default profile. The default profile applies to all servers on your network that are not identified in another profile.

- Specify any Ports that should be monitored for FTP traffic. Port 21 is the well-known port for FTP traffic.

- Update the FTP commands used to transfer files from server to client in the File Get Commands field.

- Update the FTP commands used to transfer files from client to server in the File Put Commands field.

Note Do not change the values in the File Get Commands and File Put Commands field unless directed to do so by Support.

- To detect additional FTP commands outside of those checked by default by the FTP/Telnet preprocessor, type the commands, separated by spaces in the Additional FTP Commands field.

You can add as many additional FTP commands as needed.

Note Additional commands you may want to add include XPWD, XCWD, XCUP, XMKD, and XRMD. For more information on these commands, see RFC 775, the Directory oriented FTP commands specification by the Network Working Group.

- Specify the default maximum number of bytes for a command parameter in the Default Max Parameter Length field.

- To detect a different maximum parameter length for particular commands, click Add next to Alternate Max Parameter Length . In the first text box of the row that appears, specify the maximum parameter length. In the second text box, specify the commands, separated by spaces, where this alternate maximum parameter length should apply.

You can add as many alternative maximum parameter lengths as needed.

- To check for string format attacks on particular commands, specify the commands, separated by spaces, in the Check Commands for String Format Attacks text box.

- To specify the valid format for a command, click Add next to Command Validity . Specify the command you want to validate, then type a validation statement for the command parameter. For more information on the validation statement syntax, see Understanding Server-Level FTP Options.

- To improve performance on FTP data transfers by disabling all inspection other than state inspection on the data transfer channel, enable Ignore FTP Transfers .

Note To inspect data transfers, the global FTP/Telnet Stateful Inspection option must be selected. For more information on setting global options, see Understanding Global FTP and Telnet Options.

- To detect when telnet commands are used over the FTP command channel, select Detect Telnet Escape Codes within FTP Commands .

- To ignore telnet character and line erase commands when normalizing FTP traffic, enable Ignore Erase Commands during Normalization .

Step 7 Optionally, modify the related troubleshooting option only if asked to do so by Support; click the + sign next to Troubleshooting Options to expand the troubleshooting options section.

Step 8 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Client-Level FTP Options

License: Protection

You can create profiles for FTP clients. Within each profile, you can specify the maximum response length for an FTP response from a client. You can also configure whether the decoder detects bounce attacks and use of telnet commands on the FTP command channel for a particular client.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Networks

Use this option to specify one or more IP addresses of FTP clients.

You can specify a single IP address or address block, or a comma-separated list comprised of either or both. You can specify up to 1024 characters, and you can specify up to 255 profiles including the default profile. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or address block for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Max Response Length

Use this option to specify the maximum length of a response string from the FTP client.

You can enable rule 125:6 to generate events for this option. See Setting Rule States for more information.

Detect FTP Bounce Attempts

Use this option to detect FTP bounce attacks.

You can enable rule 125:8 to generate events for this option. See Setting Rule States for more information.

Allow FTP Bounce to

Use this option to configure a list of additional hosts and ports on those hosts on which FTP PORT commands should not be treated as FTP bounce attacks.

Detect Telnet Escape Codes within FTP Commands

Use this option to detect when telnet commands are used over the FTP command channel.

You can enable rule 125:1 to generate events for this option. See Setting Rule States for more information.

Ignore Erase Commands During Normalization

When Detect Telnet Escape Codes within FTP Commands is selected, use this option to ignore telnet character and line erase commands when normalizing FTP traffic.The setting should match how the FTP client handles telnet erase commands. Note that newer FTP clients typically ignore telnet erase commands, while older clients typically process them.

Configuring Client-Level FTP Options

License: Protection

You can configure client profiles for FTP clients to monitor FTP traffic from clients. For additional information on the options you can set for monitoring clients, see Understanding Client-Level FTP Options. For more information on telnet options, see Understanding Telnet Options. For more information on additional FTP options, see Understanding Server-Level FTP Options and Understanding Global FTP and Telnet Options.

To configure client-level FTP options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether FTP and Telnet Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The FTP and Telnet Configuration page appears.

Step 5 You have two options:

- Add a new client profile. Click the add icon (

) next to FTP Client on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses for the client in the Client Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. You can specify up to 1024 characters, and you can configure up to 255 policies, including the default policy. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of FTP clients on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the profile you added.

- Modify the settings for an existing client profile. Click the configured address for a profile you have added under FTP Client on the left side of the page, or click default .

) next to the profile you want to remove.

Step 6 Optionally, you can modify any of the following in the Configuration page area:

- Optionally, modify the address or addresses listed in the Networks field and click any other area of the page.

The highlighted address updates on the left side of the page.

Note that you cannot modify the setting for Network in the default profile. The default profile applies to all client hosts on your network that are not identified in another profile.

- Specify, in bytes, the maximum length of responses from the FTP client in the Max Response Length field.

- To detect FTP bounce attacks, select Detect FTP Bounce attempts .

The FTP/Telnet decoder detects when an FTP PORT command is issued and the specified host does not match the specified host of the client.

- To configure a list of additional hosts and ports where FTP PORT commands should not be treated as FTP bounce attacks, specify each host (or network in CIDR format) followed by a colon (:) and the port or port range in the Allow FTP Bounce to field. To enter a range of ports for a host, separate the beginning port in the range and the final port in the range with a dash (-). You can enter multiple hosts by separating the entries for the hosts with a comma.

For example, to permit FTP PORT commands directed to the host 192.168.1.1 at port 21 and commands directed to the host 192.168.1.2 at any of the ports from 22 to 1024, type:

192.168.1.1:21, 192.168.1.2:22-1024

For information on using CIDR notation and prefix lengths in the FireSIGHT System, see IP Address Conventions.

Note To specify multiple individual ports for a host, you must repeat the host IP address for each port definition. For example, to specify the ports 22 and 25 on 192.168.1.1, type 192.168.1.1:22, 192.168.1.1:25.

- To detect when telnet commands are used over the FTP command channel, select Detect Telnet Escape Codes within FTP Commands .

- To ignore telnet character and line erase commands when normalizing FTP traffic, select Ignore Erase Commands During Normalization .

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Decoding HTTP Traffic

License: Protection

The HTTP Inspect preprocessor is responsible for:

- decoding and normalizing HTTP requests sent to and HTTP responses received from web servers on your network

- separating messages sent to web servers into URI, non-cookie header, cookie header, method, and message body components to improve performance of HTTP-related intrusion rules

- separating messages received from web servers into status code, status message, non-set-cookie header, cookie header, and response body components to improve performance of HTTP-related intrusion rules

- detecting possible URI-encoding attacks

- making the normalized data available for additional rule processing

HTTP traffic can be encoded in a variety of formats, making it difficult for rules to appropriately inspect. HTTP Inspect decodes 14 types of encoding, ensuring that your HTTP traffic gets the best inspection possible.

You can configure HTTP Inspect options globally, on a single server, or for a list of servers.

Note the following when using the HTTP Inspect preprocessor:

- The preprocessor engine performs HTTP normalization statelessly . That is, it normalizes HTTP strings on a packet-by-packet basis, and can only process HTTP strings that have been reassembled by the TCP stream preprocessor.

- You must enable HTTP preprocessor rules, which have a generator ID (GID) of 119, if you want these rules to generate events. See Setting Rule States for more information.

See the following sections for more information:

- Selecting Global HTTP Normalization Options

- Configuring Global HTTP Configuration Options

- Selecting Server-Level HTTP Normalization Options

- Selecting Server-Level HTTP Normalization Encoding Options

- Configuring HTTP Server Options

- Enabling Additional HTTP Inspect Preprocessor Rules

Selecting Global HTTP Normalization Options

License: Protection

The global HTTP options provided for the HTTP Inspect preprocessor control how the preprocessor functions. Use these options to enable or disable HTTP normalization when ports not specified as web server ports receive HTTP traffic.

Note the following:

- If you enable Unlimited Decompression , the Maximum Compressed Data Depth and Maximum Decompressed Data Depth options are automatically set to 65535 when you commit your changes. See Selecting Server-Level HTTP Normalization Options for more information.

- If the values for the Maximum Compressed Data Depth and Maximum Decompressed Data Depth options are different in an intrusion policy associated with the default action of an access control policy and intrusion policies associated with access control rules, the highest value is used.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Detect Anomalous HTTP Servers

Detects HTTP traffic sent to or received by ports not specified as web server ports.

Note If you turn this option on, be make to list all ports that do receive HTTP traffic in a server profile on the HTTP Configuration page. If you do not, and you enable this option and the accompanying preprocessor rule, normal traffic to and from the server will generate events. The default server profile contains all ports normally used for HTTP traffic, but if you modified that profile, you may need to add those ports to another profile to prevent events from being generated.

You can enable rule 120:1 to generate events for this option. See Setting Rule States for more information.

Detect HTTP Proxy Servers

Detects HTTP traffic using proxy servers not defined by the Allow HTTP Proxy Use option.

You can enable rule 119:17 to generate events for this option. See Setting Rule States for more information.

Maximum Compressed Data Depth

Sets the maximum size of compressed data to decompress when Inspect Compressed Data (and, optionally, Decompress SWF File (LZMA), Decompress SWF File (Deflate), or Decompress PDF File (Deflate)) is enabled. You can specify from 1 to 65535 bytes.

Maximum Decompressed Data Depth

Sets the maximum size of the normalized decompressed data when Inspect Compressed Data (and, optionally, Decompress SWF File (LZMA), Decompress SWF File (Deflate), or Decompress PDF File (Deflate)) is enabled. You can specify from 1 to 65535 bytes.

Configuring Global HTTP Configuration Options

License: Protection

You can configure detection of HTTP traffic to non-standard ports and on HTTP traffic using proxy servers. For more information on global HTTP configuration options, see Selecting Global HTTP Normalization Options.

To configure global HTTP configuration options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether HTTP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The HTTP Configuration page appears.

Step 5 You can modify any of the global options described in Selecting Global HTTP Normalization Options.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Selecting Server-Level HTTP Normalization Options

License: Protection

You can set server-level options for each server you monitor, globally for all servers, or for a list of servers. Additionally, you can use a predefined server profile to set these options, or you can set them individually to meet the needs of your environment. Use these options, or one of the default profiles that set these options, to specify the HTTP server ports whose traffic you want to normalize, the amount of server response payload you want to normalize, and the types of encoding you want to normalize.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Networks

Use this option to specify the IP address of one or more servers. You can specify a single IP address or address block, or a comma-separated list comprised of either or both.

In addition to a limit of up to 255 total profiles, including the default profile, you can include up to 496 characters, or approximately 26 entries, in an HTTP server list, and specify a total of 256 address entries for all server profiles. For information on using IPv4 CIDR notation and IPv6 prefix lengths in the FireSIGHT System, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Ports

The ports whose HTTP traffic the preprocessor engine normalizes. Separate multiple port numbers with commas.

Oversize Dir Length

Detects URL directories longer than the specified value.

You can enable rule 119:15 to generate events for this option. See Setting Rule States for more information.

Client Flow Depth

Specifies the number of bytes for rules to inspect in raw HTTP packets, including header and payload data, in client-side HTTP traffic defined in Ports. Client flow depth does not apply when HTTP content rule options within a rule inspect specific parts of a request message. See HTTP Content Options for more information.

You can specify a value from -1 to 1460. Cisco recommends that you set client flow depth to its maximum value. Specify any of the following:

– From 1 to 1460 inspects the specified number of bytes in the first packet. If the first packet contains fewer bytes than specified, inspect the entire packet. Note that the specified value applies to both segmented and reassembled packets.

Note also that a value of 300 typically eliminates inspection of large HTTP Cookies that appear at the end of many client request headers.

– 0 inspects all client-side traffic, including multiple packets in a session and exceeding the 1460 byte limit if necessary. Note that this value is likely to affect performance.

– -1 ignores all client-side traffic.

Server Flow Depth

Specifies the number of bytes for rules to inspect in raw HTTP packets in server-side HTTP traffic specified by Ports. Inspection includes the raw header and payload when Inspect HTTP Responses disabled and only the raw response body when Inspect HTTP Response is enabled.

Server flow depth specifies the number of bytes of raw server response data in a session for rules to inspect in server-side HTTP traffic defined in Ports. You can use this option to balance performance and the level of inspection of HTTP server response data. Server flow depth does not apply when HTTP content options within a rule inspect specific parts of a response message. See HTTP Content Options for more information.

Unlike client flow depth, server flow depth specifies the number of bytes per HTTP response, not per HTTP request packet, for rules to inspect.

You can specify a value from -1 to 65535. Cisco recommends that you set the server flow depth to its maximum value. You can specify any of the following:

– From 1 to 65535:

When Inspect HTTP Responses is enabled, inspects only the raw HTTP response body, and not raw HTTP headers; also inspects decompressed data when Inspect Compressed Data is enabled.

When Inspect HTTP Responses is disabled, inspects the raw packet header and payload.

If the session includes fewer response bytes than specified, rules fully inspect all response packets in a given session, across multiple packets as needed. If the session includes more response bytes than specified, rules inspect only the specified number of bytes for that session, across multiple packets as needed.

Note that a small flow depth value may cause false negatives from rules that target server-side traffic defined in Ports. Most of these rules target either the HTTP header or content that is likely to be in the first hundred or so bytes of non-header data. Headers are usually under 300 bytes long, but header size may vary.

Note also that the specified value applies to both segmented and reassembled packets.

– 0 inspects the entire packet for all HTTP server-side traffic defined in Ports, including response data in a session that exceeds 65535 bytes.

Note that this value is likely to affect performance.

– -1:

When Inspect HTTP Responses is enabled, inspects only raw HTTP headers and not the raw HTTP response body.

When Inspect HTTP Responses is disabled, ignores all server-side traffic defined in Ports.

Maximum Header Length

Detects a header field longer than the specified maximum number of bytes in an HTTP request; also in HTTP responses when Inspect HTTP Responses is enabled. The value of 0 disables this option. Specify a value from 1 to 65535 to enable it.

You can enable rule 119:19 to generate events for this option. See Setting Rule States for more information.

Maximum Number of Headers

Detects when the number of headers exceeds this setting in an HTTP request. Specify a value from 1 to 1024 to enable it.

You can enable rule 119:20 to generate events for this option. See Setting Rule States for more information.

Maximum Number of Spaces

Detects when the number of white spaces in a folded line equals or exceeds this setting in an HTTP request. A value of 0 disables this option. Specify a value from 1 to 65535 to enable it.

You can enable rule 119:26 to generate events for this option. See Setting Rule States for more information.

HTTP Client Body Extraction Depth

Specifies the number of bytes to extract from the message body of an HTTP client request. You can use an intrusion rule to inspect the extracted data by selecting the content or protected_content keyword HTTP Client Body option. See HTTP Content Options for more information.

Specify a value from -1 to 65495. Specify -1 to ignore the client body. Specify 0 to extract the entire client body. Note that identifying specific bytes to extract can improve system performance. Note also that you must specify a value from 0 to 65495 for the HTTP Client Body option to function in an intrusion rule.

Small Chunk Size

Specifies the maximum number of bytes at which a chunk is considered small. Specify a value of 1 to 255. A value of 0 disables detection of anomalous consecutive small segments. See the Consecutive Small Chunks option for more information.

Consecutive Small Chunks

Specifies how many consecutive small chunks represent an abnormally large number in client or server traffic that uses chunked transfer encoding. The Small Chunk Size option specifies the maximum size of a small chunk.

For example, set Small Chunk Size to 10 and Consecutive Small Chunks to 5 to detect 5 consecutive chunks of 10 bytes or less.

You can enable preprocessor rule 119:27 to trigger events on excessive small chunks in client traffic, and rule 120:7 in server traffic. When Small Chunk Size is enabled and this option is set to 0 or 1, enabling these rules would trigger an event on every chunk of the specified size or less. See Setting Rule States for more information.

HTTP Methods

Specifies HTTP request methods in addition to GET and POST that you expect the system to encounter in traffic. Use a comma to separate multiple values.

Intrusion rules use the content or protected_content keyword with the HTTP Method argument to search for content in HTTP methods. See HTTP Content Options. You can enable rule 119:31 to generate events when a method other than GET, POST, or a method configured for this option is encountered in traffic.

No Alerts

Disables intrusion events when accompanying preprocessor rules are enabled.

Note This option does not disable HTTP standard text rules and shared object rules.

Normalize HTTP Headers

When Inspect HTTP Responses is enabled, enables normalization of non-cookie data in request and response headers. When Inspect HTTP Responses is not enabled, enables normalization of the entire HTTP header, including cookies, in request and response headers.

Inspect HTTP Cookies

Enables extraction of cookies from HTTP request headers. Also enables extraction of set-cookie data from response headers when Inspect HTTP Responses is enabled. Disabling this option when cookie extraction is not required can improve performance.

Note that the Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

Normalize Cookies in HTTP headers

Enables normalization of cookies in HTTP request headers. When Inspect HTTP Responses is enabled, also enables normalization of set-cookie data in response headers. You must select Inspect HTTP Cookies before selecting this options.

Allow HTTP Proxy Use

Allows the monitored web server to be used as an HTTP proxy. This option is used only in the inspection of HTTP requests.

Inspect URI Only

Inspects only the URI portion of the normalized HTTP request packet.

Inspect HTTP Responses

Enables extended inspection of HTTP responses so, in addition to decoding and normalizing HTTP request messages, the preprocessor extracts response fields for inspection by the rules engine. Enabling this option causes the system to extract the response header, body, status code, and so on, and also extracts set-cookie data when Inspect HTTP Cookies is enabled. For more information, see HTTP Content Options, Generating Events on the HTTP Encoding Type and Location, and Pointing to a Specific Payload Type.

You can enable rules 120:2 and 120:3 to generate events for this option. See Setting Rule States for more information.

Normalize UTF Encodings to UTF-8

When Inspect HTTP Responses is enabled, detects UTF-16LE, UTF-16BE, UTF-32LE, and UTF32-BE encodings in HTTP responses and normalizes them to UTF-8.

You can enable rule 120:4 to generate events for this option. See Setting Rule States for more information.

Inspect Compressed Data

When Inspect HTTP Responses is enabled, enables decompression of gzip and deflate-compatible compressed data in the HTTP response body, and inspection of the normalized decompressed data. The system inspects chunked and non-chunked HTTP response data. The system inspects decompressed data packet by packet across multiple packets as needed; that is, the system does not combine the decompressed data from different packets for inspection. Decompression ends when Maximum Compressed Data Depth, Maximum Decompressed Data Depth, or the end of the compressed data is reached. Inspection of decompressed data ends when Server Flow Depth is reached unless you also select Unlimited Decompression. You can use the file_data rule keyword to inspect decompressed data; see Pointing to a Specific Payload Type for more information.

Unlimited Decompression

When Inspect Compressed Data (and, optionally, Decompress SWF File (LZMA), Decompress SWF File (Deflate), or Decompress PDF File (Deflate)) is enabled, overrides Maximum Decompressed Data Depth across multiple packets; that is, this option enables unlimited decompression across multiple packets. Note that enabling this option does not affect Maximum Compressed Data Depth or Maximum Decompressed Data Depth within a single packet. Note also that enabling this option sets Maximum Compressed Data Depth and Maximum Decompressed Data Depth to 65535 when you commit your changes. See Selecting Global HTTP Normalization Options.

Normalize Javascript

When Inspect HTTP Responses is enabled, enables detection and normalization of Javascript within the HTTP response body. The preprocessor normalizes obfuscated Javascript data such as the unescape and decodeURI functions and the String.fromCharCode method. The preprocessor normalizes the following encodings within the unescape, decodeURI, and decodeURIComponent functions:

– %XX

– %uXXXX

– 0xXX

– \xXX

– \uXXXX

The preprocessor detects consecutive white spaces and normalizes them into a single space. When this option is enabled, a configuration field allows you to specify the maximum number of consecutive white spaces to permit in obfuscated Javascript data. You can enter a value from 1 to 65535. The value 0 disables event generation, regardless of whether the preprocessor rule (120:10) associated with this field is enabled.

The preprocessor also normalizes the Javascript plus (+) operator and concatenates strings using the operator.

You can use the file_data keyword to point intrusion rules to the normalized Javascript data. See Pointing to a Specific Payload Type for more information.

You can enable rules 120:9, 120:10, and 120:11 to generate events for this option, as follows:

Table 27-6 Normalize Javascript Option Rules

This rule...

Triggers an event when...

120:9

the obfuscation level within the preprocessor is greater than or equal to 2.

120:10

the number of consecutive white spaces in the Javascript obfuscated data is greater than or equal to the value configured for the maximum number of consecutive white spaces allowed.

120:11

escaped or encoded data includes more than one type of encoding.

See Setting Rule States for more information.

Decompress SWF File (LZMA) and Decompress SWF File (Deflate)

When HTTP Inspect Responses is enabled, these options decompress the compressed portions of files located within the HTTP response body of HTTP requests.

Note You can only decompress the compressed portions of files found in HTTP GET responses.

– Decompress SWF File (LZMA) decompresses the LZMA-compatible compressed portions of Adobe ShockWave Flash (.swf) files

– Decompress SWF File (Deflate) decompresses the deflate-compatible compressed portions of Adobe ShockWave Flash (.swf) files

Decompression ends when Maximum Compressed Data Depth, Maximum Decompressed Data Depth, or the end of the compressed data is reached. Inspection of decompressed data ends when Server Flow Depth is reached unless you also select Unlimited Decompression. You can use the file_data rule keyword to inspect decompressed data; see Pointing to a Specific Payload Type for more information.

You can enable rules 120:12 and 120:13 to generate events for this option, as follows:

Table 27-7 Decompress SWF File Option Rules

This rule...

Triggers an event when...

120:12

deflate file decompression fails.

120:13

LZMA file decompression fails.

Decompress PDF File (Deflate)

When HTTP Inspect Responses is enabled, Decompress PDF File (Deflate) decompresses the deflate-compatible compressed portions of Portable Document Format (.pdf) files located within the HTTP response body of HTTP requests. The system can only decompress PDF files with the /FlateDecode stream filter. Other stream filters (including /FlateDecode /FlateDecode) are unsupported.

Note You can only decompress the compressed portions of files found in HTTP GET responses.

Decompression ends when Maximum Compressed Data Depth, Maximum Decompressed Data Depth, or the end of the compressed data is reached. Inspection of decompressed data ends when Server Flow Depth is reached unless you also select Unlimited Decompression. You can use the file_data rule keyword to inspect decompressed data; see Pointing to a Specific Payload Type for more information.

You can enable rules 120:14, 120:15, 120:16, and 120:17 to generate events for this option, as follows:

Table 27-8 Decompress PDF File (Deflate) Option Rules

This rule...

Triggers an event when...

120:14

file decompression fails.

120:15

file decompression fails due to an unsupported compression type.

120:16

file decompression fails due to an unsupported PDF stream filter.

120:17

file parsing fails.

Extract Original Client IP Address

Enables extraction of the original client IP address from the X-Forwarded-For (XFF), True-Client-IP, or custom-defined HTTP header. You can display the extracted original client IP address in the intrusion events table view. See Understanding Intrusion Events for more information.

You can enable rules 119:23, 119:29 and 119:30 to generate events for this option. See Setting Rule States for more information.

XFF Header Priority

When Extract Original Client IP Address is enabled, specifies the order in which the system processes original client IP HTTP headers. If, on your monitored network, you expect to encounter original client IP headers other than X-Forwarded-For (XFF) or True-Client-IP, you can click Add to add additional header names to the priority list. You can then use the up and down arrow icons beside each header type to adjust its priority. Note that if multiple XFF headers appear in an HTTP request, the system processes only the header with the highest priority.

Log URI

Enables extraction of the raw URI, if present, from HTTP request packets and associates the URI with all intrusion events generated for the session.

When this option is enabled, you can display the first fifty characters of the extracted URI in the HTTP URI column of the intrusion events table view. You can display the complete URI, up to 2048 bytes, in the packet view. See Understanding Intrusion Events and Viewing Event Information for more information.

Log Hostname

Enables extraction of the host name, if present, from the HTTP request Host header and associates the host name with all intrusion events generated for the session. When multiple Host headers are present, extracts the host name from the first header.

When this option is enabled, you can display the first fifty characters of the extracted host name in the HTTP Hostname column of the intrusion events table view. You can display the complete host name, up to 256 bytes, in the packet view. See Understanding Intrusion Events and Viewing Event Information for more information.

You can enable rule 119:25 to generate events for this option. See Setting Rule States for more information.

Note that when the preprocessor and rule 119:24 are enabled, the preprocessor generates an intrusion event if it detects multiple Host headers in an HTTP request, regardless of the setting for this option. See Enabling Additional HTTP Inspect Preprocessor Rules for more information.

Profile

Specifies the types of encoding that are normalized for HTTP traffic. The system provides a default profile appropriate for most servers, default profiles for Apache servers and IIS servers, and custom default settings that you can tailor to meet the needs of your monitored traffic. See Selecting Server-Level HTTP Normalization Encoding Options for more information.

Selecting Server-Level HTTP Normalization Encoding Options

License: Protection

You can select server-level HTTP normalization options to specify the types of encoding that are normalized for HTTP traffic, and to cause the system to generate events against traffic containing this type of encoding.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

ASCII Encoding

Decodes encoded ASCII characters and specifies whether the rules engine generates an event on ASCII-encoded URIs.

You can enable rule 119:1 to generate events for this option. See Setting Rule States for more information.

UTF-8 Encoding

Decodes standard UTF-8 Unicode sequences in the URI.

You can enable rule 119:6 to generate events for this option. See Setting Rule States for more information.

Microsoft %U Encoding

Decodes the IIS %u encoding scheme that uses %u followed by four characters where the 4 characters are a hex encoded value that correlates to an IIS Unicode codepoint.

Tip Legitimate clients rarely use %u encodings, so Cisco recommends decoding HTTP traffic encoded with %u encodings.

You can enable rule 119:3 to generate events for this option. See Setting Rule States for more information.

Bare Byte UTF-8 Encoding

Decodes bare byte encoding, which uses non-ASCII characters as valid values in decoding UTF-8 values.

Tip Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings correctly. Cisco recommends enabling this option because no legitimate clients encode UTF-8 this way.

You can enable rule 119:4 to generate events for this option. See Setting Rule States for more information.

Microsoft IIS Encoding

Decodes using Unicode codepoint mapping.

Tip Cisco recommends enabling this option, because it is seen mainly in attacks and evasion attempts.

You can enable rule 119:7 to generate events for this option. See Setting Rule States for more information.

Double Encoding

Decodes IIS double encoded traffic by making two passes through the request URI performing decodes in each one. Cisco recommends enabling this option because it is usually found only in attack scenarios.

You can enable rule 119:2 to generate events for this option. See Setting Rule States for more information.

Multi-Slash Obfuscation

Normalizes multiple slashes in a row into a single slash.

You can enable rule 119:8 to generate events for this option. See Setting Rule States for more information.

IIS Backslash Obfuscation

Normalizes backslashes to forward slashes.

You can enable rule 119:9 to generate events for this option. See Setting Rule States for more information.

Directory Traversal

Normalizes directory traversals and self-referential directories. If you enable the accompanying preprocessor rules to generate events against this type of traffic, it may generate false positives because some web sites refer to files using directory traversals.

You can enable rules 119:10 and 119:11 to generate events for this option. See Setting Rule States for more information.

Tab Obfuscation

Normalizes the non-RFC standard of using a tab for a space delimiter. Apache and other non-IIS web servers use the tab character (0x09) as a delimiter in URLs.

Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab as white space if a space character (0x20) precedes it.

You can enable rule 119:12 to generate events for this option. See Setting Rule States for more information.

Invalid RFC Delimiter

Normalizes line breaks (\n) in URI data.

You can enable rule 119:13 to generate events for this option. See Setting Rule States for more information.

Webroot Directory Traversal

Detects directory traversals that traverse past the initial directory in the URL.

You can enable rule 119:18 to generate events for this option. See Setting Rule States for more information.

Tab URI Delimiter

Turns on the use of the tab character (0x09) as a delimiter for a URI. Apache, newer versions of IIS, and some other web servers use the tab character as a delimiter in URLs.

Note Regardless of the configuration for this option, the HTTP Inspect preprocessor treats a tab as white space if a space character (0x20) precedes it.

Non-RFC characters

Detects the non-RFC character list you add in the corresponding field when it appears within incoming or outgoing URI data. When modifying this field, use the hexadecimal format that represents the byte character. If and when you configure this option, set the value with care. Using a character that is very common may overwhelm you with events.

You can enable rule 119:14 to generate events for this option. See Setting Rule States for more information.

Max Chunk Encoding Size

Detects abnormally large chunk sizes in URI data.

You can enable rules 119:16 and 119:22 to generate events for this option. See Setting Rule States for more information.

Disable Pipeline Decoding

Disables HTTP decoding for pipelined requests. When this option is disabled, performance is enhanced because HTTP requests waiting in the pipeline are not decoded or analyzed, and are only inspected using generic pattern matching.

Non-Strict URI Parsing

Enables non-strict URI parsing. Use this option only on servers that will accept non-standard URIs in the format "GET /index.html abc xo qr \n". Using this option, the decoder assumes that the URI is between the first and second space, even if there is no valid HTTP identifier after the second space.

Extended ASCII Encoding

Enables parsing of extended ASCII characters in an HTTP request URI. Note that this option is available in custom server profiles only, and not in the default profiles provided for Apache, IIS, or all servers.

Configuring HTTP Server Options

License: Protection

Use the following procedure to configure HTTP server options. For more information on the HTTP server options, see Selecting Server-Level HTTP Normalization Options and Selecting Server-Level HTTP Normalization Encoding Options.

To configure server-level HTTP configuration options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether HTTP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The HTTP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You have two options:

- Add a new server profile. Click the add icon (

) next to Servers on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses for the client in the Server Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. You can include up to 496 characters in a list, specify a total of 256 address entries for all server profiles, and create a total of 255 profiles including the default profile. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of servers on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the profile you added.

- Modify the settings for an existing profile. Click the configured address for a profile you have added under Servers on the left side of the page, or click default .

) next to the profile you want to remove.

Step 6 Optionally, modify the address or addresses listed in the Networks field and click any other area of the page.

The highlighted address updates on the left side of the page.

Note that you cannot modify the setting for Networks in the default profile. The default profile applies to all servers on your network that are not identified in another profile.

Step 7 In the Ports field, list the ports whose traffic you want to inspect with HTTP Inspect. Separate multiple ports with commas.

Step 8 You can modify any of the other options described in Selecting Server-Level HTTP Normalization Options.

Step 9 Select a server profile as follows:

- Select Custom to create your own server profile (see Selecting Server-Level HTTP Normalization Encoding Options for more information).

- Select All to use the standard default profile, appropriate for all servers.

- Select IIS to use the default IIS profile.

- Select Apache to use the default Apache profile.

Step 10 If you selected Custom, the custom options appear.

Step 11 Configure the HTTP decoding options you want in your profile.

See Selecting Server-Level HTTP Normalization Options for details on available normalization options.

Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Enabling Additional HTTP Inspect Preprocessor Rules

License: Protection

You can enable the rules in the Preprocessor Rule GID:SID column of the following table to generate events for HTTP Inspect preprocessor rules that are not associated with specific configuration options. See Setting Rule States for more information.

Table 27-9 Additional HTTP Inspect Preprocessor Rules

Preprocessor Rule GID:SID

Description

120:5

Generates an event when UTF-7 encoding is encountered in HTTP response traffic; UTF-7 should only appear where 7-bit parity is required, such as in SMTP traffic.

119:21

Generates an event when an HTTP request header has more than one content-length field.

119:24

Generates an event when an HTTP request has more than one Host header.

119:28

120:8

When enabled, these rules do not generate events.

119:32

Generates an event when HTTP version 0.9 is encountered in traffic. Note that the TCP stream configuration must also be enabled. See Using TCP Stream Preprocessing.

119:33

Generates an event when an HTTP URI includes an unescaped space.

119:34

Generates an event when a TCP connection contains 24 or more pipelined HTTP requests.

Using the Sun RPC Preprocessor

License: Protection

RPC (Remote Procedure Call) normalization takes fragmented RPC records and normalizes them to a single record so the rules engine can inspect the complete record. For example, an attacker may attempt to discover the port where RPC admind runs. Some UNIX hosts use RPC admind to perform remote distributed system tasks. If the host performs weak authentication, a malicious user could take control of remote administration. The standard text rule (generator ID: 1) with the Snort ID (SID) 575 detects this attack by searching for content in specific locations to identify inappropriate portmap GETPORT requests.

Ports

Specify the ports whose traffic you want to normalize. In the interface, list multiple ports separated by commas. Typical RPC ports are 111 and 32771. If your network sends RPC traffic to other ports, consider adding them.

Detect fragmented RPC records

Detects RPC fragmented records.

You can enable rules 106:1 and 106:5 to generate events for this option. See Setting Rule States for more information.

Detect multiple records in one packet

Detects more than one RPC request per packet (or reassembled packet).

You can enable rule 106:2 to generate events for this option. See Setting Rule States for more information.

Detect fragmented record sums which exceed one fragment

Detects reassembled fragment record lengths that exceed the current packet length.

You can enable rule 106:3 to generate events for this option. See Setting Rule States for more information.

Detect single fragment records which exceed the size of one packet

Detects partial records

You can enable rule 106:4 to generate events for this option. See Setting Rule States for more information.

Configuring the Sun RPC Preprocessor

License: Protection

You can use the following procedure to configure the Sun RPC preprocessor. For more information on the Sun RPC preprocessor configuration options, see Using the Sun RPC Preprocessor.

To configure the Sun RPC preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether Sun RPC Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Sun RPC Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 In the Ports field, type the port numbers where you want to decode RPC traffic. Separate multiple ports with commas.

Step 6 You can select or clear any of the following detection options on the Sun RPC Configuration page:

- Detect fragmented RPC records

- Detect multiple records in one packet

- Detect fragmented record sums which exceed one packet

- Detect single fragment records which exceed the size of one packet

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Decoding the Session Initiation Protocol

License: Protection

The Session Initiation Protocol (SIP) provides call setup, modification, and teardown of one or more sessions for one or more users of such client applications as Internet telephony, multimedia conferencing, instant messaging, online gaming, and file transfer. A method field in each SIP request identifies the purpose of the request, and a Request-URI specifies where to send the request. A status code in each SIP response indicates the outcome of the requested action.

After calls are set up using SIP, the Real-time Transport Protocol (RTP) is responsible for subsequent audio and video communication; this part of the session is sometimes referred to as the call channel, the data channel, or the audio/video data channel. RTP uses the Session Description Protocol (SDP) within the SIP message body for data-channel parameter negotiation, session announcement, and session invitation.

The SIP preprocessor is responsible for:

- decoding and analyzing SIP 2.0 traffic

- extracting the SIP header and message body, including SDP data when present, and passing the extracted data to the rules engine for further inspection

- generating events when the following conditions are detected and the corresponding preprocessor rules are enabled: anomalies and known vulnerabilities in SIP packets; out-of-order and invalid call sequences

- optionally ignoring the call channel

The preprocessor identifies the RTP channel based on the port identified in the SDP message, which is embedded in the SIP message body, but the preprocessor does not provide RTP protocol inspection.

Note the following when using the SIP preprocessor:

- UDP typically carries media sessions supported by SIP. UDP stream preprocessing provides SIP session tracking for the SIP preprocessor.

- SIP rule keywords allow you to point to the SIP packet header or message body and to limit detection to packets for specific SIP methods or status codes. For more information, see SIP Keywords.

- When enabled, the preprocessor generates no events before sending the extracted data to the rules engine unless you also enable the accompanying rules with generator ID (GID) 140. See Setting Rule States for more information.

See the following sections for more information:

- Selecting SIP Preprocessor Options

- Configuring the SIP Preprocessor

- Enabling Additional SIP Preprocessor Rules

Selecting SIP Preprocessor Options

License: Protection

The following list describes SIP preprocessor options you can modify.

For the Maximum Request URI Length, Maximum Call ID Length, Maximum Request Name Length, Maximum From Length, Maximum To Length, Maximum Via Length, Maximum Contact Length, and Maximum Content Length options, you can specify from 1 to 65535 bytes, or 0 to disable event generation for the option regardless of whether the associated rule is enabled.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Ports

Specifies the ports to inspect for SIP traffic. You can specify an integer from 0 to 65535. Separate multiple port numbers with commas.

Methods to Check

Specifies SIP methods to detect. You can specify any of the following currently defined SIP methods:

ack, benotify, bye, cancel, do, info, invite, join, message,

notify, options, prack, publish, quath, refer, register,

service, sprack, subscribe, unsubscribe, update

Methods are case-insensitive. The method name can include alphabetic characters, numbers, and the underscore character. No other special characters are permitted. Separate multiple methods with commas.

Because new SIP methods might be defined in the future, your configuration can include an alphabetic string that is not currently defined. The system supports up to 32 methods, including the 21 currently defined methods and an additional 11 methods. The system ignores any undefined methods that you might configure.

Note that, in addition to any methods you specify for this option, the 32 total methods includes methods specified using the sip_method keyword in intrusion rules. See sip_method for more information.

Maximum Dialogs within a Session

Specifies the maximum number of dialogs allowed within a stream session. If more dialogs than this number are created, the oldest dialogs are dropped until the number of dialogs does not exceed the maximum number specified; an event also triggers when rule 140:27 is enabled.

You can specify an integer from 1 to 4194303.

Maximum Request URI Length

Specifies the maximum number of bytes to allow in the Request-URI header field. A longer URI triggers an event when rule 140:3 is enabled. The request URI field indicates the destination path or page for the request.

Maximum Call ID Length

Specifies the maximum number of bytes to allow in the request or response Call-ID header field. A longer Call-ID triggers an event when rule 140:5 is enabled. The Call-ID field uniquely identifies the SIP session in requests and responses.

Maximum Request Name Length

Specifies the maximum number of bytes to allow in the request name, which is the name of the method specified in the CSeq transaction identifier. A longer request name triggers an event when rule 140:7 is enabled.

Maximum From Length

Specifies the maximum number of bytes to allow in the request or response From header field. A longer From triggers an event when rule 140:9 is enabled. The From field identifies the message initiator.

Maximum To Length

Specifies the maximum number of bytes to allow in the request or response To header field. A longer To triggers an event when rule 140:11 is enabled. The To field identifies the message recipient.

Maximum Via Length

Specifies the maximum number of bytes to allow in the request or response Via header field. A longer Via triggers an event when rule 140:13 is enabled. The Via field provides the path followed by the request and, in a response, receipt information.

Maximum Contact Length

Specifies the maximum number of bytes to allow in the request or response Contact header field. A longer Contact triggers an event when rule 140:15 is enabled. The Contact field provides a URI that specifies the location to contact with subsequent messages.

Maximum Content Length

Specifies the maximum number of bytes to allow in the content of the request or response message body. Longer content triggers an event when rule 140:16 is enabled.

Ignore Audio/Video Data Channel

Enables and disables inspection of data channel traffic. Note that the preprocessor continues inspection of other non-data-channel SIP traffic when you enable this option.

Configuring the SIP Preprocessor

License: Protection

Use the following procedure to configure the SIP preprocessor.

To configure the SIP preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether SIP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The SIP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can modify any of the options described in Selecting SIP Preprocessor Options.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Enabling Additional SIP Preprocessor Rules

License: Protection

The SIP preprocessor rules in the following table are not associated with specific configuration options. As with other SIP preprocessor rules, you must enable these rules if you want them to generate events. See Setting Rule States for information on enabling rules.

Table 27-10 Additional SIP Preprocessor Rules

Preprocessor Rule GID:SID

Description

140:1

Generates an event when the preprocessor is monitoring the maximum number of SIP sessions allowed by the system.

140:2

Generates an event when the required Request_URI field is empty in a SIP request.

140:4

Generates an event when the Call-ID header field is empty in a SIP request or response.

140:6

Generates an event when the value for the sequence number in the SIP request or response CSeq field is not a 32-bit unsigned integer less than 231.

140:8

Generates an event an event when the From header field is empty in a SIP request or response.

140:10

Generates an event when the To header field is empty in a SIP request or response.

140:12

Generates an event when the Via header field is empty in a SIP request or response

140:14

Generates an event when the required Contact header field is empty in a SIP request or response.

140:17

Generates an event when a single SIP request or response packet in UDP traffic contains multiple messages. Note that older SIP versions supported multiple messages, but SIP 2.0 supports only one message per packet.

140:18

Generates an event when the actual length of the message body in a SIP request or response in UDP traffic does not match the value specified in the Content-Length header field in a SIP request or response.

140:19

Generates an event when the preprocessor does not recognize a method name in the CSeq field of a SIP response.

140:20

Generates an event when the SIP server does not challenge an authenticated invite message. Note that this occurs in the case of the InviteReplay billing attack.

140:21

Generates an event when session information changes before the call is set up. Note that this occurs in the case of the FakeBusy billing attack.

140:22

Generates an event when the response status code is not a three-digit number.

140:23

Generates an event when the Content-Type header field does not specify a content type and the message body contains data.

140:24

Generates an event when the SIP version is not 1, 1.1, or 2.0.

140:25

Generates an event when the method specified in the CSeq header and the method field do not match in a SIP request.

140:26

Generates an event when the preprocessor does not recognize the method named in the SIP request method field.

Configuring the GTP Command Channel

License: Protection

The General Service Packet Radio (GPRS) Tunneling Protocol (GTP) provides communication over a GTP core network. The GTP preprocessor detects anomalies in GTP traffic and forwards command channel signaling messages to the rules engine for inspection. You can use the gtp_version, gtp_type, and gtp_info rule keywords to inspect GTP command channel traffic for exploits.

A single configuration option allows you to modify the default setting for the ports that the preprocessor inspects for GTP command channel messages.

Table 27-11 GTP Preprocessor Rules

Preprocessor Rule GID:SID

Description

143:1

Generates an event when the preprocessor detects an invalid message length.

143:2

Generates an event when the preprocessor detects an invalid information element length.

143:3

Generates an event when the preprocessor detects information elements that are out of order.

You can use the following procedure to modify the ports the GTP preprocessor monitors for GTP command messages.

To configure the GTP command channel:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether GTP Command Channel Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The GTP Command Channel Configuration page appears.

Step 5 Optionally, modify the ports that the preprocessor inspects for GTP command messages. You can specify an integer from 0 to 65535. Use commas to separate multiple ports.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Decoding IMAP Traffic

License: Protection

The Internet Message Application Protocol (IMAP) is used to retrieve email from a remote IMAP server. The IMAP preprocessor inspects server-to-client IMAP4 traffic and, when associated preprocessor rules are enabled, generates events on anomalous traffic. The preprocessor can also extract and decode email attachments in client-to-server IMAP4 traffic and send the attachment data to the rules engine. You can use the file_data keyword in an intrusion rule to point to the attachment data. See Pointing to a Specific Payload Type for more information.

Extraction and decoding include multiple attachments, when present, and large attachments that span multiple packets.

If you want IMAP preprocessor rules to generate events, you must enable the rules. IMAP preprocessor rules have a generator ID (GID) of 141.See Setting Rule States for more information.

See the following sections for more information:

- Selecting IMAP Preprocessor Options

- Configuring the IMAP Preprocessor

- Enabling Additional IMAP Preprocessor Rules

Selecting IMAP Preprocessor Options

License: Protection

The following list describes the IMAP preprocessor options you can modify.

Note that decoding, or extraction when the MIME email attachment does not require decoding, includes multiple attachments when present, and large attachments that span multiple packets.

Note also that the highest value is used when the values for the Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth options are different in:

- the default network analysis policy

- any other custom network analysis policy invoked by network analysis rules in the same access control policy

See Setting the Default Network Analysis Policy for Access Control and Specifying Traffic to Preprocess Using Network Analysis Rules for more information.

Caution Changing the value for Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Ports

Specifies the ports to inspect for IMAP traffic. You can specify an integer from 0 to 65535. Separate multiple port numbers with commas.

Base64 Decoding Depth

Specifies the maximum number of bytes to extract and decode from each Base64 encoded MIME email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all the Base64 data. Specify -1 to ignore Base64 data.

Note that positive values not divisible by 4 are rounded up to the next multiple of 4 except for the values 65533, 65534, and 65535, which are rounded down to 65532.

When Base64 decoding is enabled, you can enable rule 141:4 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data.

7-Bit/8-Bit/Binary Decoding Depth

Specifies the maximum bytes of data to extract from each MIME email attachment that does not require decoding. These attachment types include 7-bit, 8-bit, binary, and various multipart content types such as plain text, jpeg images, mp3 files, and so on. You can specify from 1 to 65535 bytes, or specify 0 to extract all data in the packet. Specify -1 to ignore non-decoded data.

Quoted-Printable Decoding Depth

Specifies the maximum number of bytes to extract and decode from each quoted-printable (QP) encoded MIME email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all QP encoded data in the packet. Specify -1 to ignore QP encoded data.

When quoted-printable decoding is enabled, you can enable rule 141:6 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data.

Unix-to-Unix Decoding Depth

Specifies the maximum number of bytes to extract and decode from each Unix-to-Unix encoded (uuencoded) email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all uuencoded data in the packet. Specify -1 to ignore uuencoded data.

When Unix-to-Unix decoding is enabled, you can enable rule 141:7 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data.

Configuring the IMAP Preprocessor

License: Protection

Use the following procedure to configure the IMAP preprocessor. For additional information on IMAP preprocessor configuration options, see Selecting IMAP Preprocessor Options.

To configure the IMAP preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether IMAP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The IMAP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Specify the Ports where IMAP traffic should be decoded. Separate multiple port numbers with commas.

Step 6 Specify the maximum bytes of data to extract and decode from any combination of the following email attachment types:

- Base64 Decoding Depth

- 7-Bit/8-Bit/Binary Decoding Depth (includes various multipart content types such as plain text, jpeg images, mp3 files, and so on)

- Quoted-Printable Decoding Depth

- Unix-to-Unix Decoding Depth

For each type, you can specify from 1 to 65535 bytes, or specify 0 to extract and, when necessary, decode all data in the packet. Specify -1 to ignore data for an attachment type.

You can use the file_data rule keyword in intrusion rules to inspect the attachment data. See Pointing to a Specific Payload Type for more information.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Enabling Additional IMAP Preprocessor Rules

License: Protection

The IMAP preprocessor rules in the following table are not associated with specific configuration options. As with other IMAP preprocessor rules, you must enable these rules if you want them to generate events. See Setting Rule States for information on enabling rules.

Table 27-12 Additional IMAP Preprocessor Rules

Preprocessor Rule GID:SID

Description

141:1

Generates an event when the preprocessor detects a client command that is not defined in RFC 3501.

141:2

Generates an event when the preprocessor detects a server response that is not defined in RFC 3501.

141:3

Generates an event when the preprocessor is using the maximum amount of memory allowed by the system. At this point, the preprocessor stops decoding until memory becomes available.

Decoding POP Traffic

License: Protection

The Post Office Protocol (POP) is used to retrieve email from a remote POP mail server. The POP preprocessor inspects server-to-client POP3 traffic and, when associated preprocessor rules are enabled, generates events on anomalous traffic. The preprocessor can also extract and decode email attachments in client-to-server POP3 traffic and send the attachment data to the rules engine. You can use the file_data keyword in an intrusion rule to point to attachment data. See Pointing to a Specific Payload Type for more information.

Extraction and decoding include multiple attachments, when present, and large attachments that span multiple packets.

If you want POP preprocessor rules to generate events, you must enable the rules. POP preprocessor rules have a generator ID (GID) of 142. See Setting Rule States for more information.

See the following sections for more information:

- Selecting POP Preprocessor Options

- Configuring the POP Preprocessor

- Enabling Additional POP Preprocessor Rules

Selecting POP Preprocessor Options

License: Protection

The following list describes the POP preprocessor options you can modify.

Note that decoding, or extraction when the MIME email attachment does not require decoding, includes multiple attachments when present, and large attachments that span multiple packets.

Note also that when the values for the Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth options are different in an intrusion policy associated with the default action of an access control policy and intrusion policies associated with access control rules, the highest value is used.

Caution Changing the value for Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Ports

Specifies the ports to inspect for POP traffic. You can specify an integer from 0 to 65535. Separate multiple port numbers with commas.

Base64 Decoding Depth

Specifies the maximum number of bytes to extract and decode from each Base64 encoded MIME email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all the Base64 data. Specify -1 to ignore Base64 data.

Note that positive values not divisible by 4 are rounded up to the next multiple of 4 except for the values 65533, 65534, and 65535, which are rounded down to 65532.

When Base64 decoding is enabled, you can enable rule 142:4 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

7-Bit/8-Bit/Binary Decoding Depth

Specifies the maximum bytes of data to extract from each MIME email attachment that does not require decoding. These attachment types include 7-bit, 8-bit, binary, and various multipart content types such as plain text, jpeg images, mp3 files, and so on. You can specify from 1 to 65535 bytes, or specify 0 to extract all data in the packet. Specify -1 to ignore non-decoded data.

Quoted-Printable Decoding Depth

Specifies the maximum number of bytes to extract and decode from each quoted-printable (QP) encoded MIME email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all QP encoded data in the packet. Specify -1 to ignore QP encoded data.

When quoted-printable decoding is enabled, you can enable rule 142:6 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

Unix-to-Unix Decoding Depth

Specifies the maximum number of bytes to extract and decode from each Unix-to-Unix encoded (uuencoded) email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all uuencoded data in the packet. Specify -1 to ignore uuencoded data.

When Unix-to-Unix decoding is enabled, you can enable rule 142:7 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

Configuring the POP Preprocessor

License: Protection

Use the following procedure to configure the POP preprocessor. For additional information on POP preprocessor configuration options, see Selecting POP Preprocessor Options.

To configure the POP preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether POP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The POP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Specify the Ports where IMAP traffic should be decoded. Separate multiple port numbers with commas.

Step 6 Specify the maximum bytes of data to extract and decode from any combination of the following email attachment types:

- Base64 Decoding Depth

- 7-Bit/8-Bit/Binary Decoding Depth (includes various multipart content types such as plain text, jpeg images, mp3 files, and so on)

- Quoted-Printable Decoding Depth

- Unix-to-Unix Decoding Depth

For each type, you can specify from 1 to 65535 bytes, or specify 0 to extract and, when necessary, decode all data in the packet. Specify -1 to ignore data for an attachment type.

You can use the file_data rule keyword in intrusion rules to inspect the attachment data. See Pointing to a Specific Payload Type for more information.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Enabling Additional POP Preprocessor Rules

License: Protection

The POP preprocessor rules in the following table are not associated with specific configuration options. As with other POP preprocessor rules, you must enable these rules if you want them to generate events. See Setting Rule States for information on enabling rules.

Table 27-13 Additional POP Preprocessor Rules

Preprocessor Rule GID:SID

Description

142:1

Generates an event when the preprocessor detects a client command that is not defined in RFC 1939.

142:2

Generates an event when the preprocessor detects a server response that is not defined in RFC 1939.

142:3

Generates an event when the preprocessor is using the maximum amount of memory allowed by the system. At this point, the preprocessor stops decoding until memory becomes available.

Decoding SMTP Traffic

License: Protection

The SMTP preprocessor instructs the rules engine to normalize SMTP commands. The preprocessor can also extract and decode email attachments in client-to-server traffic and, depending on the software version, extract email file names, addresses, and header data to provide context when displaying intrusion events triggered by SMTP traffic.

Note the following when using the SMTP preprocessor:

- You must enable SMTP preprocessor rules, which have a generator ID (GID) of 124, if you want these rules to generate events. See Setting Rule States for more information.

For more information, see the following sections:

- Understanding SMTP Decoding

- Configuring SMTP Decoding

- Enabling SMTP Maximum Decoding Memory Alerting

Understanding SMTP Decoding

License: Protection

You can enable or disable normalization, and you can configure options to control the types of anomalous traffic the SMTP decoder detects.

Note that decoding, or extraction when the MIME email attachment does not require decoding, includes multiple attachments when present, and large attachments that span multiple packets.

Note also that when the values for the Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth options are different in an intrusion policy associated with the default action of an access control policy and intrusion policies associated with access control rules, the highest value is used.

Caution Changing the value for Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, or Unix-to-Unix Decoding Depth restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Ports

Specifies the ports whose SMTP traffic you want to normalize. You can specify an integer from 0 to 65535. Separate multiple ports with commas.

Stateful Inspection

When selected, causes SMTP decoder to save state and provide session context for individual packets and only inspects reassembled sessions. When cleared, analyzes each individual packet without session context.

Normalize

When set to All, normalizes all commands. Checks for more than one space character after a command.

When set to None, normalizes no commands.

When set to Cmds, normalizes the commands listed in Custom Commands.

Custom Commands

When Normalize is set to Cmds, normalizes the listed commands.

Specify commands which should be normalized in the text box. Checks for more than one space character after a command.

The space (ASCII 0x20) and tab (ASCII 0x09) characters count as space characters for normalization purposes.

Ignore Data

Does not process mail data; processes only MIME mail header data.

Ignore TLS Data

Does not process data encrypted under the Transport Layer Security protocol.

No Alerts

Disables intrusion events when accompanying preprocessor rules are enabled.

Detect Unknown Commands

Detects unknown commands in SMTP traffic.

You can enable rules 124:5 and 124:6 to generate events for this option. See Setting Rule States for more information.

Max Command Line Len

Detects when an SMTP command line is longer than this value. Specify 0 to never detect command line length.

RFC 2821, the Network Working Group specification on the Simple Mail Transfer Protocol, recommends 512 as a maximum command line length.

You can enable rule 124:1 to generate events for this option. See Setting Rule States for more information.

Max Header Line Len

Detects when an SMTP data header line is longer than this value. Specify 0 to never detect data header line length.

You can enable rules 124:2 and 124:7 to generate events for this option. See Setting Rule States for more information.

Max Response Line Len

Detects when an SMTP response line is longer than this value. Specify 0 to never detect response line length.

RFC 2821 recommends 512 as a maximum response line length.

You can enable rule 124:3 to generate events for this option. See Setting Rule States for more information.

Alt Max Command Line Len

Detects when the SMTP command line for any of the specified commands is longer than this value. Specify 0 to never detect command line length for the specified commands. Different default line lengths are set for numerous commands.

This setting overrides the Max Command Line Len setting for the specified commands.

You can enable rule 124:3 to generate events for this option. See Setting Rule States for more information.

Invalid Commands

Detects if these commands are sent from the client side.

You can enable rule 124:5 and 124:6 to generate events for this option. See Setting Rule States for more information.

Valid Commands

Permits commands in this list.

Even if this list is empty, the preprocessor permits the following valid commands: ATRN AUTH BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL NOOP ONEX QUEU QUIT RCPT RSET SAML SEND SIZE SOML STARTTLS TICK TIME TURN TURNME VERB VRFY XADR XAUTH XCIR XEXCH50 X-EXPS XGEN XLICENSE X-LINK2STATE XQUE XSTA XTRN XUSR

Note RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps RCPT and MAIL to the correct command name.

You can enable rule 124:4 to generate events for this option. See Setting Rule States for more information.

Data Commands

Lists commands that initiate sending data in the same way the SMTP DATA command sends data per RFC 5321. Separate multiple commands with spaces.

Binary Data Commands

Lists commands that initiate sending data in a way that is similar to how the BDAT command sends data per RFC 3030. Separate multiple commands with spaces.

Authentication Commands

Lists commands that initiate an authentication exchange between client and server. Separate multiple commands with spaces.

Detect xlink2state

Detects packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks. In inline deployments, the system can also drop those packets.

You can enable rule 124:8 to generate events for this option. See Setting Rule States for more information.

Base64 Decoding Depth

When Ignore Data is disabled, specifies the maximum number of bytes to extract and decode from each Base64 encoded MIME email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all the Base64 data. Specify -1 to ignore Base64 data. The preprocessor will not decode data when Ignore Data is selected.

Note that positive values not divisible by 4 are rounded up to the next multiple of 4 except for the values 65533, 65534, and 65535, which are rounded down to 65532.

When Base64 decoding is enabled, you can enable rule 124:10 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

Note that this option replaces the deprecated options Enable MIME Decoding and Maximum MIME Decoding Depth, which are still supported in existing intrusion policies for backward compatibility.

7-Bit/8-Bit/Binary Decoding Depth

When Ignore Data is disabled, specifies the maximum bytes of data to extract from each MIME email attachment that does not require decoding. These attachment types include 7-bit, 8-bit, binary, and various multipart content types such as plain text, jpeg images, mp3 files, and so on. You can specify from 1 to 65535 bytes, or specify 0 to extract all data in the packet. Specify -1 to ignore non-decoded data. The preprocessor will not extract data when Ignore Data is selected.

Quoted-Printable Decoding Depth

When Ignore Data is disabled, specifies the maximum number of bytes to extract and decode from each quoted-printable (QP) encoded MIME email attachment.

You can specify from 1 to 65535 bytes, or specify 0 to decode all QP encoded data in the packet. Specify -1 to ignore QP encoded data. The preprocessor will not decode data when Ignore Data is selected.

When quoted-printable decoding is enabled, you can enable rule 124:11 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

Unix-to-Unix Decoding Depth

When Ignore Data is disabled, specifies the maximum number of bytes to extract and decode from each Unix-to-Unix encoded (uuencoded) email attachment. You can specify from 1 to 65535 bytes, or specify 0 to decode all uuencoded data in the packet. Specify -1 to ignore uuencoded data. The preprocessor will not decode data when Ignore Data is selected.

When Unix-to-Unix decoding is enabled, you can enable rule 124:13 to generate an event when decoding fails; decoding could fail, for example, because of incorrect encoding or corrupted data. See Setting Rule States for more information.

Log MIME Attachment Names

Enables extraction of MIME attachment file names from the MIME Content-Disposition header and associates the file names with all intrusion events generated for the session. Multiple file names are supported.

When this option is enabled, you can view file names associated with events in the Email Attachment column of the intrusion events table view. See Understanding Intrusion Events for more information.

Log To Addresses

Enables extraction of recipient email addresses from the SMTP RCPT TO command and associates the recipient addresses with all intrusion events generated for the session. Multiple recipients are supported.

When this option is enabled, you can view recipients associated with events in the Email Recipient column of the intrusion events table view. See Understanding Intrusion Events for more information.

Log From Addresses

Enables extraction of sender email addresses from the SMTP MAIL FROM command and associates the sender addresses with all intrusion events generated for the session. Multiple sender addresses are supported.

When this option is enabled, you can view senders associated with events in the Email Sender column of the intrusion events table view. See Understanding Intrusion Events for more information.

Log Headers

Enables extraction of email headers. The number of bytes to extract is determined by the value specified for Header Log Depth.

You can use the content or protected_content keyword to write intrusion rules that use email header data as a pattern. You can also view the extracted email header in the intrusion event packet view. See Constraining Content Matches and Using the Packet View for more information.

Header Log Depth

Specifies the number of bytes of the email header to extract when Log Headers is enabled. You can specify 0 to 20480 bytes. A value of 0 disables Log Headers.

Configuring SMTP Decoding

License: Protection

You can use the SMTP Configuration page of an intrusion policy to configure SMTP normalization. For more information on SMTP preprocessor configuration options, see Understanding SMTP Decoding.

To configure SMTP decoding options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether SMTP Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The SMTP Configuration page appears. The following graphic shows the Defense Center packet view. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Specify the Ports where SMTP traffic should be decoded, separated by commas.

Step 6 Select Stateful Inspection to examine reassembled TCP streams containing SMTP packets. Clear Stateful Inspection to inspect only unreassembled SMTP packets.

Step 7 Configure the normalization options:

- To normalize all commands, select All .

- To normalize only commands specified by Custom Commands , select Cmds and specify the commands to normalize. Separate commands with spaces.

- To normalize no commands, select None .

- To ignore mail data except for MIME mail header data, check Ignore Data .

- To ignore data encrypted under the Transport Security Layer protocol, check Ignore TLS Data .

- To disable generating events when accompanying preprocessor rules are enabled, check No Alerts .

- To detect unknown commands in SMTP data, select Detect Unknown Commands .

Step 8 Specify a maximum command line length in the Max Command Line Len field.

Step 9 Specify a maximum data header line length in the Max Header Line Len field.

Step 10 Specify a maximum response line length in the Max Response Line Len field.

Note RCPT TO and MAIL FROM are SMTP commands. The preprocessor configuration uses command names of RCPT and MAIL, respectively. Within the code, the preprocessor maps RCPT and MAIL to the correct command name.

Step 11 If needed, click Add next to Alt Max Command Line Len to add commands where you want to specify an alternate maximum command line length, then specify the line length and the command or commands, separated by spaces, where you want that length to be enforced.

Step 12 Specify any commands that you want to treat as invalid and detect in the Invalid Commands field. Separate commands with spaces.

Step 13 Specify any commands that you want to treat as valid in the Valid Commands field. Separate commands with spaces.

Note Even if the Valid Commands list is empty, the preprocessor treats the following commands as valid: ATRN, AUTH, BDAT, DATA, DEBUG, EHLO, EMAL, ESAM, ESND, ESOM, ETRN, EVFY, EXPN, HELO, HELP, IDENT, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SOML, SEND, ONEX, QUEU, STARTTLS, TICK, TIME, TURN, TURNME, VERB, VRFY, X-EXPS, X-LINK2STATE, XADR, XAUTH, XCIR, XEXCH50, XGEN, XLICENSE, XQUE, XSTA, XTRN, or XUSR.

Step 14 Specify any commands that you want to initiate sending data in the same way the SMTP DATA command sends data per RFC 5321 in the Data Commands field. Separate commands with spaces.

Step 15 Specify any commands that initiate sending data in a way that is similar to how the BDAT command sends data per RFC 3030 in the Binary Data Commands field. Separate commands with spaces.

Step 16 Specify any commands that initiate an authentication exchange between client and server in the Authentication Commands field. Separate commands with spaces.

Step 17 To detect packets that are part of X-Link2State Microsoft Exchange buffer data overflow attacks, select Detect xlink2state.

Step 18 To specify the maximum bytes of data to extract and decode for different types of email attachment, specify a value for any of the following attachment types:

- Base64 Decoding Depth

- 7-Bit/8-Bit/Binary Decoding Depth (includes various multipart content types such as plain text, jpeg images, mp3 files, and so on)

- Quoted-Printable Decoding Depth

- Unix-to-Unix Decoding Depth

You can specify from 1 to 65535 bytes, or specify 0 to extract and, when necessary, decode all data in the packet for that type. Specify -1 to ignore data for an attachment type.

You can use the file_data rule keyword in intrusion rules to inspect extracted data. See Pointing to a Specific Payload Type for more information.

You must also select the SMTP Stateful Inspection option to extract and decode cross-packet data or data crossing multiple TCP segments.

Step 19 Configure options for associating contextual information with intrusion events triggered by SMTP traffic:

- To enable extraction of MIME attachment file names to associate with intrusion events, select Log MIME Attachment Names .

- To enable extraction of recipient email addresses, select Log To Addresses .

- To enable extraction of sender email addresses to associate with intrusion events, select Log From Addresses .

- To enable extraction of email headers to associate with intrusion events and for writing rules that inspect email headers, select Log Headers .

Note that header information is displayed in the intrusion event packet view. Note also that you can also write intrusion rules that use the content or protected_content keyword with email header data as a pattern. See Viewing Event Information and Searching for Content Matches for more information.

Optionally, you can specify a Header Log Depth of 0 to 20480 bytes of the email header to extract. A value of 0 disables Log Headers.

Step 20 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Enabling SMTP Maximum Decoding Memory Alerting

License: Protection

You can enable SMTP preprocessor rule 124:9 to generate an event when the enabled preprocessor is using the maximum amount of memory allowed by the system for decoding the following types of encoded data:

- Base64

- 7-bit/8-bit/binary

- Quoted-printable

- Unix-to-Unix

When the maximum decoding memory is exceeded, the preprocessor stops decoding these types of encoded data until memory becomes available. This preprocessor rule is not associated with a single, specific configuration option. See Setting Rule States for information on enabling rules.

Detecting Exploits Using the SSH Preprocessor

License: Protection

The SSH preprocessor detects the Challenge-Response Buffer Overflow exploit, the CRC-32 exploit, the SecureCRT SSH Client Buffer Overflow exploit, protocol mismatches, and incorrect SSH message direction. The preprocessor also detects any version string other than version 1 or 2.

Challenge-Response Buffer Overflow and CRC-32 attacks occur after the key exchange and are, therefore, encrypted. Both attacks send an uncharacteristically large payload of more than 20 KBytes to the server immediately after the authentication challenge. CRC-32 attacks apply only to SSH Version 1; Challenge-Response Buffer Overflow exploits apply only to SSH Version 2. The version string is read at the beginning of the session. Except for the difference in the version string, both attacks are handled in the same way.

The SecureCRT SSH exploit and protocol mismatch attacks occur when attempting to secure a connection, before the key exchange. The SecureCRT exploit sends an overly long protocol identifier string to the client that causes a buffer overflow. A protocol mismatch occurs when either a non-SSH client application attempts to connect to a secure SSH server or the server and client version numbers do not match.

You can configure the preprocessor to inspect traffic on a specified port or list of ports, or to automatically detect SSH traffic. It will continue to inspect SSH traffic until either a specified number of encrypted packets has passed within a specified number of bytes, or until a specified maximum number of bytes is exceeded within the specified number of packets. If the maximum number of bytes is exceeded, it is assumed that a CRC-32 (SSH Version 1) or a Challenge-Response Buffer Overflow (SSH Version 2) attack has occurred. Additionally, you can detect the SecureCRT exploit, protocol mismatches, and bad message direction. Note that the preprocessor detects without configuration any version string value other than version 1 or 2.

Note the following when using the SSH preprocessor:

- You must enable SSH preprocessor rules, which have a generator ID (GID) of 128, if you want these rules to generate events. See Setting Rule States for more information.

- The SSH preprocessor does not handle brute force attacks. For information on brute force attempts, see Adding Dynamic Rule States.

See the following sections for more information:

- Selecting SSH Preprocessor Options

- Configuring the SSH Preprocessor

Selecting SSH Preprocessor Options

License: Protection

This section describes the options you can use to configure the SSH preprocessor.

The preprocessor stops inspecting traffic for a session when either of the following occurs:

- a valid exchange between the server and the client has occurred for this number of encrypted packets; the connection continues.

- the Number of Bytes Sent Without Server Response is reached before the number of encrypted packets to inspect is reached; the assumption is made that there is an attack.

Each valid server response during Number of Encrypted Packets to Inspect resets the Number of Bytes Sent Without Server Response and the packet count continues.

Consider the following example SSH preprocessor configuration:

- Server Ports : 22

- Autodetect Ports : off

- Maximum Length of Protocol Version String : 80

- Number of Encrypted Packets to Inspect : 25

- Number of Bytes Sent Without Server Response : 19,600

- All detect options are enabled.

In the example, the preprocessor inspects traffic only on port 22. That is, auto-detection is disabled, so it inspects only on the specified port.

Additionally, the preprocessor in the example stops inspecting traffic when either of the following occurs:

- The client sends 25 encrypted packets which contain no more than 19,600 bytes, cumulative. The assumption is there is no attack.

- The client sends more than 19,600 bytes within 25 encrypted packets. In this case, the preprocessor considers the attack to be the Challenge-Response Buffer Overflow exploit because the session in the example is an SSH Version 2 session.

The preprocessor in the example will also detect any of the following that occur while it is processing traffic:

- a server overflow, triggered by a version string greater than 80 bytes and indicating a SecureCRT exploit

- a protocol mismatch

- a packet flowing in the wrong direction

Finally, the preprocessor will automatically detect any version string other than version 1 or version 2.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Server Ports

Specifies on which ports the SSH preprocessor should inspect traffic.

You can configure a single port or a comma-separated list of ports.

Autodetect Ports

Sets the preprocessor to automatically detect SSH traffic.

When this option is selected, the preprocessor inspects all traffic for an SSH version number. It stops processing when neither the client nor the server packet contains a version number. When disabled, the preprocessor inspects only the traffic identified by the Server Ports option.

Number of Encrypted Packets to Inspect

Specifies the number of encrypted packets to examine per session.

Setting this option to zero will allow all traffic to pass.

Reducing the number of encrypted packets to inspect may result in some attacks escaping detection. Raising the number of encrypted packets to inspect may negatively affect performance.

Number of Bytes Sent Without Server Response

Specifies the maximum number of bytes an SSH client may send to a server without getting a response before assuming there is a Challenge-Response Buffer Overflow or CRC-32 attack.

Increase the value for this option if the preprocessor generates false positives on the Challenge-Response Buffer Overflow or CRC-32 exploit.

Maximum Length of Protocol Version String

Specifies the maximum number of bytes allowed in the server’s version string before considering it to be a SecureCRT exploit.

Detect Challenge-Response Buffer Overflow Attack

Enables or disables detecting the Challenge-Response Buffer Overflow exploit.

You can enable rule 128:1 to generate events for this option. See Setting Rule States for more information.

Detect SSH1 CRC-32 Attack

Enables or disables detecting the CRC-32 exploit.

You can enable rule 128:2 to generate events for this option. See Setting Rule States for more information.

Detect Server Overflow

Enables or disables detecting the SecureCRT SSH Client Buffer Overflow exploit.

You can enable rule 128:3 to generate events for this option. See Setting Rule States for more information.

Detect Protocol Mismatch

Enables or disables detecting protocol mismatches.

You can enable rule 128:4 to generate events for this option. See Setting Rule States for more information.

Detect Bad Message Direction

Enables or disables detecting when traffic flows in the wrong direction (that is, if the presumed server generates client traffic, or if a client generates server traffic).

You can enable rule 128:5 to generate events for this option. See Setting Rule States for more information.

Detect Payload Size Incorrect for the Given Payload

Enables or disables detecting packets with an incorrect payload size such as when the length specified in the SSH packet is not consistent with the total length specified in the IP header or the message is truncated, that is, there is not enough data for a full SSH header.

You can enable rule 128:6 to generate events for this option. See Setting Rule States for more information.

Detect Bad Version String

Note that, when enabled, the preprocessor detects without configuration any version string other than version 1 or 2.

You can enable rule 128:7 to generate events for this option. See Setting Rule States for more information.

Configuring the SSH Preprocessor

License: Protection

This section explains how to configure the SSH preprocessor.

To configure the SSH preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether SSH Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The SSH Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can modify any of the options on the SSH Configuration preprocessor page. See Selecting SSH Preprocessor Options for more information.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Using the SSL Preprocessor

License: feature-dependent

The SSL preprocessor allows you to configure SSL inspection, which can block encrypted traffic, decrypt it, or inspect the traffic with access control. Whether you configure SSL inspection, the SSL preprocessor also analyzes SSL handshake messages when detected in traffic and determines when a session becomes encrypted. Identifying encrypted traffic allows the system to stop intrusion and file inspection of encrypted payloads, which helps reduce false positives and improve performance. See Understanding Traffic Decryption and Creating and Editing Access Control Rules for more information.

The SSL preprocessor can also examine encrypted traffic to detect attempts to exploit the Heartbleed bug, and generate events when it detects such exploits.

Using the SSL preprocessor to decrypt encrypted traffic does not require a license. All other SSL preprocessor functionality, including halting inspection of encrypted payloads for malware and intrusions, and detecting Heartbleed bug exploits, requires a Protection license.

Note The system-provided network analysis policies enable the SSL preprocessor by default. Cisco recommends you do not disable the SSL preprocessor in custom deployments if you expect encrypted traffic to cross your network.

For more information, see the following sections:

- Understanding SSL Preprocessing

- Enabling SSL Preprocessor Rules

- Configuring the SSL Preprocessor

Understanding SSL Preprocessing

License: Protection

The SSL preprocessor stops intrusion and file inspection of encrypted data, and inspects encrypted traffic with an SSL policy if you configure SSL inspection. This can help to eliminate false positives. The SSL preprocessor maintains state information as it inspects the SSL handshake, tracking both the state and SSL version for that session. When the preprocessor detects that a session state is encrypted, the system marks the traffic in that session as encrypted. You can configure the system to stop processing on all packets in an encrypted session when encryption is established, as well as generate an event when it detects an attempt to exploit the Heartbleed bug.

For each packet, the SSL preprocessor verifies that the traffic contains an IP header, a TCP header, and a TCP payload, and that it occurs on the ports specified for SSL preprocessing. For qualifying traffic, the following scenarios determine whether the traffic is encrypted:

- the system observes all packets in a session, Server side data is trusted is not enabled, and the session includes a Finished message from both the server and the client and at least one packet from each side with an Application record and without an Alert record

- the system misses some of the traffic, Server side data is trusted is not enabled, and the session includes at least one packet from each side with an Application record that is not answered with an Alert record

- the system observes all packets in a session, Server side data is trusted is enabled, and the session includes a Finished message from the client and at least one packet from the client with an Application record and without an Alert record

- the system misses some of the traffic, Server side data is trusted is enabled, and the session includes at least one packet from the client with an Application record that is not answered with an Alert record

If you choose to stop processing on encrypted traffic, the system ignores future packets in a session after it marks the session as encrypted.

In addition, during the SSL handshake, the preprocessor monitors heartbeat requests and responses. The preprocessor generates an event if it detects:

- a heartbeat request containing a payload length value greater than the payload itself

- a heartbeat response that is larger than the value stored in the Max Heartbeat Length field

Note You can add the ssl_state and ssl_version keywords to a rule to use SSL state or version information within the rule. For more information, see Extracting SSL Information from a Session.

Enabling SSL Preprocessor Rules

License: Protection

When enabled, the SSL preprocessor inspects the contents of the handshake and key exchange messages exchanged at the beginning of an SSL session. You can suspend inspecting traffic for intrusions and malware once the session is encrypted. If you configure SSL inspection, the SSL preprocessor also identifies encrypted traffic you can block, decrypt, or inspect with access control.

Note that you must enable SSL preprocessor rules, which have a generator ID (GID) of 137, if you want these rules to generate events. See Setting Rule States for more information.

The following table describes the SSL preprocessor rules you can enable.

Table 27-14 SSL Preprocessor Rules

Preprocessor Rule GID:SID

Description

137:1

Detects a client hello after a server hello, which is invalid and considered to be anomalous behavior.

137:2

Detects a server hello without a client hello when Server side data is trusted is disabled, which is invalid and considered to be anomalous behavior. See Configuring the SSL Preprocessor for more information.

137:3

Detects a heartbeat request with a payload length greater than the payload itself when Max Heartbeat Length contains a non-zero value, which indicates an attempt to exploit the Heartbleed bug.

137:4

Detects a heartbeat response larger than a non-zero value specified in Max Heartbeat Length, which indicates an attempt to exploit the Heartbleed bug.

Configuring the SSL Preprocessor

License: Protection

Without SSL inspection configured, the system attempts to inspect encrypted traffic for malware and intrusions without decrypting it. When you enable the SSL preprocessor, it detects when a session becomes encrypted. After the SSL preprocessor is enabled, the rules engine can invoke the preprocessor to obtain SSL state and version information. If you enable rules using the ssl_state and ssl_version keywords in an intrusion policy, you should also enable the SSL preprocessor in that policy.

In addition, you can enable the Stop inspecting encrypted traffic option to disable inspection and reassembly for encrypted sessions. The SSL preprocessor maintains state for the session so it can disable inspection of all traffic in the session. The system only stops inspecting traffic in encrypted sessions if SSL preprocessing is enabled and the Stop inspecting encrypted traffic option is selected. Note that if you clear the Stop inspecting encrypted traffic option, you cannot modify the Server side data is trusted option.

To base identification of encrypted traffic only on server traffic, you can enable the Server side data is trusted option; that is, server side data is trusted to indicate that the traffic is encrypted. The SSL preprocessor typically checks both client traffic and the server responses to that traffic to determine if a session is encrypted. However, because the system may not mark a transaction as encrypted if it cannot detect both sides of a session, you can rely on the SSL server to indicate a session is encrypted. Note that when you enable the Server side data is trusted option you must also enable the Stop inspecting encrypted traffic option so the system does not continue inspecting traffic in the encrypted session.

You can configure the preprocessor Max Heartbeat Length option to detect attempts to exploit the Heartbleed bug by examining heartbeat requests and responses within the SSL handshake. If the preprocessor detects a heartbeat request whose payload length is greater than the actual payload length, or a heartbeat response greater in size than the Max Heartbeat Length value, the preprocessor generates an event.

You can specify the ports where the preprocessor monitors traffic for encrypted sessions.

Note If the SSL preprocessor detects non-SSL traffic over the ports specified for SSL monitoring, it tries to decode the traffic as SSL traffic, and then flags it as corrupt.

To configure the SSL preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether SSL Configuration under Application Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The SSL Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Type the ports, separated by commas, where the SSL preprocessor should monitor traffic for encrypted sessions. Only ports included in the Ports field will be checked for encrypted traffic.

Step 6 Click the Stop inspecting encrypted traffic check box to enable or disable inspection of traffic in a session after the session is marked as encrypted.

Step 7 Click the Server side data is trusted check box to enable or disable identification of encrypted traffic based only on the client-side traffic.

Step 8 Enter a number of bytes in the Max Heartbeat Length field to enable inspection of heartbeat requests and responses within the SSL handshake for Heartbleed bug exploit attempts. You can specify an integer from 1 to 65535, or 0 to disable the option.

Step 9 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Configuring SCADA Preprocessing

You configure Supervisory Control and Data Acquisition (SCADA) preprocessors in a network analysis policy, which prepares traffic for inspection using the rules enabled in an intrusion policy. See Understanding Network Analysis and Intrusion Policies for more information.

SCADA protocols monitor, control, and acquire data from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment, electric power distribution, airport and shipping systems, and so on. The FireSIGHT System provides preprocessors for the Modbus and DNP3 SCADA protocols that you can configure as part of your network analysis policy.

Caution Some users with custom user roles cannot access the network analysis policy via the standard menu path ( Policies > Access Control > Network Analysis Policy). These users can access the network analysis policy through the intrusion policy: Policies > Intrusion > Intrusion Policy > Network Analysis Policy. For more information on custom user roles, see Managing Custom User Roles.

If you enable a rule containing Modbus or DNP3 keywords in the corresponding intrusion policy, the system automatically uses the Modbus or DNP3 processor, respectively, with its current settings, although the preprocessor remains disabled in the network analysis policy web interface. For more information, see Modbus Keywords and DNP3 Keywords.

See the following sections for more information:

- Configuring the Modbus Preprocessor

- Configuring the DNP3 Preprocessor

- Configuring the CIP Preprocessor

Configuring the Modbus Preprocessor

License: Protection

The Modbus protocol, which was first published in 1979 by Modicon, is a widely used SCADA protocol. The Modbus preprocessor detects anomalies in Modbus traffic and decodes the Modbus protocol for processing by the rules engine, which uses Modbus keywords to access certain protocol fields. See Modbus Keywords for more information.

A single configuration option allows you to modify the default setting for the port that the preprocessor inspects for Modbus traffic.

You must enable the Modbus preprocessor rules in the following table if you want these rules to generate events. See Setting Rule States for information on enabling rules.

Table 28-1 Modbus Preprocessor Rules

Preprocessor Rule GID:SID

Description

144:1

Generates an event when the length in the Modbus header does not match the length required by the Modbus function code.

Each Modbus function has an expected format for requests and responses. If the length of the message does not match the expected format, this event is generated.

144:2

Generates an event when the Modbus protocol ID is non-zero. The protocol ID field is used for multiplexing other protocols with Modbus. Because the preprocessor does not process these other protocols, this event is generated instead.

144:3

Generates an event when the preprocessor detects a reserved Modbus function code.

Note regarding the use of the Modbus preprocessor that if your network does not contain any Modbus-enabled devices, you should not enable this preprocessor in a network analysis policy that you apply to traffic.

You can use the following procedure to modify the ports the Modbus preprocessor monitors.

To configure the Modbus preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether Modbus Configuration under SCADA Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Modbus Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, modify the Ports that the preprocessor inspects for Modbus traffic. You can specify an integer from 0 to 65535. Use commas to separate multiple ports.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Configuring the DNP3 Preprocessor

License: Protection

The Distributed Network Protocol (DNP3) is a SCADA protocol that was originally developed to provide consistent communication between electrical stations. DNP3 has also become widely used in the water, waste, transportation, and many other industries.

The DNP3 preprocessor detects anomalies in DNP3 traffic and decodes the DNP3 protocol for processing by the rules engine, which uses DNP3 keywords to access certain protocol fields. See DNP3 Keywords for more information.

You must enable the DNP3 preprocessor rules in the following table if you want these rules to generate events. See Setting Rule States for information on enabling rules.

Table 28-2 DNP3 Preprocessor Rules

Preprocessor Rule GID:SID

Description

145:1

When Log bad CRC is enabled, generates an event when the preprocessor detects a link layer frame with an invalid checksum.

145:2

Generates an event and blocks the packet when the preprocessor detects a DNP3 link layer frame with an invalid length.

145:3

Generates an event and blocks the packet during reassembly when the preprocessor detects a transport layer segment with an invalid sequence number.

145:4

Generates an event when the DNP3 reassembly buffer is cleared before a complete fragment can be reassembled. This happens when a segment carrying the FIR flag appears after other segments have been queued.

145:5

Generates an event when the preprocessor detects a DNP3 link layer frame that uses a reserved address.

145:6

Generates an event when the preprocessor detects a DNP3 request or response that uses a reserved function code.

Note regarding the use of the DNP3 preprocessor that, if your network does not contain any DNP3-enabled devices, you should not enable this preprocessor in a network analysis policy that you apply to traffic. See Configuring TCP Stream Preprocessing for more information.

The following list describes the DNP3 preprocessor options you can configure.

Ports

Enables inspection of DNP3 traffic on each specified port. You can specify a single port or a comma-separated list of ports. You can specify a value from 0 to 65535 for each port.

Log bad CRCs

When enabled, validates the checksums contained in DNP3 link layer frames. Frames with invalid checksums are ignored.

You can enable rule 145:1 to generate events when invalid checksums are detected.

To configure the DNP3 preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether DNP3 Configuration under SCADA Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The DNP3 Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, modify the Ports that the preprocessor inspects for DNP3 traffic. You can specify an integer from 0 to 65535. Use commas to separate multiple ports.

Step 6 Optionally, select or clear the Log bad CRCs check box to specify whether to validate the checksums contained in DNP3 link layer frames and ignore frames with invalid checksums.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See the Network Analysis Policy Editing Actions table for more information.

Configuring the CIP Preprocessor

License: Protection

The Common Industrial Protocol (CIP) is a widely used application protocol that supports industrial automation applications. EtherNet/IP is an implementation of CIP that is used on Ethernet-based networks.

The CIP preprocessor detects CIP and ENIP traffic running on TCP or UDP and sends it to the intrusion rules engine. You can use CIP and ENIP keywords in custom intrusion rules to detect attacks in CIP and ENIP traffic. See CIP and ENIP Keywords. Additionally, you can control traffic by specifying CIP and ENIP application conditions in access control rules. See Controlling Application Traffic.

Note the following:

- To detect CIP and ENIP applications and use them in access control rules, intrusion rules and so on, you must manually enable the CIP preprocessor in the corresponding network analysis policy. See Setting the Default Network Analysis Policy for Access Control and Specifying Traffic to Preprocess Using Network Analysis Rules.

- To drop traffic that triggers CIP preprocessor rules and CIP intrusion rules, ensure that the corresponding intrusion policy Drop when Inline option is enabled. See Setting Drop Behavior in an Inline Deployment.

- To block CIP or ENIP application traffic using access control rules, ensure that the inline normalization preprocessor and its Inline Mode option are enabled in the corresponding network analysis policy. See Normalizing Inline Traffic and Allowing Preprocessors to Affect Traffic in Inline Deployments.

- Add the default CIP detection port 44818 and any other ports you list to the TCP stream Perform Stream Reassembly on Both Ports list. See Selecting Stream Reassembly Options.

- Event viewers give special handling to CIP applications. See Understanding CIP Events.

Table 28-3 CIP Preprocessor Rules

Preprocessor Rule GID:SID

Rule Message

148:1

CIP_MALFORMED

148:2

CIP_NON_CONFORMING

148:3

CIP_CONNECTION_LIMIT

148:4

CIP_REQUEST_LIMIT

The following list describes CIP preprocessor options you can modify.

Ports

Specifies the ports to inspect for CIP and ENIP traffic. You can specify an integer from 0 to 65535. Separate multiple port numbers with commas.

Note You must add the default CIP detection port 44818 and any other ports you list to the TCP stream Perform Stream Reassembly on Both Ports list. See Selecting Stream Reassembly Options.

Default Unconnected Timeout (seconds)

When a CIP request message does not contain a protocol-specific timeout value and Maximum number of concurrent unconnected requests per TCP connection is reached, the system times the message for the number of seconds specified by this option. When the timer expires, the message is removed to make room for future requests. You can specify an integer from 0 to 360. When you specify 0, all traffic that does not have a protocol-specific timeout times out first.

Maximum number of concurrent unconnected requests per TCP connection

The number of concurrent requests that can go unanswered before the system closes the connection. You can specify an integer from 1 to 10000.

Maximum number of CIP connections per TCP connection

The maximum number of simultaneous CIP connections allowed by the system per TCP connection. You can specify an integer from 1 to 10000.

To configure the CIP preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue.See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether CIP Configuration under SCADA Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The CIP Configuration page appears. A message at the bottom of the page identifies the network analysis policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can modify any of the options described in this section.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding CIP Events

By design, application detectors detect and event viewers display the same application one time per session. A CIP session can include multiple applications in different packets, and a single CIP packet can contain multiple applications. The CIP preprocessor handles all CIP and ENIP traffic according to the corresponding rule and controls the display of CIP events as follows:

- Application Protocol: CIP or ENIP

- Client: CIP Client or ENIP Client

- Web Application: the specific application detected, which is:

– For rules that allow or monitor traffic: the last application protocol detected in the session.

Note that access control rules that you configure to log connections might not generate events for specified CIP applications, and access control rules that you do not configure to log connections might generate events for CIP applications.

– For rules that block traffic: the application protocol that triggered the block.

When an access control rule blocks a list of CIP applications, event viewers display the first application that is detected.

Note the following:

- Cisco recommends that you use an access control policy default action of Intrusion Prevention .

- The CIP preprocessor does not support an access control policy default action of Access Control: Trust All Traffic which may produce undesirable behavior, including not dropping traffic triggered by CIP applications specified in intrusion rules and access control rules.

- The CIP preprocessor does not support an access control policy default action of Access Control: Block All Traffic which may produce undesirable behavior, including blocking CIP applications that you do not expect to be blocked.

- The CIP preprocessor does not support application visibility for CIP applications, including network discovery.

See Understanding Connection and Security Intelligence Data Fields for more information.

Configuring Transport & Network Layer Preprocessing

You configure most transport at network layer preprocessors in a network analysis policy, which prepares traffic for inspection using the rules enabled in an intrusion policy. See Understanding Network Analysis and Intrusion Policies for more information.

Transport and network layer preprocessors detect attacks that exploit IP fragmentation, checksum validation, and TCP and UDP session preprocessing. Before packets are sent to preprocessors, the packet decoder converts packet headers and payloads into a format that can be easily used by the preprocessors and the intrusion rules engine and detects various anomalous behaviors in packet headers. After packet decoding and before sending packets to other preprocessors, the inline normalization preprocessor normalizes traffic for inline deployments.

When an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses it with its current configuration even though it remains disabled in the network analysis policy’s web interface. For more information, see Limitations of Custom Policies.

Caution Some users with custom user roles cannot access the network analysis policy via the standard menu path ( Policies > Access Control > Network Analysis Policy). These users can access the network analysis policy through the intrusion policy: Policies > Intrusion > Intrusion Policy > Network Analysis Policy. For more information on custom user roles, see Managing Custom User Roles.

You can tailor transport and network layer preprocessor settings that you configure in network analysis policies by VLAN, zone, or network. Some transport and network layer settings apply globally to all traffic, and you configure these in an access control policy.

- Configuring Advanced Transport/Network Settings

- Verifying Checksums

- Normalizing Inline Traffic

- Defragmenting IP Packets

- Understanding Packet Decoding

- Using TCP Stream Preprocessing

- Using UDP Stream Preprocessing

Configuring Advanced Transport/Network Settings

License: Protection

Advanced transport and network preprocessor settings apply globally to all networks, zones, and VLANs where you apply your access control policy. You configure these advanced settings in an access control policy rather than in a network analysis policy.

The following sections describe these settings:

- Ignoring VLAN Headers

- Initiating Active Responses with Intrusion Drop Rules

- Troubleshooting: Logging Session Termination Messages

Ignoring VLAN Headers

License: Protection

Supported Devices: Any except ASA FirePOWER

Different VLAN tags in traffic traveling in different directions for the same connection can affect traffic reassembly and rule processing. For example, in the following graphic traffic for the same connection could be transmitted over VLAN A and received over VLAN B.

When you enable Ignore the VLAN header when tracking connections, the system ignores the VLAN header so packets can be correctly processed for your deployment.

To ignore VLAN headers:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

.

The Transport/Network Layer Preprocessor Settings pop-up window appears.

Step 5 You have the following choices:

- For deployed devices that might detect different VLAN tags for the same connection in traffic traveling in different directions, select the Ignore the VLAN header when tracking connections check box to ignore VLAN headers when identifying traffic.

- For deployed devices that will not detect different VLAN tags for the same connection traffic traveling in different directions, clear the Ignore the VLAN header when tracking connections check box to include VLAN headers when identifying traffic.

Step 6 Click OK.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Initiating Active Responses with Intrusion Drop Rules

License: Protection

A drop rule is an intrusion rule or preprocessor rule whose rule state is set to Drop and Generate Events. In an inline deployment, the system responds to TCP or UDP drop rules by dropping the triggering packet and blocking the session where the packet originated. In a passive deployment, the system cannot drop the packet and does not block the session except with the use of active responses.

Tip Because UDP data streams are not typically thought of in terms of sessions, see Using UDP Stream Preprocessing for further explanation of how the stream preprocessor uses the source and destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP header to determine the direction of flow and identify a UDP session.

You can configure the Maximum Active Responses option to initiate one or more active responses to more precisely and specifically close a TCP connection or UDP session when an offending packet triggers a TCP or UDP drop rule.

When active responses are enabled in an inline deployment, the system responds to TCP drop rules by dropping the triggering packet and inserting a TCP Reset (RST) packet in both the client and server traffic. The system cannot drop the packet in a passive deployment; when active responses are enabled in a passive deployment, the system responds to TCP drop rules by sending a TCP reset to both the client and server ends of a TCP connection. When active responses are enabled in inline or passive deployments, the system closes a UDP session by sending an ICMP unreachable packet to each end of the session. Active responses are most effective in inline deployments because resets are more likely to arrive in time to affect the connection or session.

Depending on how you configure the Maximum Active Responses option, the system can also initiate additional active responses if it sees additional traffic from either end of the connection or session. The system initiates each additional active response, up to a specified maximum, after a specified number of seconds have elapsed since the previous response.

See Selecting The TCP Global Option for information on setting the maximum number of active responses.

Note that a triggered resp or react rule also initiates an active response regardless of the configuration of Maximum Active Responses; however, Maximum Active Responses control whether the system initiates additional active responses for resp and react rules in the same way it controls the maximum number of active responses for drop rules. See Initiating Active Responses with Rule Keywords for more information.

You can also use the config response command to configure the active response interface to use and the number of TCP resets to attempt in a passive deployment. See Setting the Active Response Reset Attempts and Interface for more information.

No preprocessor rules are associated with the following options.

Maximum Active Responses

Specifies a maximum of 1 to 25 active responses per TCP connection. When additional traffic occurs on a connection where an active response has been initiated, and the traffic occurs more than Minimum Response Seconds after a previous active response, the system sends another active response unless the specified maximum has been reached. A setting of 0 disables active responses triggered by drop rules and disables additional active responses triggered by resp or react rules. For more information, see Initiating Active Responses with Intrusion Drop Rules and Initiating Active Responses with Rule Keywords.

Minimum Response Seconds

Until Maximum Active Responses occur, specifies waiting 1 to 300 seconds before any additional traffic on a connection where the system has initiated an active response results in a subsequent active response.

To initiate active responses with drop rules:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

.

The Transport/Network Layer Preprocessor Settings pop-up window appears.

Step 5 You have the following options:

- Specify a value 1 to 25 of Maximum Active Responses per TCP connection. A setting of 0 disables active responses triggered by drop rules and disables additional active responses triggered by resp or react rules.

- Specify a value 1 to 300 of Minimum Response Seconds to wait until either Maximum Active Responses occur or any additional traffic on a connection where the system has initiated an active response results in a subsequent active response.

Step 6 Click OK.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Troubleshooting: Logging Session Termination Messages

License: Protection

Support might ask you during a troubleshooting call to configure your system to log a message when an individual connection exceeds the specified threshold. Changing the setting for this option will affect performance and should be done only with Support guidance.

To log session termination messages:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

.

The Transport/Network Layer Preprocessor Settings pop-up window appears.

Step 5 Expand Troubleshooting Options.

Step 6 Specify for Session Termination Logging Threshold the number of bytes that result in a logged message when the session terminates and the specified number was exceeded.

The upper limit of 1GB is also restricted by the amount of memory on the managed device allocated for stream processing.

Step 7 Click OK.

You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Verifying Checksums

License: Protection

The system can verify all protocol-level checksums to ensure that complete IP, TCP, UDP, and ICMP transmissions are received and that, at a basic level, packets have not been tampered with or accidentally altered in transit. A checksum uses an algorithm to verify the integrity of a protocol in the packet. The packet is considered to be unchanged if the system computes the same value that is written in the packet by the end host.

Disabling checksum verification may leave your network susceptible to insertion attacks. Note that the system does not generate checksum verification events. In an inline deployment, you can configure the system to drop packets with invalid checksums.

To configure checksum verifications:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether Checksum Verification under Transport/Network Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Checksum Verification page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can set any of the options in the Checksum Verification section to Enabled or Disabled in a passive or inline deployment, or to Drop in an inline deployment:

- ICMP Checksums

- IP Checksums

- TCP Checksums

- UDP Checksums

Note that to drop offending packets, in addition to setting an option to Drop you must also enable Inline Mode in the associated network analysis policy. See Allowing Preprocessors to Affect Traffic in Inline Deployments for more information. Note also that setting these options to Drop in a passive deployment, or in an inline deployment in tap mode, is the same as setting them to Enabled.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Normalizing Inline Traffic

License: Protection

The inline normalization preprocessor normalizes traffic to minimize the chances of attackers evading detection in inline deployments. If you enable the inline normalization preprocessor in a network analysis policy, the system tests the following two conditions to ensure that you are using an inline deployment:

- Inline Mode is enabled in the policy. See Allowing Preprocessors to Affect Traffic in Inline Deployments.

- The access control policy where inline normalization is enabled is applied to a device that is deployed inline and uses an inline set.

The preprocessor normalizes specified traffic only when both conditions are met.

You can specify normalization of any combination of IPv4, IPv6, ICMPv4, ICMPv6, and TCP traffic. Most normalizations are on a per-packet basis and are conducted by the inline normalization preprocessor. However, the TCP stream preprocessor handles most state-related packet and stream normalizations, including TCP payload normalization.

Inline normalization takes place immediately after decoding by the packet decoder and before processing by other preprocessors. Normalization proceeds from the inner to outer packet layers.

The inline normalization preprocessor does not generate events; it prepares packets for use by other preprocessors and the rules engine in inline deployments. The preprocessor also helps ensure that the packets the system processes are the same as the packets received by the hosts on your network.

Tip In an inline deployment, Cisco recommends that you configure the inline normalization preprocessor with the Normalize TCP Payload option enabled. In a passive deployment, Cisco recommends that you configure adaptive profiles. For more information, see Tuning Preprocessing in Passive Deployments.

Minimum TTL

When Reset TTL is greater than or equal to the value 1 to 255 set for this option, specifies the following:

- the minimum value the system will permit in the IPv4 Time to Live (TTL) field when Normalize IPv4 is enabled; a lower value results in normalizing the packet value for TTL to the value set for Reset TTL

- the minimum value the system will permit in the IPv6 Hop Limit field when Normalize IPv6 is enabled; a lower value results in normalizing the packet value for Hop Limit to the value set for Reset TTL

The system assumes a value of 1 when the field is empty.

Note that you can enable the following rules in the decoder rule category to generate events for this option:

- You can enable rule 116:428 to generate an event when the system detects an IPv4 packet with a TTL less than the specified minimum.

- You can enable rule 116:270 to generate an event when the system detects an IPv6 packet with a hop limit that is less than the specified minimum.

See the packet decoder Detect Protocol Header Anomalies option in Configuring Packet Decoding for more information.

Reset TTL

When set to a value 1 to 255 that is greater than or equal to Minimum TTL, normalizes the following:

- the IPv4 TTL field when Normalize IPv4 is enabled

- the IPv6 Hop Limit field when Normalize IPv6 is enabled

The system normalizes the packet by changing its TTL or Hop Limit value to the value set for this option when the packet value is less than Minimum TTL. Setting this option to a value of 0, or any value less than Minimum TTL, disables the option. The system assumes a value of 0 when the field is empty.

Normalize IPv4

Enables normalization of IPv4 traffic. The system also normalizes the TTL field as needed when this option is enabled and the value set for Reset TTL enables TTL normalization. You can also enable Normalize Don’t Fragment Bits and Normalize Reserved Bits when this option is enabled.

When you enable this option, the system performs the following base IPv4 normalizations:

- truncates packets with excess payload to the datagram length specified in the IP header

- clears the Differentiated Services (DS) field, formerly known as the Type of Service (TOS) field

- sets all option octets to 1 (No Operation)

Normalize Don't Fragment Bit

Clears the single-bit Don’t Fragment subfield of the IPv4 Flags header field. Enabling this option allows a downstream router to fragment packets if necessary instead of dropping them; enabling this option can also prevent evasions based on crafting packets to be dropped. You must enable Normalize IPv4 to select this option.

Normalize Reserved Bit

Clears the single-bit Reserved subfield of the IPv4 Flags header field. You would typically enable this option. You must enable Normalize IPv4 to select this option.

Normalize TOS Bit

Clears the one byte Differentiated Services field, formerly known as Type of Service. You must enable Normalize IPv4 to select this option.

Normalize Excess Payload

Truncates packets with excess payload to the datagram length specified in the IP header plus the Layer 2 (for example, Ethernet) header, but does not truncate below the minimum frame length. You must enable Normalize IPv4 to select this option.

Normalize IPv6

Sets all Option Type fields in the Hop-by-Hop Options and Destination Options extension headers to 00 (Skip and continue processing). The system also normalizes the Hop Limit field as needed when this option is enabled and the value set for Reset TTL enables hop limit normalization.

Normalize ICMPv4

Clears the 8-bit Code field in Echo (Request) and Echo Reply messages in ICMPv4 traffic.

Normalize ICMPv6

Clears the 8-bit Code field in Echo (Request) and Echo Reply messages in ICMPv6 traffic.

Normalize/Clear Reserved Bits

Clears the Reserved bits in the TCP header.

Normalize/Clear Option Padding Bytes

Clears any TCP option padding bytes.

Clear Urgent Pointer if URG=0

Clears the 16-bit TCP header Urgent Pointer field if the urgent (URG) control bit is not set.

Clear Urgent Pointer/URG on Empty Payload

Clears the TCP header Urgent Pointer field and the URG control bit if there is no payload.

Clear URG if Urgent Pointer is Not Set

Clears the TCP header URG control bit if the urgent pointer is not set.

Normalize Urgent Pointer

Sets the two-byte TCP header Urgent Pointer field to the payload length if the pointer is greater than the payload length.

Normalize TCP Payload

Enables normalization of the TCP Data field to ensure consistency in retransmitted data. Any segments that cannot be properly reassembled are dropped.

Remove Data on SYN

Removes data in synchronization (SYN) packets if your TCP operating system policy is not Mac OS.

This option also disables event generation for rule 129:2.

Remove Data on RST

Removes any data from a TCP reset (RST) packet.

Trim Data to Window

Trims the TCP Data field to the size specified in the Window field.

Trim Data to MSS

Trims the TCP Data field to the Maximum Segment Size (MSS) if the payload is longer than MSS.

Block Unrecoverable TCP Header Anomalies

When you enable this option, the system blocks anomalous TCP packets that, if normalized, would be invalid and likely would be blocked by the receiving host. For example, the system blocks any SYN packet transmitted subsequent to an established session.

The system also drops any packet that matches any of the following TCP stream preprocessor rules, regardless of whether the rules are enabled:

– 129:1

– 129:3

– 129:4

– 129:6

– 129:8

– 129:11

– 129:14 through 129:19

The Total Blocked Packets performance graph tracks the number of packets blocked in inline deployments and, in passive deployments and inline deployments in tap mode, the number that would have been blocked in an inline deployment. See Generating Intrusion Event Performance Statistics Graphs for more information.

Explicit Congestion Notification

Enables per-packet or per-stream normalization of Explicit Congestion Notification (ECN) flags as follows:

- select Packet to clear ECN flags on a per-packet basis regardless of negotiation

- select Stream to clear ECN flags on a per-stream basis if ECN use was not negotiated

If you select Stream, you must also ensure that the TCP stream preprocessor Require TCP 3-Way Handshake option is enabled for this normalization to take place; see Selecting TCP Policy Options for more information.

Allow These TCP Options

Disables normalization of specific TCP options you allow in traffic.

The system does not normalize options that you explicitly allow. It normalizes options that you do not explicitly allow by setting the options to No Operation (TCP Option 1).

The system always allows the Maximum Segment Size (MSS), Window Scale, and Time Stamp TCP options because these options are commonly used for optimal TCP performance. The system normalizes these commonly used options regardless of the configuration of Allow These TCP Options. The system does not automatically allow other less commonly used options.

You can allow specific options by configuring a comma-separated list of option keywords, option numbers, or both as shown in the following example:

sack, echo, 19

Specifying an option keyword is the same as specifying the number for one or more TCP options associated with the keyword. For example, specifying sack is the same as specifying TCP options 4 (Selective Acknowledgment Permitted) and 5 (Selective Acknowledgment). Option keywords are not case sensitive.

You can also specify any, which allows all TCP options and effectively disables normalization of all TCP options.

The following table summarizes how you can specify TCP options to allow. If you leave the field empty, the system allows only the MSS, Window Scale, and Time Stamp options.

Specify...

To allow...

sack

TCP options 4 (Selective Acknowledgment Permitted) and 5 (Selective Acknowledgment)

echo

TCP options 6 (Echo Request) and 7 (Echo Reply)

partial_order

TCP options 9 (Partial Order Connection Permitted) and 10 (Partial Order Service Profile)

conn_count

TCP Connection Count options 11 (CC), 12 (CC.New), and 13 (CC.Echo)

alt_checksum

TCP options 14 (Alternate Checksum Request) and 15 (Alternate Checksum)

md5

TCP option 19 (MD5 Signature)

the option number, 2 to 255

a specific option, including options for which there is no keyword

any

all TCP options; this setting effectively disables TCP option normalization

When you do not specify any for this option, normalizations include the following:

- except MSS, Window Scale, Time Stamp, and any explicitly allowed options, sets all option bytes to No Operation (TCP Option 1)

- sets the Time Stamp octets to No Operation if Time Stamp is present but invalid, or valid but not negotiated

- blocks the packet if Time Stamp is negotiated but not present

- clears the Time Stamp Echo Reply (TSecr) option field if the Acknowledgment (ACK) control bit is not set

- sets the MSS and Window Scale options to No Operation (TCP Option 1) if the SYN control bit is not set

To configure the inline normalizations preprocessor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices depending on whether Inline Normalization is enabled under Transport/Network Layer Preprocessors:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Inline Normalization page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can set any of the options described in Normalizing Inline Traffic.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Defragmenting IP Packets

License: Protection

When an IP datagram is broken into two or more smaller IP datagrams because it is larger than the maximum transmission unit (MTU), it is fragmented. A single IP datagram fragment may not contain enough information to identify a hidden attack. Attackers may attempt to evade detection by transmitting attack data in fragmented packets. The IP defragmentation preprocessor reassembles fragmented IP datagrams before the rules engine executes rules against them so the rules can more appropriately identify attacks in those packets. If fragmented datagrams cannot be reassembled, rules do not execute against them.

Note that you must enable IP defragmentation preprocessor rules, which have a generator ID (GID) of 123, if you want these rules to generate events. See Setting Rule States for more information.

See the following sections for more information:

- Understanding IP Fragmentation Exploits

- Target-Based Defragmentation Policies

- Selecting Defragmentation Options

- Configuring IP Defragmentation

Understanding IP Fragmentation Exploits

License: Protection

Enabling IP defragmentation helps you detect attacks against hosts on your network, like the teardrop attack, and resource consumption attacks against the system itself, like the Jolt2 attack.

The Teardrop attack exploits a bug in certain operating systems that causes them to crash when trying to reassemble overlapping IP fragments. When enabled and configured to do so, the IP defragmentation preprocessor identifies the overlapping fragments. The IP defragmentation preprocessor detects the first packets in an overlapping fragment attack such as Teardrop, but does not detect subsequent packets for the same attack.

The Jolt2 attack sends a large number of copies of the same fragmented IP packet in an attempt to overuse IP defragmentors and cause a denial of service attack. A memory usage cap disrupts this and similar attacks in the IP defragmentation preprocessor, and places the system self-preservation above exhaustive inspection. The system is not overwhelmed by the attack, remains operational, and continues to inspect network traffic.

Different operating systems reassemble fragmented packets in different ways. Attackers who can determine which operating systems your hosts are running can also fragment malicious packets so that a target host reassembles them in a specific manner. Because the system does not know which operating systems the hosts on your monitored network are running, the preprocessor may reassemble and inspect the packets incorrectly, thus allowing an exploit to pass through undetected. To mitigate this kind of attack, you can configure the defragmentation preprocessor to use the appropriate method of defragmenting packets for each host on your network. See Target-Based Defragmentation Policies for more information.

Note that you can also use adaptive profiles to dynamically select target-based policies for the IP defragmentation preprocessor using host operating system information for the target host in a packet. For more information, see Tuning Preprocessing in Passive Deployments.

Target-Based Defragmentation Policies

License: Protection

A host's operating system uses three criteria to determine which packet fragments to favor when reassembling the packet: the order in which the fragment was received by the operating system, its offset (the fragment's distance, in bytes, from the beginning of the packet), and its beginning and ending position compared to overlap fragments. Although every operating system uses these criteria, different operating systems favor different fragments when reassembling fragmented packets. Therefore, two hosts with different operating systems on your network could reassemble the same overlapping fragments in entirely different ways.

An attacker, aware of the operating system of one of your hosts, could attempt to evade detection and exploit that host by sending malicious content hidden in overlapping packet fragments. This packet, when reassembled and inspected, seems innocuous, but when reassembled by the target host, contains a malicious exploit. However, if you configure the IP defragmentation preprocessor to be aware of the operating systems running on your monitored network segment, it will reassemble the fragments the same way that the target host does, allowing it to identify the attack.

You can configure the IP defragmentation preprocessor to use one of seven defragmentation policies, depending on the operating system of the target host. The following table lists the seven policies and the operating systems that use each one. The First and Last policy names reflect whether those policies favor original or subsequent overlapping packets.

Table 29-1 Target-Based Defragmentation Policies

Policy

Operating Systems

BSD

AIX

FreeBSD

IRIX

VAX/VMS

BSD-right

HP JetDirect

First

Mac OS

HP-UX

Linux

Linux

OpenBSD

Last

Cisco IOS

Solaris

SunOS

Windows

Windows

Selecting Defragmentation Options

License: Protection

You can choose to simply enable or disable IP defragmentation; however, Cisco recommends that you specify the behavior of the enabled IP defragmentation preprocessor at a more granular level.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

You can configure the global Preallocated Fragments option:

Preallocated Fragments

The maximum number of individual fragments that the preprocessor can process at once. Specifying the number of fragment nodes to preallocate enables static memory allocation.

Caution Processing an individual fragment uses approximately 1550 bytes of memory. If the preprocessor requires more memory to process the individual fragments than the predetermined allowable memory limit for the managed device, the memory limit for the device takes precedence.

You can configure the following options for each IP defragmentation policy:

Networks

The IP address of the host or hosts to which you want to apply the defragmentation policy.

You can specify a single IP address or address block, or a comma-separated list of either or both. You can specify up to 255 total profiles, including the default policy. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Policy

The defragmentation policy you want to use for a set of hosts on your monitored network segment. You can choose among seven policies: BSD, BSD-Right, First, Linux, Last, Solaris, and Windows. See Target-Based Defragmentation Policies for detailed information on these policies.

Timeout

Specifies the maximum amount of time, in seconds, that the preprocessor engine can use when reassembling a fragmented packet. If the packet cannot be reassembled within the specified time period, the preprocessor engine stops attempting to reassemble the packet and discards received fragments.

Minimum TTL

Specifies the minimum acceptable TTL value a packet may have. This option detects TTL-based insertion attacks.

You can enable rule 123:1 to generate events for this option. See Setting Rule States for more information.

Detect Anomalies

Identifies fragmentation problems such as overlapping fragments.

You can enable the following rules to generate events for this option:

- 123:1 through 123:4

- 123:5 (BSD policy)

- 123:6 through 123:8

Overlap Limit

Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments in a session has been detected, defragmentation stops for that session. You must enable Detect Anomalies to configure this option. A blank value disables this option.

You can enable rule 123:12 to generate events for this option. See Setting Rule States for more information.

Minimum Fragment Size

Specifies that when a non-last fragment smaller than the configured number between 0 (unlimited) and 255 of bytes has been detected, the packet is considered malicious. You must enable Detect Anomalies to configure this option. A blank value disables this option.

You can enable rule 123:13 to generate events for this option. See Setting Rule States for more information.

Configuring IP Defragmentation

License: Protection

You can use the following procedure to configure the IP defragmentation preprocessor. For more information on the IP defragmentation preprocessor configuration options, see Selecting Defragmentation Options.

To configure IP defragmentation:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether IP Defragmentation under Transport/Network Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The IP Defragmentation page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, you can modify the setting for Preallocated Fragments in the Global Settings page area.

Step 6 You have two options:

- Add a new target-based policy. Click the add icon (

) next to Servers on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses in the Host Address field and click OK .

You can specify a single IP address or address block, or a comma-separated list of either or both. You can create a total of 255 target-based policies including the default policy. For information on using IP address blocks in the FireSIGHT System, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of targets on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the policy you added.

- Modify the settings for an existing target-based policy. Click the configured address for a policy you have added under Hosts on the left side of the page, or click default .

) next to the policy you want to remove.

Step 7 Optionally, you can modify any of the options in the Configuration page area.

Step 8 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Packet Decoding

License: Protection

Before sending captured packets to a preprocessor, the system first sends the packets to the packet decoder. The packet decoder converts packet headers and payloads into a format that preprocessors and the rules engine can easily use. Each stack layer is decoded in turn, beginning with the data link layer and continuing through the network and transport layers..

Note that you must enable packet decoder rules, which have a generator ID (GID) of 116, if you want these rules to generate events. See Setting Rule States for more information.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Decode GTP Data Channel

Decodes the encapsulated GTP (General Packet Radio Service [GPRS] Tunneling Protocol) data channel. By default, the decoder decodes version 0 data on port 3386 and version 1 data on port 2152. You can use the GTP_PORTS default variable to modify the ports that identify encapsulated GTP traffic. See Optimizing Predefined Default Variables for more information.

You can enable rules 116:297 and 116:298 to generate events for this option.

Detect Teredo on Non-Standard Ports

Inspects Teredo tunneling of IPv6 traffic that is identified on a UDP port other than port 3544.

The system always inspects IPv6 traffic when it is present. By default, IPv6 inspection includes the 4in6, 6in4, 6to4, and 6in6 tunneling schemes, and also includes Teredo tunneling when the UDP header specifies port 3544.

In an IPv4 network, IPv4 hosts can use the Teredo protocol to tunnel IPv6 traffic through an IPv4 Network Address Translation (NAT) device. Teredo encapsulates IPv6 packets within IPv4 UDP datagrams to permit IPv6 connectivity behind an IPv4 NAT device. The system normally uses UDP port 3544 to identify Teredo traffic. However, an attacker could use a non-standard port in an attempt to avoid detection. You can enable Detect Teredo on Non-Standard Ports to cause the system to inspect all UDP payloads for Teredo tunneling.

Teredo decoding occurs only on the first UDP header, and only when IPv4 is used for the outer network layer. When a second UDP layer is present after the Teredo IPv6 layer because of UDP data encapsulated in the IPv6 data, the rules engine uses UDP intrusion rules to analyze both the inner and outer UDP layers.

Note that intrusion rules 12065, 12066, 12067, and 12068 in the policy-other rule category detect, but do not decode, Teredo traffic. Optionally, you can use these rules to drop Teredo traffic in an inline deployment; however, you should ensure that these rules are disabled or set to generate events without dropping traffic when you enable Detect Teredo on Non-Standard Ports. See Filtering Rules in an Intrusion Policy and Setting Rule States for more information.

Detect Excessive Length Value

Detects when the packet header specifies a packet length that is greater than the actual packet length.

You can enable rules 116:6, 116:47, 116:97, and 116:275 to generate events for this option.

Detect Invalid IP Options

Detects invalid IP header options to identify exploits that use invalid IP options. For example, there is a denial of service attack against a firewall which causes the system to freeze. The firewall attempts to parse invalid Timestamp and Security IP options and fails to check for a zero length, which causes an irrecoverable infinite loop. The rules engine identifies the zero length option, and provides information you can use to mitigate the attack at the firewall.

You can enable rules 116:4 and 116:5 to generate events for this option. See Setting Rule States for more information.

Detect Experimental TCP Options

TCP Option

Description

9

Partial Order Connection Permitted

10

Partial Order Service Profile

14

Alternate Checksum Request

15

Alternate Checksum Data

18

Trailer Checksum

20

Space Communications Protocol Standards (SCPS)

21

Selective Negative Acknowledgements (SCPS)

22

Record Boundaries (SCPS)

23

Corruption (SPCS)

24

SNAP

26

TCP Compression Filter

Because these are experimental options, some systems do not account for them and may be open to exploits.

Note In addition to the experimental options listed in the above table, the system considers any TCP option with an option number greater than 26 to be experimental.

You can enable rule 116:58 to generate events for this option. See Setting Rule States for more information.

Detect Obsolete TCP Options

TCP Option

Description

6

Echo

7

Echo Reply

16

Skeeter

17

Bubba

19

MD5 Signature

25

Unassigned

You can enable rule 116:57 to generate events for this option. See Setting Rule States for more information.

Detect T/TCP

Detects TCP headers with the CC.ECHO option. The CC.ECHO option confirms that TCP for Transactions (T/TCP) is being used. Because T/TCP header options are not in widespread use, some systems do not account for them and may be open to exploits.

You can enable rule 116:56 to generate events for this option. See Setting Rule States for more information.

Detect Other TCP Options

Detects TCP headers with invalid TCP options not detected by other TCP decoding event options. For example, this option detects TCP options with the incorrect length or with a length that places the option data outside the TCP header.

You can enable rules 116:54, 116:55, and 116:59 to generate events for this option. See Setting Rule States for more information.

Detect Protocol Header Anomalies

Detects other decoding errors not detected by the more specific IP and TCP decoder options. For example, the decoder might detect a malformed data-link protocol header.

To generate events for this option, you can enable any packet decoder rule other than rules specifically associated with other packet decoder options. See Setting Rule States for more information

Note that the following rules generate events triggered by anomalous IPv6 traffic: 116:270 through 116:274, 116:275 through 116:283, 116:291, 116:292, 116:295, 116:296, 116:406, 116:458, 116:460, 116:461.

Note also the following rules associated with the inline normalization preprocessor Minimum TTL option:

- You can enable rule 116:428 to generate an event when the system detects an IPv4 packet with a TTL less than the specified minimum.

- You can enable rule 116:270 to generate an event when the system detects an IPv6 packet with a hop limit that is less than the specified minimum.

See the inline normalization Minimum TTL option in Normalizing Inline Traffic for more information.

Configuring Packet Decoding

License: Protection

You can configure packet decoding on the Packet Decoding configuration page. For more information on packet decoding configuration options, see Understanding Packet Decoding.

To configure packet decoding:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether Packet Decoding under Transport/Network Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Packet Decoding page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Resolving Conflicts and Committing Policy Changes for more information

Step 5 You can enable or disable any of the detection options on the Packet Decoding page. See Understanding Packet Decoding for more information.

Step 6 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Using TCP Stream Preprocessing

License: Protection

The TCP protocol defines various states in which connections can exist. Each TCP connection is identified by the source and destination IP addresses and source and destination ports. TCP permits only one connection with the same connection parameter values to exist at a time.

Note that you must enable TCP stream preprocessor rules, which have a generator ID (GID) of 129, if you want these rules to generate events. See Setting Rule States for more information.

See the following sections for more information:

- Understanding State-Related TCP Exploits

- Initiating Active Responses with Intrusion Drop Rules

- Selecting The TCP Global Option

- Understanding Target-Based TCP Policies

- Selecting TCP Policy Options

- Reassembling TCP Streams

- Configuring TCP Stream Preprocessing

Understanding State-Related TCP Exploits

License: Protection

If you add the flow keyword with the established argument to an intrusion rule, the intrusion rules engine inspects packets matching the rule and the flow directive in stateful mode. Stateful mode evaluates only the traffic that is part of a TCP session established with a legitimate three-way handshake between a client and server. The following diagram illustrates a three-way handshake.

You can configure the system so that the preprocessor detects any TCP traffic that cannot be identified as part of an established TCP session, although this is not recommended for typical use because the events would quickly overload the system and not provide meaningful data.

Attacks like stick and snot use the system’s extensive rule sets and packet inspection against itself. These tools generate packets based on the patterns in Snort-based intrusion rules, and send them across the network. If your rules do not include the flow or flowbits keyword to configure them for stateful inspection, each packet will trigger the rule, overwhelming the system. Stateful inspection allows you to ignore these packets because they are not part of an established TCP session and do not provide meaningful information. When performing stateful inspection, the rules engine detects only those attacks that are part of an established TCP session, allowing analysts to focus on these rather than the volume of events caused by stick or snot.

Selecting The TCP Global Option

License: Protection

The TCP stream preprocessor has one global option that controls how the TCP stream preprocessor functions.

No preprocessor rules are associated with this option.

Packet Type Performance Boost

Enables ignoring TCP traffic for all ports and application protocols that are not specified in enabled intrusion rules, except when a TCP rule with both the source and destination ports set to any has a flow or flowbits option. This performance improvement could result in missed attacks.

Understanding Target-Based TCP Policies

License: Protection

Different operating systems implement TCP in different ways. For example, Windows and some other operating systems require a TCP reset segment to have a precise TCP sequence number to reset a session, while Linux and other operating systems permit a range of sequence numbers. In this example, the stream preprocessor must understand exactly how the destination host will respond to the reset based on the sequence number. The stream preprocessor stops tracking the session only when the destination host considers the reset to be valid, so an attack cannot evade detection by sending packets after the preprocessor stops inspecting the stream. Other variations in TCP implementations include such things as whether an operating system employs a TCP timestamp option and, if so, how it handles the timestamp, and whether an operating system accepts or ignores data in a SYN packet.

Different operating systems also reassemble overlapping TCP segments in different ways. Overlapping TCP segments could reflect normal retransmissions of unacknowledged TCP traffic. They could also represent an attempt by an attacker, aware of the operating system of one of your hosts, to evade detection and exploit that host by sending malicious content hidden in overlapping segments. However, you can configure the stream preprocessor to be aware of the operating systems running on your monitored network segment so it reassembles segments the same way the target host does, allowing it to identify the attack.

You can create one or more TCP policies to tailor TCP stream inspection and reassembly to the different operating systems on your monitored network segment. For each policy, you identify one of thirteen operating system policies. You bind each TCP policy to a specific IP address or address block using as many TCP policies as you need to identify any or all of the hosts using a different operating system. The default TCP policy applies to any hosts on the monitored network that you do not identify in any other TCP policy, so there is no need to specify an IP address, CIDR block, or prefix length for the default TCP policy.

Note that you can also use adaptive profiles to dynamically select target-based policies for the TCP stream preprocessor using host operating system information for the target host in a packet. For more information, see Tuning Preprocessing in Passive Deployments.

Table 29-2 TCP Operating System Policies

Policy

Operating Systems

First

unknown OS

Last

Cisco IOS

BSD

AIX

FreeBSD

OpenBSD

Linux

Linux 2.4 kernel

Linux 2.6 kernel

Old Linux

Linux 2.2 and earlier kernel

Windows

Windows 98

Windows NT

Windows 2000

Windows XP

Windows 2003

Windows 2003

Windows Vista

Windows Vista

Solaris

Solaris OS

SunOS

IRIX

SGI Irix

HPUX

HP-UX 11.0 and later

HPUX 10

HP-UX 10.2 and earlier

Mac OS

Mac OS 10 (Mac OS X)

Tip The First operating system policy could offer some protection when you do not know the host operating system. However, it may result in missed attacks. You should edit the policy to specify the correct operating system if you know it.

Selecting TCP Policy Options

License: Protection

The following list describes the options you can set to identify and control TCP traffic that the stream preprocessor inspects.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Network

Specifies the host IP addresses to which you want to apply the TCP stream reassembly policy.

You can specify a single IP address or address block. You can specify up to 255 total profiles including the default policy. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Note that the default setting in the default policy specifies all IP addresses on your monitored network segment that are not covered by another target-based policy. Therefore, you cannot and do not need to specify an IP address or CIDR block/prefix length for the default policy, and you cannot leave this setting blank in another policy or use address notation to represent any (for example, 0.0.0.0/0 or ::/0).

Note also that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

Policy

Identifies the TCP policy operating system of the target host or hosts. If you select a policy other than Mac OS, the system removes the data from the synchronization (SYN) packets and disables event generation for rule 129:2.

For more information, see Understanding Target-Based TCP Policies.

Timeout

The number of seconds between 1 and 86400 the intrusion rules engine keeps an inactive stream in the state table. If the stream is not reassembled in the specified time, the intrusion rules engine deletes it from the state table.

Note If your managed device is deployed on a segment where the network traffic is likely to reach the device’s bandwidth limits, you should consider setting this value higher (for example, to 600 seconds) to lower the amount of processing overhead.

Maximum TCP Window

Specifies the maximum TCP window size between 1 and 1073725440 bytes allowed as specified by a receiving host. Setting the value to 0 disables checking for the TCP window size.

Caution The upper limit is the maximum window size permitted by RFC, and is intended to prevent an attacker from evading detection, but setting a significantly large maximum window size could result in a self-imposed denial of service.

You can enable rule 129:6 to generate events for this option. See Setting Rule States for more information.

Overlap Limit

Specifies that when the configured number between 0 (unlimited) and 255 of overlapping segments in a session has been detected, segment reassembly stops for that session and, if Stateful Inspection Anomalies is enabled and the accompanying preprocessor rule is enabled, an event is generated.

You can enable rule 129:7 to generate events for this option. See Setting Rule States for more information.

Flush Factor

In an inline deployment, specifies that when a segment of decreased size has been detected subsequent to the configured number between 1 and 2048 of segments of non-decreasing size, the system flushes segment data accumulated for detection. Setting the value to 0 disables detection of this segment pattern, which can indicate the end of a request or response. Note that the Inline Normalization Normalize TCP Payload option must be enabled for this option the be effective. See Normalizing Inline Traffic for more information.

Stateful Inspection Anomalies

Detects anomalous behavior in the TCP stack. When accompanying preprocessor rules are enabled, this may generate many events if TCP/IP stacks are poorly written.

You can enable the following rules to generate events for this option:

– 129:1 through 129:5

– 129:6 (Mac OS only)

– 129:8 through 129:11

– 129:13 through 129:19

See Setting Rule States for more information:

TCP Session Hijacking

Detects TCP session hijacking by validating the hardware (MAC) addresses detected from both sides of a TCP connection during the 3-way handshake against subsequent packets received on the session. When the MAC address for one side or the other does not match, if Stateful Inspection Anomalies is enabled and one of the two corresponding preprocessor rules are enabled, the system generates events.

You can enable rules 129:9 and 129:10 to generate events for this option. See Setting Rule States for more information.

Consecutive Small Segments

When Stateful Inspection Anomalies is enabled, specifies a maximum number of 1 to 2048 consecutive small TCP segments allowed. Setting the value to 0 disables checking for consecutive small segments.

You must set this option together with the Small Segment Size option, either disabling both or setting a non-zero value for both. Note that receiving as many as 2000 consecutive segments, even if each segment was 1 byte in length, without an intervening ACK would be far more consecutive segments than you would normally expect.

You can enable rule 129:12 to generate events for this option. See Setting Rule States for more information.

Small Segment Size

When Stateful Inspection Anomalies is enabled, specifies the 1 to 2048 byte TCP segment size that is considered small. Setting the value to 0 disables specifying the size of a small segment.

You must set this option together with the Consecutive Small Segments option, either disabling both or setting a non-zero value for both. Note that a 2048 byte TCP segment is larger than a normal 1500 byte Ethernet frame.

Ports Ignoring Small Segments

When Stateful Inspection Anomalies, Consecutive Small Segments, and Small Segment Size are enabled, optionally specifies a comma-separated list of one or more ports that ignore small TCP segment detection. Leaving this option blank specifies that no ports are ignored.

You can add any port to the list, but the list only affects ports specified in one of the Perform Stream Reassembly on port lists in the TCP policy.

Require TCP 3-Way Handshake

Specifies that sessions are treated as established only upon completion of a TCP three-way handshake. Disable this option to increase performance, protect from SYN flood attacks, and permit operation in a partially asynchronous environment. Enable it to avoid attacks that attempt to generate false positives by sending information that is not part of an established TCP session.

You can enable rule 129:20 to generate events for this option. See Setting Rule States for more information.

3-Way Handshake Timeout

Specifies the number of seconds between 0 (unlimited) and 86400 (twenty-four hours) by which a handshake must be completed when Require TCP 3-Way Handshake is enabled. You must enable Require TCP 3-Way Handshake to modify the value for this option.

Packet Size Performance Boost

Sets the preprocessor to not queue large packets in the reassembly buffer. This performance improvement could result in missed attacks. Disable this option to protect against evasion attempts using small packets of one to twenty bytes. Enable it when you are assured of no such attacks because all traffic is comprised of very large packets.

Legacy Reassembly

Sets the stream preprocessor to emulate the deprecated Stream 4 preprocessor when reassembling packets, which lets you compare events reassembled by the stream preprocessor to events based on the same data stream reassembled by the Stream 4 preprocessor.

Asynchronous Network

Specifies whether the monitored network is an asynchronous network, that is, a network where the system sees only half the traffic. When this option is enabled, the system does not reassemble TCP streams to increase performance.

Perform Stream Reassembly on Client Ports, Server Ports, Both Ports

Specifies for client ports, server ports, or both, a comma-separated list of ports to identify the traffic for the stream preprocessor to reassemble. See Selecting Stream Reassembly Options.

Perform Stream Reassembly on Client Services, Server Services, Both Services

Specifies for client services, server services, or both, services to identify in the traffic for the stream preprocessor to reassemble. See Selecting Stream Reassembly Options.

Troubleshooting Options: Maximum Queued Bytes

Support might ask you during a troubleshooting call to specify the amount of data that can be queued on one side of a TCP connection. A value of 0 specifies an unlimited number of bytes.

Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.

Troubleshooting Options: Maximum Queued Segments

Support might ask you during a troubleshooting call to specify the maximum number of bytes of data segments that can be queued on one side of a TCP connection. A value of 0 specifies an unlimited number of data segment bytes.

Caution Changing the setting for this troubleshooting option will affect performance and should be done only with Support guidance.

Reassembling TCP Streams

License: Protection

The stream preprocessor collects and reassembles all the packets that are part of a TCP session’s server-to-client communication stream, client-to-server communication stream, or both. This allows the rules engine to inspect the stream as a single, reassembled entity rather than inspecting only the individual packets that are part of a given stream.

See the following sections for more information:

- Understanding Stream-Based Attacks

- Selecting Stream Reassembly Options

Understanding Stream-Based Attacks

License: Protection

Stream reassembly allows the rules engine to identify stream-based attacks, which it may not detect when inspecting individual packets. You can specify which communication streams the rules engine reassembles based on your network needs. For example, when monitoring traffic on your web servers, you may only want to inspect client traffic because you are much less likely to receive malicious traffic from your own web server.

Selecting Stream Reassembly Options

License: Protection

In each TCP policy, you can specify a comma-separated list of ports to identify the traffic for the stream preprocessor to reassemble. If adaptive profiles are enabled, you can also list services that identify traffic to reassemble, either as an alternative to ports or in combination with ports. See Tuning Preprocessing in Passive Deployments for information on enabling and using adaptive profiles.

You can specify ports, services, or both. You can specify separate lists of ports for any combination of client ports, server ports, and both. You can also specify separate lists of services for any combination of client services, server services, and both. For example, assume that you wanted to reassemble the following:

- SMTP (port 25) traffic from the client

- FTP server responses (port 21)

- telnet (port 23) traffic in both directions

You could configure the following:

- For client ports, specify 23, 25

- For server ports, specify 21, 23

Or, instead, you could configure the following:

- For client ports, specify 25

- For server ports, specify 21

- For both ports, specify 23

Additionally, consider the following example which combines ports and services and would be valid when adaptive profiles are enabled:

- For client ports, specify 23

- For client services, specify smtp

- For server ports, specify 21

- For server services, specify telnet

Negating a port (for example, !80) can improve performance by preventing the TCP stream preprocessor from processing traffic for that port.

Although you can also specify all as the argument to provide reassembly for all ports, Cisco does not recommend setting ports to all because it may increase the amount of traffic inspected by this preprocessor and slow performance unnecessarily.

TCP reassembly automatically and transparently includes ports that you add to other preprocessors. However, if you do explicitly add ports to TCP reassembly lists that you have added to other preprocessor configurations, these additional ports are handled normally. This includes port lists for the following preprocessors:

- FTP/Telnet (server-level FTP)

- DCE/RPC

- HTTP Inspect

- SMTP

- Session Initiation Protocol

- POP

- IMAP

- SSL

Note that reassembling additional traffic types (client, server, both) increases resource demands.

If no preprocessor rule is mentioned in the following descriptions, the option is not associated with a preprocessor rule.

Perform Stream Reassembly on Client Ports

Enables stream reassembly based on ports for the client side of the connection. In other words, it reassembles streams destined for web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $HOME_NET. Use this option when you expect malicious traffic to originate from clients.

Perform Stream Reassembly on Client Services

Enables stream reassembly based on services for the client side of the connection. Use this option when you expect malicious traffic to originate from clients.

At least one client detector must be enabled (see Activating and Deactivating Detectors) for each client service you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for an associated client application, the system automatically enables all Cisco-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

This feature requires Protection and Control licenses.

Perform Stream Reassembly on Server Ports

Enables stream reassembly based on ports for the server side of the connection only. In other words, it reassembles streams originating from web servers, mail servers, or other IP addresses typically defined by the IP addresses specified in $EXTERNAL_NET. Use this option when you want to watch for server side attacks. You can disable this option by not specifying ports.

Perform Stream Reassembly on Server Services

Enables stream reassembly based on services for the server side of the connection only. Use this option when you want to watch for server side attacks. You can disable this option by not specifying services.

At least one detector must be enabled (see Activating and Deactivating Detectors) for each service you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for a service, the system automatically enables all Cisco-provided detectors for the associated application protocol; if none exist, the system enables the most recently modified user-defined detector for the application protocol.

This feature requires Protection and Control licenses.

Perform Stream Reassembly on Both Ports

Enables stream reassembly based on ports for both the client and server side of the connection. Use this option when you expect that malicious traffic for the same ports may travel in either direction between clients and servers. You can disable this option by not specifying ports.

Perform Stream Reassembly on Both Services

Enables stream reassembly based on services for both the client and server side of the connection. Use this option when you expect that malicious traffic for the same services may travel in either direction between clients and servers.You can disable this option by not specifying services.

At least one detector must be enabled (see Activating and Deactivating Detectors) for each service you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for an associated client application or application protocol, the system automatically enables all Cisco-provided detectors for the application or application protocol; if none exist, the system enables the most recently modified user-defined detector for the application or application protocol.

This feature requires Protection and Control licenses.

Configuring TCP Stream Preprocessing

License: Protection

You can configure TCP stream preprocessing, including TCP policies. For more information on the TCP stream preprocessor configuration options, see Selecting TCP Policy Options.

To configure the stream preprocessor to track TCP sessions:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether TCP Stream Configuration under Transport/Network Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The TCP Stream Configuration page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, modify Packet Type Performance Boost under Global Settings. See Selecting The TCP Global Option for more information.

Step 6 You have two options:

- Add a new target-based policy. Click the add icon (

) next to Hosts on the left side of the page. The Add Target pop-up window appears. Specify one or more IP addresses in the Host Address field and click OK .

You can specify a single IP address or address block. You can create a total of 255 target-based policies including the default policy. For information on using IP address blocks in the FireSIGHT System, see IP Address Conventions.

Note that for a target-based policy to process traffic, the networks you identify must match or be a subset of the networks, zones, and VLANs handled by the network analysis policy where you configure the target-based policy. See Customizing Preprocessing with Network Analysis Policies for more information.

A new entry appears in the list of targets on the left side of the page, highlighted to indicate that it is selected, and the Configuration section updates to reflect the current configuration for the policy you added.

- Modify the settings for an existing target-based policy. Click the configured address for a policy you have added under Hosts on the left side of the page, or click default .

) next to the policy you want to remove.

Step 7 Optionally, modify any of the TCP policy options under Configuration.

For specific instructions on modifying settings for stream reassembly based on client services, server services, or both go to step 8; otherwise, go to step 11.

For more information, see Selecting TCP Policy Options and Selecting Stream Reassembly Options.

Step 8 To modify settings for stream reassembly based on client, server, or both services, click inside the field you want to modify or click Edit next to the field.

The pop-up window for the field you selected appears.

For example, the following graphic shows the Perform Stream Reassembly on Both Services pop-up window.

Note that you can enable adaptive profiles to monitor traffic for the stream preprocessor to reassemble based on services discovered on your network. See Working with Servers and Tuning Preprocessing in Passive Deployments for more information.

Step 9 You have two choices:

- To add services to monitor, select one or more services from the Available list on the left, then click the right arrow ( > ) button.

- To remove a service, select it from the Enabled list on the right, then click the left arrow ( < ) button.

Use Ctrl or Shift while clicking to select multiple service detectors. You can also click and drag to select multiple adjacent service detectors.

Step 10 Click OK to add the selections.

The TCP Stream Configuration page is displayed and the services are updated.

Step 11 Optionally, expand the Troubleshooting Options and modify either of the TCP stream preprocessing policy settings only if asked to do so by Support. For more information, see Selecting TCP Policy Options.

Step 12 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Using UDP Stream Preprocessing

License: Protection

UDP stream preprocessing occurs when the rules engine processes packets against a UDP rule that includes the flow keyword (see Applying Rules to a TCP or UDP Client or Server Flow) using any of the following arguments:

- Established

- To Client

- From Client

- To Server

- From Server

UDP is a connectionless protocol that does not provide a means for two endpoints to establish a communication channel, exchange data, and close the channel. UDP data streams are not typically thought of in terms of sessions. However, the stream preprocessor uses the source and destination IP address fields in the encapsulating IP datagram header and the port fields in the UDP header to determine the direction of flow and identify a session. A session ends when a configurable timer is exceeded, or when either endpoint receives an ICMP message that the other endpoint is unreachable or the requested service is unavailable.

Note that the system does not generate events related to UDP stream preprocessing; however, you can enable related packet decoder rules to detect UDP protocol header anomalies. For information on events generated by the packet decoder, see Understanding Packet Decoding.

Configuring UDP Stream Preprocessing

License: Protection

You can configure UDP stream preprocessing.

To configure the stream preprocessor to track UDP sessions:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Edit Policy page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 You have two choices, depending on whether UDP Stream Configuration under Transport/Network Layer Preprocessors is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The UDP Stream Configuration page appears. A message at the bottom of the page identifies the policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, configure a Timeout value to specify the number of seconds between 1 and 86400 the preprocessor keeps an inactive stream in the state table. If additional datagrams are not seen in the specified time, the preprocessor deletes the stream from the state table.

Step 6 Optionally, select Packet Type Performance Boost to ignore UDP traffic for all ports and application protocols that are not specified in enabled rules, except when a UDP rule with both the source and destination ports set to any has a flow or flowbits option. This performance improvement could result in missed attacks.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Tuning Preprocessing in Passive Deployments

Typically, the system uses the static settings in your network analysis policy to preprocess and analyze traffic. With the adaptive profiles feature, however, the system can adapt to network traffic by associating traffic with host information from the network map and then processing the traffic accordingly.

When a host receives traffic, the operating system running on the host reassembles IP fragments. The order used for that reassembly depends on the operating system. Similarly, each operating system may implement TCP in different ways, and therefore reassemble TCP streams differently. If preprocessors reassemble data using a format other than that used for the operating system of the destination host, the system may miss content that could be malicious when reassembled on the receiving host.

Tip In a passive deployment, Cisco recommends that you configure adaptive profiles. In an inline deployment, Cisco recommends that you configure the inline normalization preprocessor with the Normalize TCP Payload option enabled. For more information, see Normalizing Inline Traffic.

For more information on using adaptive profiles to improve reassembly of packet fragments and TCP streams, see the following topics:

- Understanding Adaptive Profiles

- Configuring Adaptive Profiles

Understanding Adaptive Profiles

License: Protection

Adaptive profiles enable use of the most appropriate operating system profiles for IP defragmentation and TCP stream preprocessing. For more information on the aspects of the network analysis policy affected by adaptive profiles, see Defragmenting IP Packets and Using TCP Stream Preprocessing.

The system can use host information detected by network discovery, obtained through an Nmap scan, or added through the host input feature to adapt processing behavior.

Note When you input host information from a third-party application using the command line import utility or the host input API, you must first map the data to product definitions so the system can use it for adaptive profiles. For more information, see Managing Third-Party Product Mappings.

Using Adaptive Profiles with Preprocessors

License: Protection

Adaptive profiles, like the target-based profiles you can configure in a network analysis policy, help to defragment IP packets and reassemble streams in the same way as the operating system on the target host. The intrusion rules engine then analyzes the data in the same format as that used by the destination host.

For example, you configure adaptive profiles for the 10.6.0.0/16 subnet and set the default IP Defragmentation target-based policy to Linux. The Defense Center where you configure the settings has a network map that includes the 10.6.0.0/16 subnet.

When a device detects traffic from Host A, which is not in the 10.6.0.0/16 subnet, it uses the Linux target-based policy to reassemble IP fragments. However, when it detects traffic from Host B, which is in the 10.6.0.0/16 subnet, it retrieves Host B’s operating system data from the network map, where Host B is listed as running Microsoft Windows XP Professional. The system uses the Windows target-based profile to do the IP defragmentation for the traffic destined for Host B.

See Defragmenting IP Packets for information on the IP Defragmentation preprocessor. See Using TCP Stream Preprocessing for information on the stream preprocessor.

Adaptive Profiles and FireSIGHT Recommended Rules

License: Protection

The adaptive profiles feature is an advanced setting in an access control policy that applies globally to all intrusion policies invoked by that access control policy. The FireSIGHT recommended rules feature applies to the individual intrusion policy where you configure it.

Like FireSIGHT recommended rules, adaptive profiles compare metadata in a rule to host information to determine whether a rule should apply for a particular host. However, while FireSIGHT recommended rules provide recommendations for enabling or disabling rules using that information, adaptive profiles use the information to apply specific rules to specific traffic.

FireSIGHT recommended rules require your interaction to implement suggested changes to rule states. Adaptive profiles, on the other hand, do not modify intrusion policies. Adaptive treatment of rules happens on a packet-by-packet basis.

Additionally, FireSIGHT recommended rules can result in enabling disabled rules. Adaptive profiles, in contrast, only affect the application of rules that are already enabled in intrusion policies. Adaptive profiles never change the rule state.

You can use adaptive profiles and FireSIGHT recommended rules in combination. Adaptive profiles use the rule state for a rule when your intrusion policy is applied to determine whether to include it as a candidate for applying, and your choices to accept or decline recommendations are reflected in that rule state. You can use both features to ensure that you have enabled or disabled the most appropriate rules for each network you monitor, and then to apply enabled rules most efficiently for specific traffic.

See Tailoring Intrusion Protection to Your Network Assets for more information.

Configuring Adaptive Profiles

License: Protection

To use host information to determine which target-based profiles are used for IP defragmentation and TCP stream preprocessing, you can configure adaptive profiles.

When you configure adaptive profiles, you need to bind the adaptive profile setting to a specific network or networks. To successfully use adaptive profiles, that network must exist in the network map and must be in the segment monitored by the devices where you apply the access control policy.

Note To use adaptive profiles, you must enable host discovery in the network discovery policy for the networks you want to protect, then reapply the network discovery policy. For more information, see Creating a Network Discovery Policy.

You can indicate the hosts in the network map where adaptive profiles should be used to process traffic by specifying an IP address, a block of addresses, or a network variable with the desired value configured in the variable set linked to the default intrusion policy for your access control policy. See Setting the Default Intrusion Policy for Access Control for more information.

You can use any of these addressing methods alone or in any combination as a list of IP addresses, address blocks, or variables separated by commas, as shown in the following example:

192.168.1.101, 192.168.4.0/24, $HOME_NET

For information on specifying address blocks in the FireSIGHT System, see IP Address Conventions.

Tip You can apply adaptive profiles to all hosts in the network map by using a variable with a value of any or by specifying 0.0.0.0/0 as the network value.

You can also control how frequently network map data is synced from the Defense Center to its managed devices. The system uses the data to determine what profiles should be used when processing traffic.

Caution Enabling or disabling adaptive profiles restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To configure adaptive profiles:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to edit.

The access control policy editor appears.

Step 3 Select the Advanced tab.

The access control policy advanced settings page appears.

.

The Detection Enhancement Settings pop-up window appears.

Step 5 Select Adaptive Profiles - Enabled to enable adaptive profiles.

Step 6 Optionally, in the Adaptive Profiles - Attribute Update Interval field, type the number of minutes that should elapse between synchronization of network map data from the Defense Center to its managed devices.

Note Increasing the value for this option could improve performance in a large network.

Step 7 In the Adaptive Profiles - Networks field, type the specific IP address, address block, or variable, or a list that includes any of these addressing methods separated by commas, to identify any host in the network map for which you want to use adaptive profiles.

See Working with Variable Sets for information on configuring variables. See Creating a Network Discovery Policy for information on configuring the network map.

Step 8 Click OK to retain your settings.

Getting Started with Intrusion Policies

Intrusion policies are defined sets of intrusion detection and prevention configurations that inspect traffic for security violations and, in inline deployments, can block or alter malicious traffic. Intrusion policies are invoked by your access control policy and are the system’s last line of defense before traffic is allowed to its destination.

Cisco delivers several intrusion policies with the FireSIGHT System. By using system-provided policies you can take advantage of the experience of the Cisco Vulnerability Research Team (VRT). For these policies, the VRT sets intrusion and preprocessor rule states (enabled or disabled), as well as provides the initial configurations for other advanced settings. An enabled rule causes the system to generate intrusion events for (and optionally block) traffic matching the rule. Disabling a rule stops processing of the rule.

Tip System-provided intrusion and network analysis policies are similarly named but contain different configurations. For example, the Balanced Security and Connectivity network analysis policy and the Balanced Security and Connectivity intrusion policy work together and can both be updated in intrusion rule updates. However, the network analysis policy governs mostly preprocessing options, whereas the intrusion policy governs mostly intrusion rules. Understanding Network Analysis and Intrusion Policies provides an overview of how network analysis and intrusion policies work together to examine your traffic, as well as some basics on using the navigation panel, resolving conflicts, and committing changes.

If you create a custom intrusion policy, you can:

- Tune detection by enabling and disabling rules, as well as by writing and adding your own rules.

- Use FireSIGHT recommendations to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets.

- Configure various advanced settings such as external alerting, sensitive data preprocessing, and global rule thresholding.

- Use layers as building blocks to efficiently manage multiple intrusion policies.

When tailoring your intrusion policy, especially when enabling and adding rules, keep in mind that some intrusion rules require that traffic first be decoded or preprocessed in a certain way. Before an intrusion policy examines a packet, the packet is preprocessed according to configurations in a network analysis policy. If you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Note Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. For more information, see Limitations of Custom Policies.

After you configure a custom intrusion policy, you can use it as part of your access control configuration by associating the intrusion policy with one or more access control rules or an access control policy’s default action. This forces the system to use the intrusion policy to examine certain allowed traffic before the traffic passes to its final destination. A variable set that you pair with the intrusion policy allows you to accurately reflect your home and external networks and, as appropriate, the servers on your network. For more information, see Controlling Traffic Using Intrusion and File Policies.

Note that by default, the system disables intrusion inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion inspection configured. For more information, see Understanding Traffic Decryption and Using the SSL Preprocessor.

This chapter explains how to create a simple custom intrusion policy. The chapter also contains basic information on managing intrusion policies: editing, comparing, and so on. For more information, see:

- Creating a Custom Intrusion Policy

- Managing Intrusion Policies

- Editing Intrusion Policies

- Applying an Intrusion Policy

- Generating a Report of Current Intrusion Settings

- Comparing Two Intrusion Policies or Revisions

Creating a Custom Intrusion Policy

License: Protection

When you create a new intrusion policy you must give it a unique name, specify a base policy, and specify drop behavior.

The base policy defines the intrusion policy’s default settings. Modifying a setting in the new policy overrides—but does not change—the settings in the base policy. You can use either a system-provided or custom policy as your base policy. For more information, see Understanding the Base Layer.

The intrusion policy’s drop behavior, or Drop when Inline setting, determines how the system handles drop rules (intrusion or preprocessor rules whose rule state is set to Drop and Generate Events) and other intrusion policy configurations that affect traffic. You should enable drop behavior in inline deployments when you want to drop or replace malicious packets. Note that in passive deployments, the system cannot affect traffic flow regardless of the drop behavior. For more information, see Setting Drop Behavior in an Inline Deployment.

To create an intrusion policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion Policy > Intrusion Policy.

The Intrusion Policy page appears.

Tip You can also import a policy from another Defense Center; see Importing and Exporting Configurations.

Step 2 Click Create Policy.

If you have unsaved changes in another policy, click Cancel when prompted to return to the Intrusion Policy page. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Create Intrusion Policy pop-up window appears.

Step 3 Give the policy a unique Name and, optionally, a Description.

Step 4 Specify the initial Base Policy.

You can use either a system-provided or custom policy as your base policy.

Step 5 Set the system’s drop behavior in an inline deployment:

- To allow intrusion policies to affect traffic and generate events, enable Drop when Inline .

- To prevent intrusion policies from affecting traffic while still generating events, disable Drop when Inline .

Step 6 Create the policy:

- Click Create Policy to create the new policy and return to the Intrusion Policy page. The new policy has the same settings as its base policy.

- Click Create and Edit Policy to create the policy and open it for editing in the advanced intrusion policy editor; see Editing Intrusion Policies.

Managing Intrusion Policies

License: Protection

On the Intrusion Policy page (Policies > Intrusion > Intrusion Policy) you can view your current custom intrusion policies, along with the following information:

- the time and date the policy was last modified (in local time) and the user who modified it

- whether the Drop when Inline setting is enabled, which allows you to drop and modify traffic in an inline deployment

- which access control policies and devices are using the intrusion policy to inspect traffic

- whether a policy has unsaved changes, as well as information about who (if anyone) is currently editing the policy

In addition to custom policies that you create, the system provides two custom policies: Initial Inline Policy and Initial Passive Policy. These two intrusion policies use the Balanced Security and Connectivity intrusion policy as their base. The only difference between them is their Drop When Inline setting, which enables drop behavior in the inline policy and disables it in the passive policy. You can edit and use these system-provided custom policies.

Options on the Intrusion Policy page allow you to take the actions in the following table.

Table 31-1 Intrusion Policy Management Actions

To...

You can...

See...

create a new intrusion policy

click Create Policy.

Creating a Custom Intrusion Policy

edit an existing intrusion policy

).

Editing Intrusion Policies

reapply an intrusion policy to your managed devices

).

Applying an Intrusion Policy

export an intrusion policy to import on another Defense Center

).

Exporting Configurations

view a PDF report that lists the current configuration settings in a intrusion policy

).

Generating a Report of Current Intrusion Settings

compare the settings of two intrusion policies or two revisions of the same policy

click Compare Policies.

Comparing Two Intrusion Policies or Revisions

delete an intrusion policy

), then confirm that you want to delete the policy. You cannot delete an intrusion policy if an access control policy references it.

Editing Intrusion Policies

License: Protection

When you create a new intrusion policy, it has the same intrusion rule and advanced settings as its base policy. The following table explains the most common actions taken when editing an intrusion policy:

Table 31-2 Intrusion Policy Editing Actions

To...

You can...

See...

specify drop behavior in an inline deployment

select or clear the Drop when Inline check box on the Policy Information page.

Setting Drop Behavior in an Inline Deployment

change the base policy

select a base policy from the Base Policy drop-down list on the Policy Information page.

Changing the Base Policy

view the settings in the base policy

click Manage Base Policy on the Policy Information page

Understanding the Base Layer

display or configure intrusion rules

click Manage Rules on the Policy Information page.

Viewing Rules in an Intrusion Policy

display a filtered view of intrusion rules by current rule state and, optionally, configure those rules

on the Policy Information page, click View next to the number of rules under Manage Rules that are set to Generate Events or to Drop and Generate Events.

Filtering Rules in an Intrusion Policy

configure FireSIGHT recommended rules

click FireSIGHT Recommendations in the navigation panel

Using FireSIGHT Recommendations

display a filtered view of intrusion rules by current recommended rule state and, optionally, configure those rules

on the Policy Information page, after you generate recommendations:

- click View next to the number of recommendations to generate events, drop and generate events, or disable rules

- click View Recommended Changes to view all recommendations

Using FireSIGHT Recommendations

enable, disable, or edit advanced settings

click Advanced Settings in the navigation panel

Configuring Advanced Settings in an Intrusion Policy

manage policy layers

click Policy Layers in the navigation panel

Using Layers in a Network Analysis or Intrusion Policy

When tailoring an intrusion policy, especially when enabling and adding rules, keep in mind that some intrusion rules require that traffic first be decoded or preprocessed in a certain way. Before an intrusion policy examines a packet, the packet is preprocessed according to configurations in a network analysis policy. If you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Note Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. For more information, see Limitations of Custom Policies.

The system caches one intrusion policy per user. While editing an intrusion policy, if you select any menu or other path to another page, your changes stay in the system cache even if you leave the page. In addition to the actions you can perform in the table above, Understanding Network Analysis and Intrusion Policies provides information on using the navigation panel, resolving conflicts, and committing changes

To edit a intrusion policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the intrusion policy you want to configure.

The intrusion policy editor appears, focused on the Policy Information page and with a navigation panel on the left.

Step 3 Edit your policy. Take any of the actions summarized above.

Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Setting Drop Behavior in an Inline Deployment

License: Protection

In an inline deployment, an intrusion policy can block and modify traffic:

- Drop rules can drop matching packets and generate intrusion events. To configure an intrusion or preprocessor drop rule, set its state to Drop and Generate Events; see Setting Rule States.

- Intrusion rules can use the replace keyword to replace malicious content; see Replacing Content in Inline Deployments.

For an intrusion rules to affect traffic, you must correctly configure drop rules and rules that replace content, as well as well as correctly deploy managed devices inline, that is, with inline interface sets. Finally, you must enable the intrusion policy’s drop behavior, or Drop when Inline setting.

Note To block the transfer of malware files over FTP, you must not only correctly configure network-based advanced malware protection (AMP), but also enable Drop when Inline in your access control policy’s default intrusion policy. To determine or change the default intrusion policy, see Setting the Default Intrusion Policy for Access Control.

If you want to assess how your configuration would function in an inline deployment without actually affecting traffic, you can disable drop behavior. In this case, the system generates intrusion events but does not drop packets that trigger drop rules. When you are satisfied with the results, you can enable drop behavior.

Note that in passive deployments or inline deployments in tap mode, the system cannot affect traffic regardless of the drop behavior. In other words, in a passive deployment, rules set to Drop and Generate Events behave identically to rules set to Generate Events—the system generates intrusion events but cannot drop packets.

When you view intrusion events, workflows can include the inline result, which indicates whether traffic was actually dropped, or whether it only would have dropped. When a packet matches a drop rule, the inline result is:

- Dropped , for packets dropped by a correctly configured inline deployment with drop behavior enabled

- Would have dropped , for packets that were not dropped either because your devices are deployed passively or because drop behavior is disabled. Note that the inline result is always Would have dropped for packets seen while the system is pruning, regardless of deployment.

To set the drop behavior of an intrusion policy in an inline deployment:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

The Policy Information page appears.

Step 3 Set the policy’s drop behavior:

- To allow intrusion rules to affect traffic and generate events, enable Drop when Inline .

- To prevent intrusion rules from affecting traffic while still generating events, disable Drop when Inline .

Step 4 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. For more information, see Resolving Conflicts and Committing Policy Changes.

Configuring Advanced Settings in an Intrusion Policy

License: Protection

An intrusion policy’s advanced settings require specific expertise to configure. The base policy for your intrusion policy determines which advanced settings are enabled by default and the default configuration for each.

When you select Advanced Settings in the navigation panel of an intrusion policy, the policy lists its advanced settings by type. On the Advanced Settings page, you can enable or disable advanced settings in your intrusion policy, as well as access advanced setting configuration pages.

An advanced setting must be enabled for you to configure it. When you enable an advanced setting, a sublink to the configuration page for the advanced setting appears beneath the Advanced Settings link in the navigation panel, and an Edit link to the configuration page appears next to the advanced setting on the Advanced Settings page.

Tip To revert an advanced setting’s configuration to the settings in the base policy, click Revert to Defaults on the configuration page for the advanced setting. When prompted, confirm that you want to revert.

When you disable an advanced setting, the sublink and Edit link no longer appear, but your configurations are retained. Note that some intrusion policy configurations (sensitive data rules, SNMP alerts for intrusion rules) require enabled and correctly configured advanced settings. You cannot save an intrusion policy misconfigured in this way; see Resolving Conflicts and Committing Policy Changes.

Modifying the configuration of an advanced setting requires an understanding of the configuration you are modifying and its potential impact on your network. The following sections provide links to specific configuration details for each advanced setting.

Specific Threat Detection

The sensitive data preprocessor detects sensitive data such as credit card numbers and Social Security numbers in ASCII text. For information on configuring this preprocessor, see Detecting Sensitive Data.

Note that other preprocessors that detect specific threats (back orifice attacks, several portscan types, and rate-based attacks that attempt to overwhelm your network with excessive traffic) are configured in network analysis policies. For more information, see Detecting Specific Threats.

Intrusion Rule Thresholds

Global rule thresholding can prevent your system from being overwhelmed with a large number of events by allowing you to use thresholds to limit the number of times the system logs and displays intrusion events. For more information, see Globally Limiting Intrusion Event Logging.

External Responses

In addition to the various views of intrusion events within the web interface, you can enable logging to system log (syslog) facilities or send event data to an SNMP trap server. Per policy, you can specify intrusion event notification limits, set up intrusion event notification to external logging facilities, and configure external responses to intrusion events. For more information, see:

- Configuring SNMP Responses

- Configuring Syslog Responses

Note that in addition to these per-policy alerting configurations, you can globally enable or disable email alerting on intrusion events for each rule or rule group. Your email alert settings are used regardless of which intrusion policy processes a packet. For more information, see Understanding Email Alerting.

Applying an Intrusion Policy

License: Protection

After you apply an intrusion policy to a managed device using access control (see Applying an Access Control Policy), you can reapply the intrusion policy at any time. This allows you to implement intrusion policy changes on your monitored network without reapplying the access control policy. While reapplying, you can also view a comparison report to review the changes made since the last time the intrusion policy was applied.

Caution When you reapply an intrusion policy, resource demands may result in a small number of packets dropping without inspection. Additionally, reapplying an intrusion policy after importing an intrusion rule update that includes a new or updated shared object rule restarts the Snort process, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See Configurations that Restart the Snort Process and How Snort Restarts Affect Traffic for more information.

Note the following when reapplying intrusion policies:

- You can schedule intrusion policy reapply tasks to recur on a regular basis; see Automating Applying an Intrusion Policy.

- An intrusion policy reapply fails on invalid target devices. For example, if you apply an access control policy that removes a previously applied intrusion policy from a device and then attempt to reapply the intrusion policy before the access control policy apply task resolves, the intrusion policy reapply fails.

- You cannot apply intrusion policies to stacked devices running different versions of the FireSIGHT System (for example, if an upgrade on one of the devices fails). You can reapply an intrusion policy to a device stack, but not to individual devices within the stack.

- When you import a rule update, you can automatically apply intrusion policies after the import completes. If you do not enable this option, you must manually reapply the policies changed by the rule update. See Importing Rule Updates and Local Rule Files for more information.

- If the Snort version on the Defense Center differs from that on the managed device, you cannot apply an intrusion policy to the device without applying the access control policy. If intrusion policy apply fails for this reason, reapply the entire access control policy instead.

- On devices with limited memory, the number of intrusion policies may not be paired with more than one variable set. in the case where you can apply an access control policy that references only one intrusion policy, verify every reference to the intrusion policy is paired with the same variable set.

To reapply an intrusion policy:

Access: Admin/Security Approver

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to reapply.

Step 4 Click Reapply.

The policy is reapplied. You can monitor the status of the apply using the task queue (System > Monitoring > Task Status). See Viewing the Task Queue for more information.

Generating a Report of Current Intrusion Settings

License: Protection

An intrusion policy report is a record of the policy configuration at a specific point in time. The system combines the settings in the base policy with the settings of the policy layers, and makes no distinction between which settings originated in the base policy or policy layer.

Table 31-3 Intrusion Policy Report Sections

Section

Description

Policy Information

Provides the name and description of the intrusion policy, the name of the user who last modified the policy, and the date and time the policy was last modified. Also indicates whether dropping packets in an inline deployment is enabled or disabled, the current rule update version, and whether the base policy is locked to the current rule update.

FireSIGHT Recommendations

Provides information on any recommended rule states based on the hosts and applications in your network. Optionally, it includes differences between recommendations and rule states in policy reports if you enabled that setting when you configured FireSIGHT recommendations

Advanced Settings

Lists all enabled intrusion policy advanced settings and their configurations.

Rules

Provides a list of all enabled rules and their actions.

You can also generate a comparison report that compares two intrusion policies, or two revisions of the same policy. For more information, see Comparing Two Intrusion Policies or Revisions.

To view an intrusion policy report:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the intrusion policy for which you want to generate a report. Remember to commit any potential changes before you generate an intrusion policy report; only committed changes appear in the report.

The system generates the intrusion policy report. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Comparing Two Intrusion Policies or Revisions

License: Protection

To review policy changes for compliance with your organization’s standards or to optimize system performance, you can examine the differences between two intrusion policies. You can compare any two intrusion policies or two revisions of the same intrusion policy, for the intrusion policies you can access. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies or policy revisions.

There are two tools you can use to compare intrusion policies or intrusion policy revisions:

- The comparison view displays only the differences between two intrusion policies or intrusion policy revisions in a side-by-side format; the name of each policy or policy revision appears in the title bar on the left and right sides of the comparison view.

You can use this to view and navigate both policy revisions on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two intrusion policies or intrusion policy revisions in a format similar to the intrusion policy report, but in PDF format.

You can use this to save, copy, print and share your policy comparisons for further examination.

For more information on understanding and using the intrusion policy comparison tools, see:

- Using the Intrusion Policy Comparison View

- Using the Intrusion Policy Comparison Report

Using the Intrusion Policy Comparison View

License: Protection

The comparison view displays both intrusion policies or policy revisions in a side-by-side format, with each policy or policy revision identified by name in the title bar on the left and right sides of the comparison view. The time of last modification and the last user to modify are displayed to the right of the policy name. Note that the Intrusion Policy page displays the time a policy was last modified in local time, but the intrusion policy report lists the time modified in UTC. Differences between the two intrusion policies or policy revisions are highlighted:

- Blue indicates that the highlighted setting is different in the two policies or policy revisions, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy or policy revision but not the other.

The window displays the name of the layer that contains the advanced configuration.

Table 31-4 Intrusion Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

determine which layer contains the configuration for a specific advanced setting

) next to the configuration you want to view.

generate a new intrusion policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the Intrusion Policy Comparison Report for more information.

generate an intrusion policy comparison report

click Comparison Report.

The policy comparison report creates a PDF that lists only the differences between the two policies or policy revisions.

Using the Intrusion Policy Comparison Report

License: Protection

An intrusion policy comparison report is a record of all differences between two intrusion policies or two revisions of the same intrusion policy identified by the intrusion policy comparison view, presented as a PDF. You can use this report to further examine the differences between two intrusion policy configurations and to save and disseminate your findings.

You can generate an intrusion policy comparison report from the comparison view for any intrusion policies to which you have access. Remember to commit any potential changes before you generate an intrusion policy report; only committed changes appear in the report.

The format of the intrusion policy comparison report is the same as the intrusion policy report with one exception: the intrusion policy report contains all settings in the intrusion policy, and the intrusion policy comparison report lists only those settings which differ between the policies.

Depending on your configuration, an intrusion policy comparison report can contain one or more sections as described in the Intrusion Policy Report Sections table.

Tip You can use a similar procedure to compare SSL, access control, network analysis, file, system, or health policies.

To compare two intrusion policies or two revisions of the same policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

- To compare two revisions of the same policy, select Other Revision .

Remember to commit any changes before you generate an intrusion policy report; only committed changes appear in the report.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing two revisions of the same policy, select the policy from the Policy drop-down list, then select the revisions you want to compare from the Revision A and Revision B drop-down lists.

Step 5 Click OK to display the intrusion policy comparison view.

The comparison view appears.

Step 6 Click Comparison Report to generate the intrusion policy comparison report.

Step 7 The intrusion policy report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Tuning Intrusion Policies Using Rules

You can use the Rules page in an intrusion policy to configure rule states and other settings for shared object rules, standard text rules, and preprocessor rules.

You enable a rule by setting its rule state to Generate Events or to Drop and Generate Events. Enabling a rule causes the system to generate events on traffic matching the rule. Disabling a rule stops processing of the rule. Optionally, you can set your intrusion policy so that a rule set to Drop and Generate Events in an inline deployment generates events on, and drops, matching traffic. See Setting Drop Behavior in an Inline Deployment for more information. In a passive deployment, a rule set to Drop and Generate Events just generates events on matching traffic.

You can filter rules to display a subset of rules, enabling you to select the exact set of rules where you want to change rule states or rule settings.

When an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses it with its current configuration even though it remains disabled in the network analysis policy’s web interface. For more information, see Limitations of Custom Policies.

See the following sections for more information:

- Understanding Intrusion Prevention Rule Types describes the intrusion rules and preprocessor rules you can view and configure in an intrusion policy.

- Viewing Rules in an Intrusion Policy describes how you can change the order of rules on the Rules page, interpret the icons on the page, and focus in on rule details.

- Filtering Rules in an Intrusion Policy describes how you can use rule filters to find the rules for which you want to apply rule settings.

- Setting Rule States describes how to enable and disable rules from the Rules page.

- Filtering Intrusion Event Notification Per Policy explains how to set event filtering thresholds for specific rules and set suppression on specific rules.

- Adding Dynamic Rule States explains how to set rule states that trigger dynamically when rate anomalies are detected in matching traffic.

- Adding SNMP Alerts describes how to associate SNMP alerts with specific rules.

- Adding Rule Comments describes how to add comments to rules in an intrusion policy.

Understanding Intrusion Prevention Rule Types

License: Protection

An intrusion policy contains two types of rules: intrusion rules and preprocessor rules.

An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit vulnerabilities on your network; an intrusion rule analyzes network traffic to check if it matches the criteria in the rule. The system compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in a rule, the rule triggers. The system includes two types of intrusion rules created by the Cisco Vulnerability Research Team (VRT): shared object rules, which are compiled and cannot be modified (except for rule header information such as source and destination ports and IP addresses), and standard text rules, which can be saved and modified as new custom instances of the rule.

The system also includes preprocessor rules, which are rules associated with preprocessor and packet decoder detection options. You cannot copy or edit preprocessor rules. Most preprocessor rules are disabled by default and must be enabled (that is, set to Generate Events or to Drop and Generate Events) if you want the system to generate events for preprocessor rules and, in an inline deployment, drop offending packets.

The VRT determines the default rule states of Cisco’s shared object rules, standard text rules, and preprocessor rules for each default intrusion policy included with the system.

Table 32-1 Rule types

Type

Description

shared object rule

An intrusion rule created by the Cisco Vulnerability Research Team (VRT) that is delivered as a binary module compiled from C source code. You can use shared object rules to detect attacks in ways that standard text rules cannot. You cannot modify the rule keywords and arguments in a shared object rule; you are limited to either modifying variables used in the rule, or modifying aspects such as the source and destination ports and IP addresses and saving a new instance of the rule as a custom shared object rule. A shared object rule has a GID (generator ID) of 3. See Modifying Existing Rules for more information.

standard text rule

An intrusion rule either created by the VRT, copied and saved as a new custom rule, created using the rule editor, or imported as a local rule that you create on a local machine and import. You cannot modify the rule keywords and arguments in a standard rule created by the VRT; you are limited to either modifying variables used in the rule, or modifying aspects such as the source and destination ports and IP addresses and saving a new instance of the rule as a custom standard text rule. See Modifying Existing Rules, Understanding and Writing Intrusion Rules and Importing Local Rule Files for more information. A standard text rule created by the VRT has a GID (generator ID) of 1. Custom standard text rules that you create using the rule editor or import as local rules have a SID (Signature ID) of 1000000 or greater.

preprocessor rule

A rule associated with a detection option of the packet decoder or with one of the preprocessors included with the FireSIGHT System. You must enable preprocessor rules if you want them to generate events. These rules have a decoder- or preprocessor-specific GID (generator ID). See the Generator IDs table for more information.

Viewing Rules in an Intrusion Policy

License: Protection

You can adjust how rules are displayed in the intrusion policy, and can sort rules by several criteria. You can also display the details for a specific rule to see rule settings, rule documentation, and other rule specifics.

The Rules page has four primary areas of functionality:

- the filtering features—for more information, see Filtering Rules in an Intrusion Policy

- the rule attribute menus—for more information, see Setting Rule States, Filtering Intrusion Event Notification Per Policy, Adding Dynamic Rule States, Adding SNMP Alerts, and Adding Rule Comments

- the rules listing—for more information, see the Rules Page Columns table.

- the rule details—for more information, see Viewing Rule Details

You can also sort rules by different criteria; for more information, see Sorting the Rule Display.

) as the Rule State column.

Table 32-2 Rules Page Columns

Heading

Description

For more information, see...

GID

Integer which indicates the Generator ID (GID) for the rule.

Reading Preprocessor Generator IDs

SID

Integer which indicates the Snort ID (SID), which acts a unique identifier for the rule.

Reading Preprocessor Generator IDs

Message

Message included in events generated by this rule, which also acts as the name of the rule.

Defining the Event Message

The rule state for the rule, which may be one of three states:

- drop and generate events (

)

- generate events (

)

- disable (

)

Note that you can access the Set rule state dialog box for a rule by clicking on its rule state icon.

Setting Rule States

FireSIGHT recommended rule state for the rule.

Tailoring Intrusion Protection to Your Network Assets

Event filter, including event thresholds and event suppression, applied to the rule.

Filtering Intrusion Event Notification Per Policy

Dynamic rule state for the rule, which goes into effect if specified rate anomalies occur.

Adding Dynamic Rule States

Alerts configured for the rule (currently SNMP alerts only).

Adding SNMP Alerts

Comments added to the rule.

Adding Rule Comments

You can also use the layer drop-down list to switch to the Rules page for other layers in your policy. Note that, unless you add layers to your policy, the only editable views listed in the drop-down list are the policy Rules page and the Rules page for a policy layer that is originally named My Changes; note also that making changes in one of these views is the same as making the changes in the other. See Using Layers in a Network Analysis or Intrusion Policy for more information. The drop-down list also lists the Rules page for the read-only base policy. See Understanding the Base Layer for information on the base policy.

To view the rules in an intrusion policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules on the Policy Information page.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Note that selecting Rules above the dividing line in the navigation panel takes you to the same rules listing. You can view and set all rule attributes in your policy in this view.

Sorting the Rule Display

License: Protection

You can sort rules by any of the columns in the Rules page by clicking on the heading title or icon.

) arrow on a heading or icon indicates that the sort is on that column in that direction.

To sort rules in an intrusion policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Click the title or icon in the top of the column you want to sort by.

The rules are sorted by the column, in the direction indicated by the arrow that appears on the column heading. To sort in the opposite direction, click the heading again. The sort order and the arrow reverse.

Viewing Rule Details

License: Protection

You can view rule documentation, FireSIGHT recommendations, and rule overhead from the Rule Detail view. You can also view and add rule-specific features.

Table 32-3 Rule Details

Item

Description

For more information, see...

Summary

The rule summary. For rule-based events, this row appears when the rule documentation contains summary information.

Viewing Event Information

Rule State

The current rule state for the rule. Also indicates the layer where the rule state is set.

Setting Rule States; Using Layers in a Network Analysis or Intrusion Policy

FireSIGHT Recommendation

If FireSIGHT recommendations have been generated, the recommended rule state for the rule.

Tailoring Intrusion Protection to Your Network Assets

Rule Overhead

The rule’s potential impact on system performance and the likelihood that the rule might generate false positives.

Understanding Rule Overhead

Thresholds

Thresholds currently set for this rule, as well as the facility to add a threshold for the rule.

Setting a Threshold for a Rule

Suppressions

Suppression settings currently set for this rule, as well as the facility to add suppressions for the rule.

Setting Suppression for a Rule

Dynamic State

Rate-based rule states currently set for this rule, as well as the facility to add dynamic rule states for the rule.

Setting a Dynamic Rule State for a Rule

Alerts

Alerts currently set for this rule, as well as the facility to add an alert for the rule. Currently, only SNMP alerts are supported.

Setting an SNMP Alert for a Rule

Comments

Comments added to this rule, as well as the facility to add comments for the rule.

Adding a Rule Comment for a Rule

Documentation

The rule documentation for the current rule, supplied by the Cisco Vulnerability Research Team (VRT).

Using Packet View Actions

To view rule details:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Highlight the rule whose rule details you want to view.

Step 5 Click Show details.

The Rule Detail view appears. To hide the details again, click Hide details.

Tip You can also open Rule Detail by double-clicking a rule in the Rules view.

Setting a Threshold for a Rule

License: Protection

You can set a single threshold for a rule from the Rule Detail page. Adding a threshold overwrites any existing threshold for the rule. For more information on thresholding, see Configuring Event Thresholding.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

To set a threshold from the rule details:

Access: Admin/Intrusion Admin

Step 1 Click Add next to Thresholds.

The Set Threshold dialog box appears.

Step 2 From the Type drop-down list, select the type of threshold you want to set:

- Select Limit to limit notification to the specified number of event instances per time period.

- Select Threshold to provide notification for each specified number of event instances per time period.

- Select Both to provide notification once per time period after a specified number of event instances.

Step 3 From the Track By drop-down list, select Source or Destination to indicate whether you want the event instances tracked by source or destination IP address.

Step 4 In the Count field, type the number of event instances you want to use as your threshold.

Step 5 In the Seconds field, type a number between 0 and 2147483647 that specifies the time period, in seconds, for which event instances are tracked.

Step 6 Click OK.

) next to the rule in the Event Filtering column. If you add multiple event filters to a rule, the system includes an indication over the icon of the number of event filters.

Setting Suppression for a Rule

License: Protection

You can set one or more suppressions for a rule from the Rule Detail page. For more information on suppression, see Configuring Suppression Per Intrusion Policy.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

To set suppression from the rule details:

Access: Admin/Intrusion Admin

Step 1 Click Add next to Suppressions.

The Add Suppression dialog box appears.

Step 2 From the Suppression Type drop-down list, select one of the following options:

- Select Rule to completely suppress events for a selected rule.

- Select Source to suppress events generated by packets originating from a specified source IP address.

- Select Destination to suppress events generated by packets going to a specified destination IP address.

Step 3 If you selected Source or Destination for the suppression type, the Network field appears. In the Network field, enter the IP address, an address block, or a comma-separated list comprised of any combination of these. If the intrusion policy is associated with the default action of an access control policy, you can also specify or list a network variable in the default action variable set.

For information on using IPv4 CIDR and IPv6 prefix length address blocks in the FireSIGHT System, see IP Address Conventions.

Step 4 Click OK.

) next to the rule in the Event Filtering column next the suppressed rule. If you add multiple event filters to a rule, a number over the icon indicates the number of filters.

Setting a Dynamic Rule State for a Rule

License: Protection

You can set one or more dynamic rule states for a rule from the Rule Detail page. The first dynamic rule state listed has the highest priority. Note that when two dynamic rule states conflict, the action of the first is carried out. For more information on dynamic rule states, see Understanding Dynamic Rule States.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

To set a dynamic rule state from the rule details:

Access: Admin/Intrusion Admin

Step 1 Click Add next to Dynamic State.

The Add Rate-Based Rule State dialog box appears.

Step 2 From the Track By drop-down list, select an option to indicate how you want the rule matches tracked:

- Select Source to track the number of hits for that rule from a specific source or set of sources.

- Select Destination to track the number of hits for that rule to a specific destination or set of destinations.

- Select Rule to track all matches for that rule.

Step 3 Optionally, if you set Track By to Source or Destination, enter the IP address of each host you want to track in the Network field.

For information on using IPv4 CIDR and IPv6 prefix length notation in the FireSIGHT System, see IP Address Conventions.

Step 4 Next to Rate, indicate the number of rule matches per time period to set the attack rate:

- In the Count field, using an integer between 0 and 2147483647, specify the number of rule matches you want to use as your threshold.

- In the Seconds field, using an integer between 0 and 2147483647, specify the number of seconds that make up the time period for which attacks are tracked.

Step 5 From the New State drop-down list, select the new action to be taken when the conditions are met:

- Select Generate Events to generate an event.

- Select Drop and Generate Events to generate an event and drop the packet that triggered the event in inline deployments or to generate an event in passive deployments.

- Select Disabled to take no action.

Step 6 In the Timeout field, using an integer between 1 and 2147483647 (approximately 68 years), type the number of seconds you want the new action to remain in effect. After the timeout occurs, the rule reverts to its original state. Specify 0 to prevent the new action from timing out.

Step 7 Click OK.

) next to the rule in the Dynamic State column. If you add multiple dynamic rule state filters to a rule, a number over the icon indicates the number of filters.

If any required fields are blank, you receive an error message indicating which fields you must fill.

Setting an SNMP Alert for a Rule

License: Protection

You can set an SNMP alert for a rule from the Rule Detail page. For more information on SNMP alerts, see Adding SNMP Alerts.

To add an SNMP alert from the rule details:

Access: Admin/Intrusion Admin

Step 1 Click Add SNMP Alert next to Alerts.

) next to the rule in the Alerting column. If you add multiple alerts to a rule, the system includes an indication over the icon of the number of alerts.

Adding a Rule Comment for a Rule

License: Protection

You can add a rule comment for a rule from the Rule Detail page. For more information on rule comments, see Adding Rule Comments.

To add a comment from the rule details:

Access: Admin/Intrusion Admin

Step 1 Click Add next to Comments.

The Add Comment dialog box appears.

Step 2 In the Comment field, type the rule comment.

Step 3 Click OK.

) next to the rule in the Comments column. If you add multiple comments to a rule, a number over the icon indicates the number of comments.

Tip To delete a rule comment, click Delete in the rule comments section. Note that you can only delete a comment if the comment is cached with uncommitted intrusion policy changes. After intrusion policy changes are committed, the rule comment is permanent.

Filtering Rules in an Intrusion Policy

License: Protection

You can filter the rules you display on the Rules page by a single criteria, or a combination of one or more criteria.

The filter you construct is shown in the Filter text box. You can click keywords and keyword arguments in the filter panel to construct a filter. When you select multiple keywords, the system combines them using AND logic to create a compound search filter. For example, if you select preprocessor under Category and then select Rule Content > GID and enter 116, you get a filter of Category: “preprocessor” GID:”116” which retrieves all rules that are preprocessor rules and have a GID of 116.

The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, Preprocessor, and Priority filter groups allow you to submit more than one argument for a keyword, separated by commas. For example, you can press Shift and then select os-linux and os-windows from Category to produce the filter Category:"os-windows,os-linux", which retrieves any rules in the os-linux category or in the os-windows category.

).

).

For more information, see the following topics:

- Understanding Rule Filtering in an Intrusion Policy

- Setting a Rule Filter in an Intrusion Policy

Understanding Rule Filtering in an Intrusion Policy

License: Protection

Rule filter keywords help you find the rules for which you want to apply rule settings, such as rule states or event filters. You can filter by a keyword and simultaneously select the argument for the keyword by selecting the argument you want from the Rules page filter panel.

For more information, see the following sections:

- Guidelines for Constructing Intrusion Policy Rule Filters

- Understanding Rule Configuration Filters

- Understanding Rule Content Filters

- Understanding Rule Categories

- Editing a Rule Filter Directly

Guidelines for Constructing Intrusion Policy Rule Filters

License: Protection

In most cases, when you are building a filter, you can use the filter panel to the left of the Rules page in the intrusion policy to select the keywords/arguments you want to use.

Rule filters are grouped into rule filter groups in the filter panel. Many rule filter groups contain sub-criteria so that you can more easily find the specific rules you are looking for. Some rule filters have multiple levels that you can expand to drill down to individual rules.

Items in the filter panel sometimes represent filter type groups, sometimes represent keywords, and sometimes represent the argument to a keyword. Use the following rules of thumb to help you build your filters:

- When you select a filter type group heading that is not a keyword (Rule Configuration, Rule Content, Platform Specific, and Priority), it expands to list the available keywords.

When you select a keyword by clicking on a node in the criteria list, a pop-up window appears, where you supply the argument you want to filter by.

If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

For example, if you click Drop and Generate Events under Rule Configuration > Recommendation in the filter panel, Recommendation:"Drop and Generate Events" is added to the filter text box. If you then click Generate Events under Rule Configuration > Recommendation, the filter changes to Recommendation:"Generate Events".

- When you select a filter type group heading that is a keyword (Category, Classifications, Microsoft Vulnerabilities, Microsoft Worms, Priority, and Rule Update), it lists the available arguments.

When you select an item from this type of group, the argument and the keyword it applies to are immediately added to the filter. If the keyword is already in the filter, it replaces the existing argument for the keyword that corresponds to that group.

For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added to the filter text box. If you then click os-windows under Category, the filter changes to Category:"os-windows".

- Reference under Rule Content is a keyword, and so are the specific reference ID types listed below it. When you select any of the reference keywords, a pop-up window appears, where you supply an argument and the keyword is added to the existing filter. If the keyword is already in use in the filter, the new argument you supply replaces the existing argument.

For example, if you click Rule Content > Reference > CVE ID in the filter panel, a pop-up window prompts you to supply the CVE ID. If you enter 2007, then CVE:”2007” is added to the filter text box. In another example, if you click Rule Content > Reference in the filter panel, a pop-up window prompts you to supply the reference. If you enter 2007, then Reference:”2007” is added to the filter text box.

- When you select rule filter keywords from different groups, each filter keyword is added to the filter and any existing keywords are maintained (unless overridden by a new value for the same keyword).

For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added to the filter text box. If you then click MS00-006 under Microsoft Vulnerabilities, the filter changes to Category:"os-linux" MicrosoftVulnerabilities:"MS00-006".

- When you select multiple keywords, the system combines them using AND logic to create a compound search filter. For example, if you select preprocessor under Category and then select Rule Content > GID and enter 116 , you get a filter of Category: “preprocessor” GID:”116” , which retrieves all rules that are preprocessor rules and have a GID of 116.

- The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, and Priority filter groups allow you to submit more than one argument for a keyword, separated by commas. For example, you can press Shift and then select os-linux and os-windows from Category to produce the filter Category:"os-windows,app-detect" , which retrieves any rules in the os-linux category or in the os-windows category.

The same rule may be retrieved by more than one filter keyword/argument pair. For example, the DOS Cisco attempt rule (SID 1545) appears if rules are filtered by the dos category, and also if you filter by the High priority.

Note The Cisco VRT may use the rule update mechanism to add and remove rule filters.

Table 32-4 Rule Filter Groups

Filter Group

Description

Multiple Argument Support?

Heading is...

Items in List are...

Rule Configuration

Finds rules according to the configuration of the rule. See Understanding Rule Configuration Filters.

No

A grouping

keywords

Rule Content

Finds rules according to the content of the rule. See Understanding Rule Content Filters.

No

A grouping

keywords

Category

Finds rules according to the rule categories used by the rule editor. Note that local rules appear in the local sub-group. See Understanding Rule Categories.

Yes

A keyword

arguments

Classifications

Finds rules according to the attack classification that appears in the packet display of an event generated by the rule. See Searching for Intrusion Events and Defining the Intrusion Event Classification.

No

A keyword

arguments

Microsoft Vulnerabilities

Finds rules according to Microsoft bulletin number.

Yes

A keyword

arguments

Microsoft Worms

Finds rules based on specific worms that affect Microsoft Windows hosts.

Yes

A keyword

arguments

Platform Specific

Finds rules according to their relevance to specific versions of operating systems.

Note that a rule may affect more than one operating system or more than one version of an operating system. For example, enabling SID 2260 affects multiple versions of Mac OS X, IBM AIX, and other operating systems.

Yes

A keyword

arguments

Note that if you pick one of the items from the sub-list, it adds a modifier to the argument.

Preprocessors

Finds rules for individual preprocessors.

Note that you must enable preprocessor rules associated with a preprocessor option to generate events for the option when the preprocessor is enabled; see Setting Rule States.

Yes

A grouping

sub-groupings

Priority

Finds rules according to high, medium, and low priorities.

The classification assigned to a rule determines its priority. These groups are further grouped into rule categories. Note that local rules (that is, rules that you create) do not appear in the priority groups.

Yes

A keyword

arguments

Note that if you pick one of the items from the sub-list, it adds a modifier to the argument.

Rule Update

Finds rules added or modified through a specific rule update. For each rule update, view all rules in the update, only new rules imported in the update, or only existing rules changed by the update.

No

A keyword

arguments

Understanding Rule Configuration Filters

License: Protection

You can filter the rules listed in the Rules page by several rule configuration settings. For example, if you want to view the set of rules whose rule state does not match the recommended rule state, you can filter on rule state by selecting Does not match recommendation.

When you select a keyword by clicking on a node in the criteria list, a pop-up window appears, where you supply the argument you want to filter by.

If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

For example, if you click Drop and Generate Events under Rule Configuration > Recommendation in the filter panel, Recommendation:"Drop and Generate Events" is added to the filter text box. If you then click Generate Events under Rule Configuration > Recommendation, the filter changes to Recommendation:"Generate Events".

See the following procedures for more information on the rule configuration settings you can use to filter.

To use the Rule State filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Rule State.

Step 2 From the Rule State drop-down list, select the rule state to filter by:

- To find rules that only generate events, select Generate Events , then click OK .

- To find rules that are set to generate events and drop the matching packet, select Drop and Generate Events , then click OK .

- To find disabled rules, select Disabled , then click OK .

- To find rules whose rule state does not match the recommended state, select Does not match recommendation , then click OK .

The Rules page updates to display rules according to current rule state.

To use the Recommendation filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Recommendation.

Step 2 From the Recommendation drop-down list, select the FireSIGHT rule state recommendation to filter by, then click OK.

The Rules page updates to display rules according to recommended rule state.

To use the Threshold filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Threshold.

Step 2 From the Threshold drop-down list, select the threshold setting to filter by:

- To find rules with a threshold type of limit , select Limit , then click OK .

- To find rules with a threshold type of threshold , select Threshold , then click OK .

- To find rules with a threshold type of both , select Both , then click OK .

- To find rules with thresholds tracked by source , select Source , then click OK .

- To find rules with thresholds tracked by destination , select Destination , then click OK .

- To find any rule with a threshold set, select All , then click OK .

The Rules page updates to display rules where the type of threshold indicated in the filter has been applied to the rule.

To use the Suppression filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Suppression.

Step 2 From the Suppression drop-down list, select the suppression setting to filter by:

- To find rules where events are suppressed for packets inspected by that rule, select By Rule , then click OK .

- To find rules where events are suppressed based on the source of the traffic, select By Source , then click OK .

- To find rules where events are suppressed based on the destination of the traffic, select By Destination , then click OK .

- To find any rule with suppression set, select All , then click OK .

The Rules page updates to display rules where the type of suppression indicated in the filter has been applied to the rule.

To use the Dynamic State filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Dynamic State.

Step 2 From the Dynamic State drop-down list, select the suppression setting to filter by:

- To find rules where a dynamic state is configured for packets inspected by that rule, select By Rule , then click OK .

- To find rules where a dynamic state is configured for packets based on the source of the traffic, select By Source , then click OK .

- To find rules where a dynamic state is configured based on the destination of the traffic, select By Destination , then click OK .

- To find rules where a dynamic state of Generate Events is configured, select Generate Events , then click OK .

- To find rules where a dynamic state of Drop and Generate Events is configured, select Drop and Generate Events , then click OK .

- To find where a dynamic state of Disabled is configured, select Disabled , then click OK .

- To find any rule with suppression set, select All , then click OK .

The Rules page updates to display rules where the dynamic rule state indicated in the filter has been applied to the rule.

To use the Alert filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Alert.

Step 2 From the Alert drop-down list, select the alert setting to filter by: SNMP.

Step 3 Click OK.

The Rules page updates to display rules where you have applied an alert filter.

To use the Comment filter:

Access: Admin/Intrusion Admin

Step 1 Under Rule Configuration, click Comment.

Step 2 In the Comment field, type the string of comment text to filter by, then click OK.

The Rules page updates to display rules where comments applied to the rule contain the string indicated in the filter.

Understanding Rule Content Filters

License: Protection

You can filter the rules listed in the Rules page by several rule content items. For example, you can quickly retrieve a rule by searching for the rule’s SID. You can also find all rules that inspect traffic going to a specific destination port.

When you select a keyword by clicking on a node in the criteria list, a pop-up window appears, where you supply the argument you want to filter by.

If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

For example, if you click SID under Rule Content in the filter panel, a pop-up window appears, prompting you to supply a SID. If you type 1045, then SID:”1045”is added to the filter text box. If you then click SID again and change the SID filter to 1044, the filter changes to SID:”1044”.

For more information on the rule content you can use to filter, see the following table.

Table 32-5 Rule Content Filters

To use this filter, click...

Then...

Result

Message

Type the message string to filter by, then click OK.

Finds rules that contain the supplied string in the message field.

SID

Type the SID number to filter by, then click OK.

Finds rules that have the specified SID.

GID

Type the GID number to filter by, then click OK.

Finds rules that have the specified GID.

Reference

Type the reference string to filter by, then click OK.

To enter a string for a specific type of reference that you want to filter by, select CVE ID, URL, Bugtraq ID, Nessus ID, Arachnids ID, or Mcafee ID, then type a string and click OK.

Finds rules that contain the supplied string in the reference field.

Action

Select the action to filter by:

- To find alert rules, select Alert , then click OK .

- To find pass rules, select Pass , then click OK .

Finds rules that start with alert or pass.

Protocol

Select the protocol to filter by: ICMP, IP, TCP, or UDP; then click OK.

Finds rules that include the selected protocol.

Direction

Select a directional setting to filter by:

- To find rules that inspect traffic moving in a specific direction, select Directional , then click OK .

- To find rules that inspect traffic moving in either direction between a source and destination, select Bidirectional , then click OK .

Finds rules based on whether the rule includes the indicated directional setting.

Source IP

Type the source IP address to filter by, then click OK.

Note that you can filter by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or $EXTERNAL_NET.

Finds rules that use the specified addresses or variables for the source IP address designation in the rule.

Destination IP

Type the destination IP address to filter by, then click OK.

Note that you can filter by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or $EXTERNAL_NET.

Finds rules that use the specified addresses or variables for the source IP address designation in the rule.

Source port

Type the source port to filter by, then click OK.

The port value must be an integer between 1 and 65535 or a port variable.

Finds rules that include the specified source port.

Destination port

Type the destination port to filter by, then click OK.

The port value must be an integer between 1 and 65535 or a port variable.

Finds rules that include the specified destination port.

Rule Overhead

Select the amount of rule overhead to filter by: Low, Medium, High, or Very High; then click OK.

Finds rules with the selected rule overhead.

Metadata

Type the metadata key-value pair to filter by, separated by a space; then click OK.

For example, type metadata:”service http” to locate rules with metadata relating to the HTTP application protocol.

Find rules with metadata containing the matching key-value pair.

Understanding Rule Categories

License: Protection

The FireSIGHT System places rules in categories based on the type of traffic the rule detects. On the Rules page, you can filter by rule category, so you can set a rule attribute for all rules in a category. For example, if you do not have Linux hosts on your network, you could filter by the os-linux category, then disable all the rules showing to disable the entire os-linux category.

You can hover your pointer over a category name to display the number of rules in that category.

Note The Cisco VRT may use the rule update mechanism to add and remove rule categories.

Editing a Rule Filter Directly

License: Protection

You can edit your filter to modify the special keywords and their arguments that are supplied when you click on a filter in the filter panel. Custom filters on the Rules page function like those used in the rule editor, but you can also use any of the keywords supplied in the Rules page filter, using the syntax displayed when you select the filter through the filter panel. To determine a keyword for future use, click on the appropriate argument in the filter panel on the right. The filter keyword and argument syntax appear in the filter text box.

To see lists of arguments for keywords which only support specific values, see Understanding Rule Configuration Filters, Understanding Rule Content Filters, and Understanding Rule Categories. Remember that comma-separated multiple arguments for a keyword are only supported for the Category and Priority filter types.

You can use keywords and arguments, character strings, and literal character strings in quotes, with spaces separating multiple filter conditions. A filter cannot include regular expressions, wild card characters, or any special operator such as a negation character (!), a greater than symbol (>), less than symbol (<), and so on. When you type in search terms without a keyword, without initial capitalization of the keyword, or without quotes around the argument, the search is treated as a string search and the category, message, and SID fields are searched for the specified terms.

All keywords, keyword arguments, and character strings are case-insensitive. Except for the gid and sid keywords, all arguments and strings are treated as partial strings. Arguments for gid and sid return only exact matches.

Each rule filter can include one or more keywords in the format:

Keyword:”argument”

where keyword is one of the keywords in the filter groups described in the Rule types table and argument is enclosed in double quotes and is a single, case-insensitive, alphanumeric string to search for in the specific field or fields relevant to the keyword. Note that keywords should be typed with initial capitalization.

Arguments for all keywords except gid and sid are treated as partial strings. For example, the argument 123 returns "12345", "41235", "45123", and so on. The arguments for gid and sid return only exact matches; for example, sid:3080 returns only SID 3080.

Each rule filter can also include one or more alphanumeric character strings. Character strings search the rule Message field, Signature ID, and Generator ID. For example, the string 123 returns the strings "Lotus123", "123mania", and so on in the rule message, and also returns SID 6123, SID 12375, and so on. For information on the rule Message field, see Defining the Event Message. For information on rule SIDs and GIDs, see Reading Preprocessor Generator IDs. You can search for a partial SID by filtering with one or more character strings.

All character strings are case-insensitive and are treated as partial strings. For example, any of the strings ADMIN, admin, or Admin return "admin", "CFADMIN", "Administrator" and so on.

You can enclose character strings in quotes to return exact matches. For example, the literal string "overflow attempt" in quotes returns only that exact string, whereas a filter comprised of the two strings overflow and attempt without quotes returns "overflow attempt", "overflow multipacket attempt", "overflow with evasion attempt", and so on.

You can narrow filter results by entering any combination of keywords, character strings, or both, separated by spaces. The result includes any rule that matches all the filter conditions.

You can enter multiple filter conditions in any order. For example, each of the following filters returns the same rules:

- url:at login attempt cve:200

- login attempt cve:200 url:at

- login cve:200 attempt url:at

Setting a Rule Filter in an Intrusion Policy

License: Protection

You can filter the rules on the Rules page to display a subset of rules. You can then use any of the page features, including selecting any of the features available in the context menu. This can be useful, for example, when you want to set a threshold for all the rules in a specific category. You can use the same features with rules in a filtered or unfiltered list. For example, you can apply new rule states to rules in a filtered or unfiltered list.

You can select predefined filter keywords from the filter panel on the left side of the Rules page in the intrusion policy. When you select a filter, the page displays all matching rules, or indicates when no rules match.

For more information on all the keywords and arguments you can use and how you can construct filters from the filter panel, see Understanding Rule Filtering in an Intrusion Policy.

You can add keywords to a filter to further constrain it. Any filter you enter searches the entire rules database and returns all matching rules. When you enter a filter while the page still displays the result of a previous filter, the page clears and returns the result of the new filter instead.

You can also type a filter using the same keyword and argument syntax supplied when you select a filter, or modify argument values in a filter after you select it. When you type in search terms without a keyword, without initial capitalization of the keyword, or without quotes around the argument, the search is treated as a string search and the category, message, and SID fields are searched for the specified terms.

To filter for specific rules in an intrusion policy:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Construct a filter by clicking on keywords or arguments in the filter panel on the left. Note that if you click an argument for a keyword already in the filter, it replaces the existing argument. See the following for more information:

- Guidelines for Constructing Intrusion Policy Rule Filters

- Understanding Rule Configuration Filters

- Understanding Rule Content Filters

- Understanding Rule Categories

- Editing a Rule Filter Directly

The page refreshes to display all matching rules, and the number of rules matching the filter is displayed above the filter text box.

Step 5 Select the rule or rules where you want to apply a new setting. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 Optionally, make any changes to the rule that you would normally make on the page. See the following sections for more information:

- See Setting Rule States for information on enabling and disabling rules on the Rules page.

- See Filtering Intrusion Event Notification Per Policy for information on adding thresholding and suppression to rules.

- See Adding Dynamic Rule States for information on setting dynamic rule states that trigger when rate anomalies occur in matching traffic.

- See Adding SNMP Alerts for information on adding SNMP alerts to specific rules.

- See Adding Rule Comments for information on adding rule comments to rules.

Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache.

See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Setting Rule States

License: Protection

The Cisco Vulnerability Research Team (VRT) sets the default state of each intrusion and preprocessor rule in each default policy. For example, a rule may be enabled in the Security over Connectivity default policy and disabled in the Connectivity over Security default policy. Intrusion policy rules you create inherit the default states of the rules in the default policy you use to create your policy.

You can set a rule to Generate Events, to Drop and Generate Events, or to Disable individually, or you can filter the rules by a variety of factors to select the rules for which you want to modify the state. In an inline deployment, you can use the Drop and Generate Events rule state in inline intrusion deployments to drop malicious packets. Note that rules with the Drop and Generate Events rule state generate events but do not drop packets in a passive deployment, including when a 3D9900 or Series 3 device inline interface set is in tap mode. Setting a rule to Generate Events or to Drop and Generate Events enables the rule; setting the rule to Disable disables it.

Consider two scenarios. In the first scenario, the rule state for a specific rule is set to Generate Events. When a malicious packet crosses your network and triggers the rule, the packet is sent to its destination and the system generates an intrusion event. In the second scenario, assume that the rule state for the same rule is set to Drop and Generate Events in an inline deployment. In this case, when the malicious packet crosses the network, the system drops the malicious packet and generates an intrusion event. The packet never reaches its target.

In an intrusion policy, you can set a rule’s state to one of the following:

- Set the rule state to Generate Events if you want the system to detect a specific intrusion attempt and generate an intrusion event when it finds matching traffic.

- Set the rule state to Drop and Generate Events if you want the system to detect a specific intrusion attempt, then drop the packet containing the attack and generate an intrusion event when it finds matching traffic in an inline deployment, or to generate an intrusion event when it finds matching traffic in a passive deployment, including when a 3D9900 or Series 3 device inline interface set is in tap mode.

Note that for the system to drop packets, your intrusion policy must be set to drop rules in an inline deployment; see Setting Drop Behavior in an Inline Deployment for more information.

- Set the rule state to Disable if you do not want the system to evaluate matching traffic.

To use drop rules, you must:

- Enable the Drop when Inline option in your intrusion policy.

- Set the rule state to Drop and Generate Events for any rules that should drop all packets that match the rule.

- Apply an access control policy that includes an access control rule that is associated with your intrusion policy to a managed device that uses an inline set.

Filtering rules on the Rules page can help you find the rules you want to set as drop rules. For more information, see Filtering Rules in an Intrusion Policy.

See Understanding and Writing Intrusion Rules for information about rule anatomy, rule keywords and their options, and rule writing syntax.

The VRT sometimes uses a rule update to change the default state of one or more rules in a default policy. If you allow rule updates to update your base policy, you also allow the rule update to change the default state of a rule in your policy when the default state changes in the default policy you used to create your policy (or in the default policy it is based on). Note, however, that if you have changed the rule state, the rule update does not override your change.

To change the rule state for one or more rules:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Note that this page indicates the total number of enabled rules, the total number of enabled rules set to Generate Events, and the total number set to Drop and Generate Events. Note also that in a passive deployment, rules set to Drop and Generate Events only generate events.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Locate the rule or rules where you want to set the rule state. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules where you want to set the rule state. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 You have the following options:

- To generate events when traffic matches the selected rules, select Rule State > Generate Events .

- To generate events and drop the traffic in inline deployments when traffic matches the selected rules, select Rule State > Drop and Generate Events .

- To not inspect traffic matching the selected rules, select Rule State > Disable .

Note Cisco strongly recommends that you do not enable all the intrusion rules in an intrusion policy. The performance of your managed device is likely to degrade if all rules are enabled. Instead, tune your rule set to match your network environment as closely as possible.

Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Filtering Intrusion Event Notification Per Policy

License: Protection

The importance of an intrusion event can be based on frequency of occurrence, or on source or destination IP address. In some cases you may not care about an event until it has occurred a certain number of times. For example, you may not be concerned if someone attempts to log into a server until they fail a certain number of times. In other cases, you may only need to see a few occurrences to know there is a widespread problem. For example, if a DoS attack is launched against your web server, you may only need to see a few occurrences of an intrusion event to know that you need to address the situation. Seeing hundreds of the same event only overwhelms your system.

See the following sections for more information:

- Configuring Event Thresholding explains how to set thresholds that dictate how often an event is displayed, based on the number of occurrences. You can configure thresholding per event and per policy.

- Configuring Suppression Per Intrusion Policy explains how to suppress notification of specified events per source or destination IP address, per policy.

Configuring Event Thresholding

License: Protection

You can set thresholds for individual rules, per intrusion policy, to limit the number of times the system logs and displays an intrusion event based on how many times the event is generated within a specified time period. This can prevent you from being overwhelmed with a large number of identical events. You can set thresholds per shared object rule, standard text rule, or preprocessor rule.

For more information, see the following sections:

- Understanding Event Thresholding

- Adding and Modifying Intrusion Event Thresholds

- Viewing and Deleting Intrusion Event Thresholds

- Setting a Threshold for a Rule

Understanding Event Thresholding

License: Protection

First, you must specify the thresholding type. You can select from the options discussed in the following table.

Table 32-6 Thresholding Options

Option

Description

Limit

Logs and displays events for the specified number of packets (specified by the Count argument) that trigger the rule during the specified time period. For example, if you set the type to Limit, the Count to 10, and the Seconds to 60, and 14 packets trigger the rule, the system stops logging events for the rule after displaying the first 10 that occur within the same minute.

Threshold

Logs and displays a single event when the specified number of packets (specified by the Count argument) trigger the rule during the specified time period. Note that the counter for the time restarts after you hit the threshold count of events and the system logs that event. For example, you set the type to Threshold, Count to 10, and Seconds to 60, and the rule triggers 10 times by second 33. The system generates one event, then resets the Seconds and Count counters to 0. The rule then triggers another 10 times in the next 25 seconds. Because the counters reset to 0 at second 33, the system logs another event.

Both

Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the rule. For example, if you set the type to Both, Count to two, and Seconds to 10, the following event counts result:

- If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is not met)

- If the rule is triggered twice in 10 seconds, the system generates one event (the threshold is met when the rule triggers the second time)

- If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met when the rule triggers the second time, and following events are ignored)

Next, you must specify tracking, which determines whether the event threshold is calculated per source or destination IP address. Select one of the options from the following table to specify how the system tracks event instances.

Table 32-7 Thresholding IP Options

Option

Description

Source

Calculates event instance count per source IP address.

Destination

Calculates event instance count per destination IP address.

Finally, you must specify the number of instances and time period that define the threshold.

Table 32-8 Thresholding Instance/Time Options

Option

Description

Count

The number of event instances per specified time period per tracking IP address required to meet the threshold.

Seconds

The number of seconds that elapse before the count resets. If you set the threshold type to limit, the tracking to Source IP, the count to 10, and the seconds to 10, the system logs and displays the first 10 events that occur in 10 seconds from a given source port. If only 7 events occur in the first 10 seconds, the system logs and displays those; if 40 events occur in the first 10 seconds, the system logs and displays 10, then begins counting again when the 10-second time period elapses.

Note that you can use intrusion event thresholding alone or in any combination with rate-based attack prevention, the detection_filter keyword, and intrusion event suppression. See Adding Dynamic Rule States, Filtering Events, and Configuring Suppression Per Intrusion Policy for more information.

See the following sections for more information:

- Adding and Modifying Intrusion Event Thresholds

- Setting a Threshold for a Rule

- Viewing and Deleting Intrusion Event Thresholds

Tip You can also add thresholds from within the packet view of an intrusion event. See Viewing Event Information for more information.

Adding and Modifying Intrusion Event Thresholds

License: Protection

You can set a threshold for one or more specific rules. You can also separately or simultaneously modify existing threshold settings. You can set a a single threshold for each. Adding a threshold overwrites any existing threshold for the rule.

For more information on viewing and deleting threshold configurations, see Viewing and Deleting Intrusion Event Thresholds.

You can also modify the global threshold that applies by default to all rules and preprocessor-generated events. For more information, see Globally Limiting Intrusion Event Logging.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Tip A global or individual threshold on a managed device with multiple CPUs may result in a higher number of events than expected.

To add or modify event thresholds:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Locate the rule or rules where you want to set a threshold. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules where you want to set a threshold. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 Select Event Filtering > Threshold.

The thresholding pop-up window appears.

Step 7 From the Type drop-down list, select the type of threshold you want to set:

- Select Limit to limit notification to the specified number of event instances per time period.

- Select Threshold to provide notification for each specified number of event instances per time period.

- Select Both to provide notification once per time period after a specified number of event instances.

Step 8 From the Track By drop-down list, select whether you want the event instances tracked by Source or Destination IP address.

Step 9 In the Count field, specify the number of event instances you want to use as your threshold.

Step 10 In the Seconds field, specify the number of seconds that make up the time period for which event instances are tracked.

Step 11 Click OK.

) next to the rule in the Event Filtering column. If you add multiple event filters to a rule, a number over the icon indicates the number of event filters.

Step 12 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache.

See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Viewing and Deleting Intrusion Event Thresholds

License: Protection

You may want to view or delete an existing threshold setting. You can use the Rules Details view to display the configured settings for a threshold to see if they are appropriate for your system. If they are not, you can add a new threshold to overwrite the existing values.

Note that you can also modify the global threshold that applies by default to all rules and preprocessor-generated events. See Globally Limiting Intrusion Event Logging for more information.

To view or delete a threshold:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Locate the rule or rules that have a configured threshold you want to view or delete. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules with a configured threshold you want to view or delete. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 To remove the threshold for each selected rule, select Event Filtering > Remove Thresholds. Click OK in the confirmation pop-up window that appears.

Tip To remove a specific threshold, you can also highlight the rule and click Show details. Expand the threshold settings, then click Delete next to the threshold settings you want to remove. Click OK to confirm that you want to delete the configuration.

The page refreshes and the threshold is deleted.

Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Configuring Suppression Per Intrusion Policy

License: Protection

You can suppress intrusion event notification when a specific IP address or range of IP addresses triggers a specific rule or preprocessor. This is useful for eliminating false positives. For example, if you have a mail server that transmits packets that look like a specific exploit, you might suppress event notification for that event when it is triggered by your mail server. The rule triggers for all packets, but you only see events for legitimate attacks.

Note that you can use intrusion event suppression alone or in any combination with rate-based attack prevention, the detection_filter keyword, and intrusion event thresholding. See Adding Dynamic Rule States, Filtering Events, and Configuring Event Thresholding for more information.

See the following sections for more information:

- Suppressing Intrusion Events

- Viewing and Deleting Suppression Conditions

Tip You can also add suppressions from within the packet view of an intrusion event. See Viewing Event Information for more information. You can also access suppression settings by using the right-click context menu on the Rule Editor page and on any intrusion event page (if the event was triggered by an intrusion rule).

Suppressing Intrusion Events

License: Protection

You can suppress intrusion event notification for a rule or rules. When notification is suppressed for a rule, the rule triggers but events are not generated. You can set one or more suppressions for a rule. The first suppression listed has the highest priority. Note that when two suppressions conflict, the action of the first is carried out.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

To suppress event display:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists the rules alphabetically by message.

Step 4 Locate the rule or rules where you want to set suppression. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules for which you want to configure suppression conditions. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all rules in the current list, select the check box at the top of the column.

Step 6 Select Event Filtering > Suppression.

The suppression pop-up window appears.

Step 7 Select one of the following Suppression Type options:

- Select Rule to completely suppress events for a selected rule.

- Select Source to suppress events generated by packets originating from a specified source IP address.

- Select Destination to suppress events generated by packets going to a specified destination IP address.

Step 8 If you selected Source or Destination for the suppression type, in the Network field enter the IP address, address block, or variable you want to specify as the source or destination IP address, or a comma-separated list comprised of any combination of these.

For information on using IPv4 CIDR and IPv6 prefix length address blocks in the FireSIGHT System, see IP Address Conventions.

Step 9 Click OK.

) next to the rule in the Event Filtering column next the suppressed rule. If you add multiple event filters to a rule, a number over the icon indicates the number of event filters.

Step 10 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache.

See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Viewing and Deleting Suppression Conditions

License: Protection

You may want to view or delete an existing suppression condition. For example, you can suppress event notification for packets originating from a mail server IP address because the mail server normally transmits packets that look like exploits. If you then decommission that mail server and reassign the IP address to another host, you should delete the suppression conditions for that source IP address.

To view or delete a defined suppression condition:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears. By default, the page lists rules alphabetically by message.

Step 4 Locate the rule or rules where you want to view or delete suppressions. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules for which you want to view or delete suppressions. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all rules in the current list, select the check box at the top of the column.

Step 6 You have two options:

- To remove all suppression for a rule, select Event Filtering > Remove Suppressions. Click OK in the confirmation pop-up window that appears.

- To remove a specific suppression setting, highlight the rule and click Show details . Expand the suppression settings and click Delete next to the suppression settings you want to remove. Click OK to confirm that you want to delete your selected settings.

The page refreshes and the suppression settings are deleted.

Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Adding Dynamic Rule States

License: Protection

Rate-based attacks attempt to overwhelm a network or host by sending excessive traffic toward the network or host, causing it to slow down or deny legitimate requests. You can use rate-based prevention to change the action of a rule in response to excessive rule matches for specific rules.

For more information, see the following sections:

- Understanding Dynamic Rule States

- Setting a Dynamic Rule State

Understanding Dynamic Rule States

License: Protection

You can configure your intrusion policies to include a rate-based filter that detects when too many matches for a rule occur in a given time period. You can use this feature on managed devices deployed inline to block rate-based attacks for a specified time, then revert to a rule state where rule matches only generate events and do not drop traffic.

Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize the impact of that traffic on legitimate requests. You can identify excessive rule matches in traffic going to a particular destination IP address or addresses or coming from a particular source IP address or addresses. You can also respond to excessive matches for a particular rule across all detected traffic.

In the intrusion policy, you can configure a rate-based filter for any intrusion or preprocessor rule. The rate-based filter contains three components:

- the rule matching rate, which you configure as a count of rule matches within a specific number of seconds

- a new action to be taken when the rate is exceeded, with three available actions: Generate Events, Drop and Generate Events, and Disable

- the duration of the action, which you configure as a timeout value

Note that when started, the new action occurs until the timeout is reached, even if the rate falls below the configured rate during that time period. When the timeout is reached, if the rate has fallen below the threshold, the action for the rule reverts to the action initially configured for the rule.

You can configure rate-based attack prevention in an inline deployment to block attacks, either temporarily or permanently. Without rate-based configuration, rules set to Generate Events do generate events, but the system does not drop packets for those rules. However, if the attack traffic matches rules that have rate-based criteria configured, the rate action may cause packet dropping to occur for the period of time that the rate action is active, even if those rules are not initially set to Drop and Generate Events.

Note Rate-based actions cannot enable disabled rules or drop traffic that matches disabled rules.

You can define multiple rate-based filters on the same rule. The first filter listed in the intrusion policy has the highest priority. Note that when two rate-based filter actions conflict, the action of the first rate-based filter is carried out.

The following diagram shows an example where an attacker is attempting to access a host. Repeated attempts to find a password trigger a rule which has rate-based attack prevention configured. The rate-based settings change the rule attribute to Drop and Generate Events after rule matches occur five times in a 10-second span. The new rule attribute times out after 15 seconds.

Setting a Dynamic Rule State

License: Protection

In some cases, you may not want to set a rule to the Drop and Generate Events state because you do not want to drop every packet that matches the rule, but you do want to drop packets matching the rule if a particular rate of matches occurs in a specified time. Dynamic rule states let you configure the rate that should trigger a change in the action for a rule, what the action should change to when the rate is met, and how long the new action should persist.

You set the number of hits for that rule by specifying a count and the number of seconds within which that number of hits should occur to trigger the action change. In addition, you can set a timeout to cause the action to revert to the previous state for the rule when the timeout expires.

You can define multiple dynamic rule state filters for the same rule. The first filter listed in the rule details in the intrusion policy has the highest priority. Note that when two rate-based filter actions conflict, the action of the first rate-based filter is carried out.

) appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Note Dynamic rule states cannot enable disabled rules or drop traffic that matches disabled rules.

To add a dynamic rule state:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears.

Step 4 Locate the rule or rules where you want to add a dynamic rule state. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules where you want to add a dynamic rule state. You have the following options:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 Select Dynamic State > Add Rate-Based Rule State.

The Add Rate-Based Rule State dialog box appears.

Step 7 From the Track By drop-down list, select how you want the rule matches tracked:

- Select Source to track the number of hits for that rule from a specific source or set of sources.

- Select Destination to track the number of hits for that rule to a specific destination or set of destinations.

- Select Rule to track all matches for that rule.

Step 8 If you set Track By to Source or Destination, enter the address of each host you want to track in the Network field.

You can specify a single IP address, address block, variable, or a comma-separated list comprised of any combination of these. For information on using IPv4 CIDR and IPv6 prefix length address blocks in the FireSIGHT System, see IP Address Conventions.

Step 9 Next to Rate, indicate the number of rule matches per time period to set the attack rate:

- In the Count field, using an integer between 1 and 2147483647, specify the number of rule matches you want to use as your threshold.

- In the Seconds field, using an integer between 1 and 2147483647, specify the number of seconds that make up the time period for which attacks are tracked.

Step 10 From the New State drop-down list, specify the new action to be taken when the conditions are met:

- Select Generate Events to generate an event.

- Select Drop and Generate Events to generate an event and drop the packet that triggered the event in inline deployments or generate an event in passive deployments.

- Select Disabled to take no action.

Step 11 In the Timeout field, type the number of seconds you want the new action to remain in effect. After the timeout occurs, the rule reverts to its original state. Specify 0 or leave the Timeout field blank to prevent the new action from timing out.

Step 12 Click OK.

) next to the rule in the Dynamic State column. If you add multiple dynamic rule state filters to a rule, a number over the icon indicates the number of filters.

If any required fields are blank, you receive an error message indicating which fields you must fill.

Tip To delete all dynamic rule settings for a set of rules, select the rules on the Rules page, then select Dynamic State > Remove Rate-Based States. You can also delete individual rate-based rule state filters from the rule details for the rule by selecting the rule, clicking Show details, then clicking Delete by the rate-based filter you want to remove.

Step 13 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache.

See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Adding SNMP Alerts

License: Protection

If you configure SNMP alerting for your FireSIGHT System, you can configure specific rules to provide an SNMP alert when the rule generates an event. For more information, see Using SNMP Responses.

To set an SNMP alert:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears.

Step 4 Locate the rule or rules where you want to set SNMP alerts. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules where you want to set SNMP alerts:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 Select Alerting > Add SNMP Alert.

) next to the rule in the Alerting column. If you add multiple alert types to a rule, a number over the icon indicates the number of alert types.

Tip To remove an SNMP alert from a rule, click the check box next to the rule and select Alerting > Remove SNMP Alerts, then click OK to confirm the deletion.

Step 7 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Adding Rule Comments

License: Protection

You can add comments to a rule. Any comments you add can be seen in the Rule Details view on the Rules page.

After you commit the intrusion policy changes containing the comment, you can also view the comment by clicking Rule Comment on the rule Edit page. For more information on editing rules, see Modifying Existing Rules.

To add a comment to a rule:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Rules.

The Rules page appears.

Step 4 Locate the rule or rules where you want to add a comment to a rule. You have the following options:

- To sort the current display, click on a column heading or icon. To reverse the sort, click again.

- Construct a filter by clicking on keywords or arguments in the filter panel on the left. For more information, see the following topics: Understanding Rule Filtering in an Intrusion Policy and Setting a Rule Filter in an Intrusion Policy.

The page refreshes to display all matching rules.

Step 5 Select the rule or rules where you want to add a comment:

- To select a specific rule, select the check box next to the rule.

- To select all the rules in the current list, select the check box at the top of the column.

Step 6 Select Comments > Add Rule Comment.

The Add Comment dialog box appears.

Step 7 In the Comment field, type the rule comment.

Step 8 Click OK.

) next to the rule in the Comments column. If you add multiple comments to a rule, a number over the icon indicates the number of comments.

Tip To delete a rule comment, highlight the rule and click Show Details, then click Delete in the Comments section. Note that you can only delete a comment if the comment is cached with uncommitted intrusion policy changes. After intrusion policy changes are committed, the rule comment is permanent.

Step 9 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache.

See Managing Intrusion Policies and Editing Intrusion Policies for more information.

Tailoring Intrusion Protection to Your Network Assets

You can use the FireSIGHT Recommended Rules feature to associate the operating systems, servers, and client application protocols detected on your network (see Introduction to Network Discovery) with rules specifically written to protect those assets, per intrusion policy. This allows you to tailor your intrusion policy to the specific needs of your monitored network. The FireSIGHT Recommended Rules feature requires FireSIGHT and Protection licenses.

When you configure the FireSIGHT Recommended Rules feature, the system searches your base policy for rules that protect against vulnerabilities associated with your network assets, and identifies the current state of rules in your base policy. The system then recommends rule states and, optionally, sets the rules to the recommended states using the criteria in the following table.

Table 33-1 FireSIGHT Rule State Recommendations Based on Vulnerabilities

Base Policy Rule State

Rule Protects Your Discovered Assets?

Recommend Rule State

Generate Events or

Disable

yes

Generate Events

Drop and Generate Events

yes

Drop and Generate Events

any

no

Disable

The Cisco Vulnerability Research Team (VRT) determines the appropriate state of each rule in the default policies provided by Cisco. Thus, when your base policy is a default policy provided by Cisco, the net effect of allowing the system to set your rules to the FireSIGHT recommended rule states is that the rules in your intrusion policy match the settings recommended by Cisco for your network assets. See Understanding the System-Provided Policies for more information.

Generating rule state recommendations can be as simple as choosing whether to use the recommended rule states, either when you generate recommendations or at a later time. Advanced recommendations options allow you to tailor your configuration further. Note that choosing to use recommended rule states adds a read-only FireSIGHT Recommendations layer to your intrusion policy, and subsequently choosing not to use recommended rule states removes the layer. See Using Layers in a Network Analysis or Intrusion Policy for information on using policy layers to more efficiently manage multiple intrusion policies.

Note that while the system typically recommends rule state changes for standard text rules and shared object rules, it can also recommend changes for preprocessor and decoder rules.

You can schedule a task to generate recommendations automatically based on the most recently saved configuration settings in your intrusion policy. For information on scheduling a task to generate recommended rule states, see Automating FireSIGHT Recommendations.

See the following sections for more information:

- Understanding Basic Rule State Recommendations

- Understanding Advanced Rule State Recommendations

- Using FireSIGHT Recommendations

Understanding Basic Rule State Recommendations

License: Protection + FireSIGHT

You can generate recommendations without using the recommended rule states in your policy. You can then display any of three filtered views of the Rules page to show rules that the system recommends you set to Generate Events, Drop and Generate Events, or Disable. This allows you to see beforehand which rules would be modified when you choose to use the recommended rule states. You can also choose to generate recommendations and immediately use them.

While displaying the recommendation-filtered Rules page, or after accessing the Rules page directly from the navigation panel or the Policy Information page, you can manually set rule states, sort rules, and take any of the other actions available on the Rules page, such as suppressing rules, setting rule thresholds, and so on. See Setting Rule States for information on manually changing the state of selected rules. See Tuning Intrusion Policies Using Rules for information on other actions available on the Rules page for tailoring the rules in your intrusion policy.

The system does not change rule states that you set manually. When you choose to use the recommended rule states while generating recommendations:

- manually setting the states of specified rules before you generate recommendations prevents the system from modifying the states of those rules in the future

- manually setting the states of specified rules after you generate recommendations overrides the recommended states of those rules

Tip You can include a list in the intrusion policy report of rules whose rule states differ from the recommended state. See Generating a Report of Current Intrusion Settings for more information.

Note also that when you generate recommendations without changing the advanced settings for FireSIGHT recommended rules, the system recommends rule state changes for all hosts in your entire discovered network. Note also that, by default, the system generates recommendations only for rules with low or medium overhead, and generates recommendations to disable rules. See Understanding Advanced Rule State Recommendations for more information.

Understanding Advanced Rule State Recommendations

License: Protection or Protection + FireSIGHT

Advanced settings allow you to redefine which hosts on your network the system monitors for vulnerabilities, to influence which rules the system recommends based on rule overhead, and to specify whether to generate recommendations to disable rules.

If you want to dynamically adapt active rule processing for specific packets based on host information, you can also enable adaptive profiles. For more information, see Adaptive Profiles and FireSIGHT Recommended Rules.

See the following sections for more information:

- Understanding the Networks to Examine

- Understanding Rule Overhead

Understanding the Networks to Examine

License: Protection + FireSIGHT

You configure the FireSIGHT Recommended Rules feature by identifying networks to examine in the network map. The system then recommends the rules you can activate to protect your network. For information on the network map, see Using the Network Map.

You configure the Networks field with the hosts to examine for recommendations. You can specify a single IP address or address block, or a comma-separated list comprised of either or both.

Lists of addresses within the hosts that you specify are linked with an OR operation except for negations, which are linked with an AND operation after all OR operations are calculated.

Understanding Rule Overhead

License: Protection

Cisco rates the overhead of each intrusion rule as none, low, medium, or high, based on the rule’s potential impact on system performance and the likelihood that the rule may generate false positives. You can view the overhead rating for a rule in the rule detail view on the Rules page. See Viewing Rule Details for more information.

You can set the system to make rule state recommendations based on all rules up to and including a specified overhead rating. For example, when you generate recommendations for rules with medium overhead, the system makes recommendations based on all rules with an overhead rating of none, low, or medium, and does not make any recommendations for rules with high overhead.

Note that the system factors rule overhead into recommendations to generate events or to drop and generate events. The system does not factor rule overhead into recommendations to disable rules. Note also that local rules have no overhead, unless they are mapped to a third-party vulnerability. See Importing Local Rule Files and Managing Third-Party Product Mappings for more information.

Generating recommendations for rules with the overhead rating at a particular setting does not preclude you from generating recommendations with different overhead, then generating recommendations again for the original overhead setting. You get the same rule state recommendations for each overhead setting each time you generate recommendations for the same rule set, regardless of the number of times you generate recommendations or how many different overhead settings you generate with. For example, you can generate recommendations with overhead set to medium, then to high, then finally to medium again; if the hosts and applications on your network have not changed, both sets of recommendations with overhead set to medium are then the same for that rule set.

Using FireSIGHT Recommendations

License: FireSIGHT + Protection

You can generate recommendations with or without using the recommended rule states, and with or without modifying the advanced settings for generating recommendations. See Understanding Basic Rule State Recommendations and Understanding Advanced Rule State Recommendations for more information.

After generating recommendations, you can use the recommended rule states; you can also view recommended states and use any features available on the Rules page.

To use FireSIGHT rule state recommendations:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 You have two options:

- If you have not generated recommendations, select No recommendations have been generated. Click here to set up FireSIGHT recommendations .

- If you have generated recommendations, select Click to change recommendations .

The FireSIGHT Recommended Rules Configuration page appears.

Step 4 You have the following choices:

- To have the corresponding intrusion policy report list the rule message, recommended state, and actual state for all rules whose actual states differ from the recommended state, select Include all differences between recommendations and rule states in policy reports . See Generating a Report of Current Intrusion Settings for more information.

- To generate recommendations using the default settings, go to step 9 .

- To modify the advanced recommendations options, go to step 5 .

section.

The advanced FireSIGHT recommendations options appear.

Step 6 In the Networks field under Networks to Examine, specify the network to examine for recommendations.

For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Note that lists of addresses are linked with an OR operation except for negations, which are linked with an AND operation after all OR operations are calculated. See Understanding the Networks to Examine for more information.

Step 7 Optionally, under FireSIGHT Recommended Rules Configuration, drag the Recommendation Threshold (By Rule Overhead) slide bar to specify the amount of overhead a rule must have to be included in the recommendations you generate.

Dragging the slide bar to the right includes rules with higher overhead and will likely result in more recommendations, but may increasingly affect system performance. See Understanding Rule Overhead for more information.

Step 8 You have the following options:

- To generate recommendations to disable rules, select the Accept Recommendations to Disable Rules check box.

Note that accepting recommendations to disable rules restricts your rule coverage.

- To prevent generating recommendations to disable rules, clear the Accept Recommendations to Disable Rules check box.

Note that omitting recommendations to disable rules augments your rule coverage.

Step 9 You have several options:

- Click Generate and Use Recommendations if you have not yet generated recommendations and want the system to change your rule states automatically to the recommended states while generating recommendations.

The system generates recommended rule state changes and automatically sets rules to the recommended states.

- Click Generate Recommendations if you want the system to generate recommendations without automatically changing your rule states to the recommended states.

The system generates recommended rule state changes.

- If you have generated recommendations before, click Update Recommendations to update existing recommendations.

The system generates recommended rule state changes and, if recommendations are in use, automatically sets rules to the recommended states. The status updates for the number of recommendations, the number of hosts with recommended rule state changes, and the number of recommendations to generate events, drop and generate events, or disable rules.

- If you have generated recommendations before, click Use Recommendations to use recommendations that you have generated but have not used.

The system automatically sets rules to the recommended states.

- If you have generated and are already using recommendations, click Do Not Use Recommendations to stop using recommendations currently in use.

The system automatically resets rules to the default rule states unless a specific rule state was applied to the rule before using recommendations; in that case, the rule reverts to the specific rule state.

Note that the system does not recommend a rule state for an intrusion rule that is based on a vulnerability that you disable using the Impact Qualification feature. For more information, see Setting the Vulnerability Impact Qualification.

Note also that updating the policy to use or not use recommendations may take several minutes, depending on the size of your network and rule set.

Note The system always recommends that you enable a local rule associated with a third-party vulnerability mapped to a host. The system does not make state recommendations for unmapped local rules. For more information, see Managing Third-Party Product Mappings.

Step 10 Optionally, click View next to a recommendation type to display a recommendations-filtered view of the Rules page for the type of recommendation you selected.

Step 11 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Detecting Specific Threats

You can use several preprocessors in a network analysis policy to detect specific threats to your monitored network, such as Back Orifice attacks, several portscan types, and rate-based attacks that attempt to overwhelm your network with excessive traffic. Note that when an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses it with its current configuration even though it remains disabled in the network analysis policy’s web interface. For more information, see Limitations of Custom Policies.

Caution Some users with custom user roles cannot access the network analysis policy via the standard menu path ( Policies > Access Control > Network Analysis Policy). These users can access the network analysis policy through the intrusion policy: Policies > Intrusion > Intrusion Policy > Network Analysis Policy. For more information on custom user roles, see Managing Custom User Roles.

You can also use sensitive data detection, which you configure in an intrusion policy, to detect unsecured transmission of sensitive numerical data.

See the following sections for more information on detecting specific threats:

- Detecting Back Orifice explains detection of Back Orifice attacks.

- Detecting Portscans describes the different types of portscans and explains how you can use portscan detection to identify threats to your networks before they develop into attacks.

- Preventing Rate-Based Attacks explains how to limit denial of service (DoS) and SYN flood attacks.

- Detecting Sensitive Data explains how to detect and generate events on sensitive data such as credit card numbers and Social Security numbers in ASCII text.

Detecting Back Orifice

License: Protection

The FireSIGHT System provides a preprocessor that detects the existence of the Back Orifice program. This program can be used to gain admin access to your Windows hosts. The Back Orifice preprocessor analyzes UDP traffic for the Back Orifice magic cookie, "*!*QWTY?", which is located in the first eight bytes of the packet and is XOR-encrypted.

The Back Orifice preprocessor has a configuration page, but no configuration options. When it is enabled, you must also enable the preprocessor rules in the following table for the preprocessor to generate corresponding events. See Setting Rule States for more information.

Table 34-1 Back Orifice GID:SIDs

Preprocessor rule GID:SID

Description

105:1

Back Orifice traffic detected

105:2

Back Orifice client traffic detected

105:3

Back Orifice server traffic detected

105:4

Back Orifice snort buffer attack detected

To view the Back Orifice Detection page:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Access Control > Access Control Policy to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 In the navigation panel on the left, click Settings.

The Settings page appears.

Step 4 You have two choices, depending on whether Back Orifice Detection under Specific Threat Detection is enabled:

- If the preprocessor is enabled, click Edit .

- If the preprocessor is disabled, click Enabled , then click Edit .

The Back Orifice Detection page appears. A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Detecting Portscans

License: Protection

A portscan is a form of network reconnaissance that is often used by attackers as a prelude to an attack. In a portscan, an attacker sends specially crafted packets to a targeted host. By examining the packets that the host responds with, the attacker can often determine which ports are open on the host and, either directly or by inference, which application protocols are running on these ports.

Note that when portscan detection is enabled, you must enable rules on the intrusion policy Rules page with generator ID (GID) 122 for enabled portscan types for the portscan detector to generate portscan events. See Setting Rule States and Table 34-5 for more information.

By itself, a portscan is not evidence of an attack. In fact, some of the portscanning techniques used by attackers can also be employed by legitimate users on your network. Cisco’s portscan detector is designed to help you determine which portscans might be malicious by detecting patterns of activity.

Table 34-2 Protocol Types

Protocol

Description

TCP

Detects TCP probes such as SYN scans, ACK scans, TCP connect() scans, and scans with unusual flag combinations such as Xmas tree, FIN, and NULL

UDP

Detects UDP probes such as zero-byte UDP packets

ICMP

Detects ICMP echo requests (pings)

IP

Detects IP protocol scans. These scans differ from TCP and UDP scans because the attacker, instead of looking for open ports, is trying to discover which IP protocols are supported on a target host.

Note For events generated by the portscan connection detector, the protocol number is set to 255. Because portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved number, so that number is used in portscan events to indicate that there is not an associated protocol for the event.

Table 34-3 Portscan Types

Type

Description

Portscan Detection

A one-to-one portscan in which an attacker uses one or a few hosts to scan multiple ports on a single target host.

One-to-one portscans are characterized by:

- a low number of scanning hosts

- a single host that is scanned

- a high number of ports scanned

This option detects TCP, UDP, and IP portscans.

Port Sweep

A one-to-many portsweep in which an attacker uses one or a few hosts to scan a single port on multiple target hosts.

Portsweeps are characterized by:

- a low number of scanning hosts

- a high number of scanned hosts

- a low number of unique ports scanned

This option detects TCP, UDP, ICMP, and IP portsweeps.

Decoy Portscan

A one-to-one portscan in which the attacker mixes spoofed source IP addresses with the actual scanning IP address.

Decoy portscans are characterized by:

- a high number of scanning hosts

- a low number of ports that are scanned only once

- a single (or a low number of) scanned hosts

The decoy portscan option detects TCP, UDP, and IP protocol portscans.

Distributed Portscan

A many-to-one portscan in which multiple hosts query a single host for open ports.

Distributed portscans are characterized by:

- a high number of scanning hosts

- a high number of ports that are scanned only once

- a single (or a low number of) scanned hosts

The distributed portscan option detects TCP, UDP, and IP protocol portscans.

The information that the portscan detector learns about a probe is largely based on seeing negative responses from the probed hosts. For example, when a web client tries to connect to a web server, the client uses port 80/tcp and the server can be counted on to have that port open. However, when an attacker probes a server, the attacker does not know in advance if it offers web services. When the portscan detector sees a negative response (that is, an ICMP unreachable or TCP RST packet), it records the response as a potential portscan. The process is more difficult when the targeted host is on the other side of a device such as a firewall or router that filters negative responses. In this case, the portscan detector can generate filtered portscan events based on the sensitivity level that you select.

Table 34-4 Sensitivity Levels

Level

Description

Low

Detects only negative responses from targeted hosts. Select this sensitivity level to suppress false positives, but keep in mind that some types of portscans (slow scans, filtered scans) might be missed.

This level uses the shortest time window for portscan detection.

Medium

Detects portscans based on the number of connections to a host, which means that you can detect filtered portscans. However, very active hosts such as network address translators and proxies may generate false positives.

Note that you can add the IP addresses of these active hosts to the Ignore Scanned field to mitigate this type of false positive.

This level uses a longer time window for portscan detection.

High

Detects portscans based on a time window, which means that you can detect time-based portscans. However, if you use this option, you should be careful to tune the detector over time by specifying IP addresses in the Ignore Scanned and Ignore Scanner fields.

This level uses a much longer time window for portscan detection.

See the following sections for more information:

- Configuring Portscan Detection

- Understanding Portscan Events

Configuring Portscan Detection

License: Protection

The portscan detection configuration options allow you to finely tune how the portscan detector reports scan activity.

Note that when portscan detection is enabled, you must enable rules on the Rules page with generator ID (GID) 122 for enabled portscan types for the portscan detector to generate portscan events. See Setting Rule States and the Portscan Detection SIDs (GID:122) table for more information.

To configure portscan detection:

Admin/Intrusion Admin

Step 1 Select Policies > Access Control > Access Control Policy to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See [was Committing Intrusion Policy Changes; update xref] for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 In the navigation panel on the left, click Settings.

The Settings page appears.

Step 4 You have two choices, depending on whether Portscan Detection under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Portscan Detection page appears. A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 In the Protocol field, specify which of the following protocols you want to enable:

- TCP

- UDP

- ICMP

- IP

Use Ctrl or Shift while clicking to select multiple protocols or clear individual protocols. See the Protocol Types table for more information.

Note that you must ensure TCP stream processing is enabled to detect scans over TCP, and that UDP stream processing is enabled to detect scans over UDP.

Step 6 In the Scan Type field, specify which of the following portscans you want to detect:

- Portscan Detection

- Port Sweep

- Decoy Portscan

- Distributed Portscan

Use Ctrl or Shift while clicking to select or deselect multiple protocols. See the Portscan Types table for more information.

Step 7 In the Sensitivity Level list, select the level you want to use: low, medium, or high.

See the Sensitivity Levels table for more information.

Step 8 Optionally, in the Watch IP field, specify which host you want to watch for signs of portscan activity, or leave the field blank to watch all network traffic.

You can specify a single IP address or address block, or a comma-separated lists of either or both. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Step 9 Optionally, in the Ignore Scanners field, specify which hosts you want to ignore as scanners. Use this field to indicate hosts on your network that are especially active. You may need to modify this list of hosts over time.

You can specify a single IP address or address block, or a comma-separated lists of either or both. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Step 10 Optionally, in the Ignore Scanned field, specify which hosts you want to ignore as the target of a scan. Use this field to indicate hosts on your network that are especially active. You may need to modify this list of hosts over time.

You can specify a single IP address or address block, or a comma-separated lists of either or both. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Step 11 Optionally, clear the Detect Ack Scans check box to discontinue monitoring of sessions picked up in mid-stream.

Note Detection of mid-stream sessions helps to identify ACK scans, but may cause false events, particularly on networks with heavy traffic and dropped packets.

Step 12 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Portscan Events

License: Protection

When portscan detection is enabled, you must enable rules with generator ID (GID) 122 and a Snort® ID (SID) from among SIDs 1 through 27 to generate events for each enabled portscan type. See Setting Rule States for more information. The Preprocessor Rule SID column in the following table lists the SID for the preprocessor rule you must enable for each portscan type.

Table 34-5 Portscan Detection SIDs (GID:122)

Portscan Type

Protocol:

Sensitivity Level

Preprocessor Rule SID

Portscan Detection

TCP

UDP

ICMP

IP

Low

Medium or High

Low

Medium or High

Low

Medium or High

Low

Medium or High

1

5

17

21

Does not generate events.

Does not generate events.

9

13

Port Sweep

TCP

UDP

ICMP

IP

Low

Medium or High

Low

Medium or High

Low

Medium or High

Low

Medium or High

3, 27

7

19

23

25

26

11

15

Decoy Portscan

TCP

UDP

ICMP

IP

Low

Medium or High

Low

Medium or High

Low

Medium or High

Low

Medium or High

2

6

18

22

Does not generate events.

Does not generate events.

10

14

Distributed Portscan

TCP

UDP

ICMP

IP

Low

Medium or High

Low

Medium or High

Low

Medium or High

Low

Medium or High

4

8

20

24

Does not generate events.

Does not generate events.

12

16

When you enable the accompanying preprocessor rules, the portscan detector generates intrusion events that you can view just as you would any other intrusion event. However, the information presented on the packet view is different from the other types of intrusion events. This section describes the fields that appear on the packet view for a portscan event and how you can use that information to understand the types of probes that occur on your network.

Begin by using the intrusion event views to drill down to the packet view for a portscan event. You can follow the procedures in Working with Intrusion Events.

Note that you cannot download a portscan packet because single portscan events are based on multiple packets; however, the portscan packet view provides all usable packet information.

Note For events generated by the portscan connection detector, the protocol number is set to 255. Because portscan does not have a specific protocol associated with it by default, the Internet Assigned Numbers Authority (IANA) does not have a protocol number assigned to it. IANA designates 255 as a reserved number, so that number is used in portscan events to indicate that there is not an associated protocol for the event.

Table 34-6 Portscan Packet View

Information

Description

Device

The device that detected the event.

Time

The time when the event occurred.

Message

The event message generated by the preprocessor.

Source IP

The IP address of the scanning host.

Destination IP

The IP address of the scanned host.

Priority Count

The number of negative responses (for example, TCP RSTs and ICMP unreachables) from the scanned host. The higher the number of negative responses, the higher the priority count.

Connection Count

The number of active connections on the hosts. This value is more accurate for connection-based scans such as TCP and IP.

IP Count

The number of times that the IP addresses that contact the scanned host changes. For example, if the first IP address is 10.1.1.1, the second IP is 10.1.1.2, and the third IP is 10.1.1.1, then the IP count is 3.

This number is less accurate for active hosts such as proxies and DNS servers.

Scanner/Scanned IP Range

The range of IP addresses for the scanned hosts or the scanning hosts, depending on the type of scan. For portsweeps, this field shows the IP range of scanned hosts. For portscans, this shows the IP range of the scanning hosts.

Port/Proto Count

For TCP and UDP portscans, the number of times that the port being scanned changes. For example, if the first port scanned is 80, the second port scanned is 8080, and the third port scanned is again 80, then the port count is 3.

For IP protocol portscans, the number of times that the protocol being used to connect to the scanned host changes.

Port/Proto Range

For TCP and UDP portscans, the range of the ports that were scanned.

For IP protocol portscans, the range of IP protocol numbers that were used to attempt to connect to the scanned host.

Open Ports

The TCP ports that were open on the scanned host. This field appears only when the portscan detects one or more open ports.

Preventing Rate-Based Attacks

License: Protection

Rate-based attacks are attacks that depend on frequency of connection or repeated attempts to perpetrate the attack. You can use rate-based detection criteria to detect a rate-based attack as it occurs and respond to it when it happens, then return to normal detection settings after it stops. For more information on configuring rate-based detection, see the following topics:

- Understanding Rate-Based Attack Prevention

- Rate-Based Attack Prevention and Other Filters

- Configuring Rate-Based Attack Prevention

- Understanding Dynamic Rule States

- Setting a Dynamic Rule State

Understanding Rate-Based Attack Prevention

License: Protection

You can configure your network analysis policy to include rate-based filters that detect excessive activity directed at hosts on your network. You can use this feature on managed devices deployed in inline mode to block rate-based attacks for a specified time, then revert to only generating events and not drop traffic.

Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize the impact of that traffic on legitimate requests. Rate-based attacks usually have one of the following characteristics:

- any traffic containing excessive incomplete connections to hosts on the network, indicating a SYN flood attack

To configure SYN attack detection, see Preventing SYN Attacks.

- any traffic containing excessive complete connections to hosts on the network, indicating a TCP/IP connection flood attack

To configure simultaneous connection detection, see Controlling Simultaneous Connections.

- excessive rule matches in traffic going to a particular destination IP address or addresses or coming from a particular source IP address or addresses.

To configure source or destination-based dynamic rule states, see Setting a Dynamic Rule State.

- excessive matches for a particular rule across all traffic.

To configure rule-based dynamic rule states, see Setting a Dynamic Rule State.

In a network analysis policy, you can either configure SYN flood or TCP/IP connection flood detection for the entire policy; in an intrusion policy, you can set rate-based filters for individual intrusion or preprocessor rules. Note that manually adding a rate-based filter to rules 135:1 and 135:2 has no effect. Rules with GID:135 use the client as the source value and the server as the destination value. See Preventing SYN Attacks and Controlling Simultaneous Connections for more information.

Each rate-based filter contains several components:

- for policy-wide or rule-based source or destination settings, the network address designation

- the rule matching rate, which you configure as a count of rule matches within a specific number of seconds

- a new action to be taken when the rate is exceeded

When you set a rate-based setting for the entire policy, the system generates events when it detects a rate-based attack, and optionally can drop the traffic in an inline deployment. When setting rate-based actions for individual rules, you have three available actions: Generate Events, Drop and Generate Events, and Disable.

- the duration of the action, which you configure as a timeout value

Note that when started, the new action occurs until the timeout is reached, even if the rate falls below the configured rate during that time period. When the timeout period expires, if the rate has fallen below the threshold, the action for the rule reverts to the action initially configured for the rule. For policy-wide settings, the action reverts to the action of each rule the traffic matches or stops if it does not match any rules.

You can configure rate-based attack prevention in an inline deployment to block attacks, either temporarily or permanently. Without rate-based configuration, rules set to Generate Events create events, but the system does not drop packets for those rules. However, if the attack traffic matches rules that have rate-based criteria configured, the rate action may cause packet dropping to occur for the period of time that the rate action is active, even if those rules are not initially set to Drop and Generate Events.

Note Rate-based actions cannot enable disabled rules or drop traffic that matches disabled rules. However, if you set a rate-based filter at the policy level, you can generate events on or generate events on and drop traffic that contains an excessive number of SYN packets or SYN/ACK interactions within a designated time period.

You can define multiple rate-based filters on the same rule. The first filter listed in the intrusion policy has the highest priority. Note that when two rate-based filter actions conflict, the system implements the action of the first rate-based filter. Similarly, policy-wide rate-based filters override rate-based filters set on individual rules if the filters conflict.

The following diagram shows an example where an attacker is attempting to access a host. Repeated attempts to find a password trigger a rule which has rate-based attack prevention configured. The rate-based settings change the rule attribute to Drop and Generate Events after rule matches occur five times in a 10-second span. The new rule attribute times out after 15 seconds.

Preventing SYN Attacks

License: Protection

The SYN attack prevention option helps you protect your network hosts against SYN floods. You can protect individual hosts or whole networks based on the number of packets seen over a period of time. If your device is deployed passively, you can generate events. If your device is placed inline, you can also drop the malicious packets. After the timeout period elapses, if the rate condition has stopped, the event generation and packet dropping stops.

For example, you could configure a setting to allow a maximum of 10 SYN packets from any one IP address, and block further connections from that IP address for 60 seconds.

Enabling this option also activates rule 135:1. Manually activating this rule has no effect. The rule state is always displayed as Disabled, and never changes. The rule generates events when this option is enabled and a defined rate condition is exceeded.

Controlling Simultaneous Connections

License: Protection

You can also limit TCP/IP connections to or from hosts on your network to prevent denial of service (DoS) attacks or excessive activity by users. When the system detects the configured number of successful connections to or from a specified IP address or range of addresses, it generates events on additional connections. The rate-based event generation continues until the timeout period elapses without the rate condition occurring. In an inline deployment you can choose to drop packets until the rate condition times out.

For example, you could configure a setting to allow a maximum of 10 successful simultaneous connections from any one IP address, and block further connections from that IP address for 60 seconds.

Enabling this option also activates rule 135:2. Manually activating this rule has no effect. The rule state is always displayed as Disabled, and never changes. The rule generates events when this option is enabled and a defined rate condition is exceeded.

Rate-Based Attack Prevention and Other Filters

License: Protection

The detection_filter keyword and the thresholding and suppression features provide other ways to filter either the traffic itself or the events that the system generates. You can use rate-based attack prevention alone or in any combination with thresholding, suppression, or the detection_filter keyword.

See the following examples for more information:

- Rate-Based Attack Prevention and Detection Filtering

- Dynamic Rule States and Thresholding or Suppression

- Policy-Wide Rate-Based Detection and Thresholding or Suppression

- Rate-Based Detection with Multiple Filtering Methods

Rate-Based Attack Prevention and Detection Filtering

License: Protection

The detection_filter keyword prevents a rule from triggering until a threshold number of rule matches occur within a specified time. When a rule includes the detection_filter keyword, the system tracks the number of incoming packets matching the pattern in the rule per timeout period. The system can count hits for that rule from particular source or destination IP addresses. After the rate exceeds the rate in the rule, event notification for that rule begins.

The following example shows an attacker attempting a brute-force login. Repeated attempts to find a password trigger a rule that also includes the detection_filter keyword, with a count set to 5. This rule has rate-based attack prevention configured. The rate-based settings change the rule attribute to Drop and Generate Events for 20 seconds when there are five hits on the rule in a 10-second span.

As shown in the diagram, the first five packets matching the rule do not generate events because the rule does not trigger until the rate exceeds the rate indicated by the detection_filter keyword. After the rule triggers, event notification begins, but the rate-based criteria do not trigger the new action of Drop and Generate Events until five more packets pass.

After the rate-based criteria are met, events are generated and the packets are dropped until the rate-based timeout period expires and the rate falls below the threshold. After twenty seconds elapse, the rate-based action times out. After the timeout, note that packets are still dropped in the rate-based sampling period that follows. Because the sampled rate is above the threshold rate in the previous sampling period when the timeout happens, the rate-based action continues.

Note that although the example does not depict this, you can use the Drop and Generate Events rule state in combination with the detection_filter keyword to start dropping traffic when hits for the rule reach the specified rate. When deciding whether to configure rate-based settings for a rule, consider whether setting the rule to Drop and Generate Events and including the detection_filter keyword would achieve the same result, or whether you want to manage the rate and timeout settings in the intrusion policy. For more information, see Setting Rule States.

Dynamic Rule States and Thresholding or Suppression

License: Protection

You can use thresholding and suppression to reduce excessive events by limiting the number of event notifications for a rule or by suppressing notifications altogether for that rule. For more information on the available options for thresholding and suppression, see Configuring Event Thresholding and Configuring Suppression Per Intrusion Policy.

If you apply suppression to a rule, the system suppresses event notifications for that rule for all applicable IP addresses even if a rate-based action change occurs. However, the interaction between thresholding and rate-based criteria is more complex.

The following example shows an attacker attempting a brute-force login. Repeated attempts to find a password trigger a rule that has rate-based attack prevention configured. The rate-based settings change the rule attribute to Drop and Generate Events for 15 seconds when there are five hits on the rule in 10 seconds. In addition, a limit threshold limits the number of events the rule can generate to 10 events in 23 seconds.

As shown in the diagram, the rule generates events for the first five matching packets. After five packets, the rate-based criteria trigger the new action of Drop and Generate Events, and for the next five packets the rule generates events and the system drops the packet. After the tenth packet, the limit threshold has been reached, so for the remaining packets the system does not generate events but does drop the packets.

Note that although it is not shown in this example, if a new action triggers because of rate-based criteria after a threshold has been reached, the system generates a single event to indicate the change in action. So, for example, when the limit threshold of 10 is reached and the system stops generating events and the action changes from Generate Events to Drop and Generate Events on the 14th packet, the system generates an eleventh event to indicate the change in action.

Policy-Wide Rate-Based Detection and Thresholding or Suppression

License: Protection

You can use thresholding and suppression to reduce excessive events by limiting the number of event notifications for a source or destination or by suppressing notifications altogether for that rule. For more information on the available options for thresholding and suppression, see Configuring Global Thresholds, Configuring Event Thresholding, and Configuring Suppression Per Intrusion Policy.

If suppression is applied to a rule, event notifications for that rule for all applicable IP addresses are suppressed even if a rate-based action change occurs because of a policy-wide or rule-specific rate-based setting. However, the interaction between thresholding and rate-based criteria is more complex.

The following example shows an attacker attempting denial of service (DoS) attacks on hosts in your network. Many simultaneous connections to hosts from the same sources trigger a policy-wide Control Simultaneous Connections setting. The setting generates events and drops malicious traffic when there are five connections from one source in 10 seconds. In addition, a global limit threshold limits the number of events any rule or setting can generate to 10 events in 20 seconds.

As shown in the diagram, the policy-wide setting generates events for the first ten matching packets and drops the traffic. After the tenth packet, the limit threshold is reached, so for the remaining packets no events are generated but the packets are dropped.

Note that although it is not shown in this example, if a new action triggers because of rate-based criteria after a threshold has been reached, the system generates a single event to indicate the change in action. So, for example, if the limit threshold of 10 has been reached and the system stops generating events and the action changes to Drop and Generate events on the 14th packet, the system generates an eleventh event to indicate the change in action.

Rate-Based Detection with Multiple Filtering Methods

License: Protection

You may encounter situations where the detection_filter keyword, thresholding or suppression, and rate-based criteria all apply to the same traffic. When you enable suppression for a rule, events are suppressed for the specified IP addresses even if a rate-based change occurs.

The following example shows an attacker attempting a brute force login, and describes a case where a detection_filter keyword, rate-based filtering, and thresholding interact. Repeated attempts to find a password trigger a rule which includes the detection_filter keyword, with a count set to 5. This rule also has rate-based attack prevention settings that change the rule attribute to Drop and Generate Events for 30 seconds when there are five rule hits in 15 seconds. In addition, a limit threshold limits the rule to 10 events in 30 seconds.

As shown in the diagram, the first five packets matching the rule do not cause event notification because the rule does not trigger until the rate indicated in the detection_filter keyword is exceeded. After the rule triggers, event notification begins, but the rate-based criteria do not trigger the new action of Drop and Generate Events until five more packets pass. After the rate-based criteria are met, the system generates events for packets 11-15 and drops the packets. After the fifteenth packet, the limit threshold has been reached, so for the remaining packets the system does not generate events but does drop the packets.

After the rate-based timeout, note that packets are still dropped in the rate-based sampling period that follows. Because the sampled rate is above the threshold rate in the previous sampling period, the new action continues.

Configuring Rate-Based Attack Prevention

License: Protection

You can configure rate-based attack prevention at the policy level to stop SYN flood attacks. You can also stop excessive connections from a specific source or to a specific destination.

To configure rate-based attack prevention:

Admin/Intrusion Admin

Step 1 Select Policies > Access Control > Access Control Policy to display the Access Control Policy page, then click Network Analysis Policy.

The Network Analysis Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 In the navigation panel on the left, click Settings.

The Settings page appears.

Step 4 You have two choices, depending on whether Rate-Based Attack Prevention under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Rate-Based Attack Prevention page appears. A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You have two options:

- To prevent incomplete connections intended to flood a host, click Add under SYN Attack Prevention .

The SYN Attack Prevention dialog box appears.

- To prevent excessive numbers of connections, click Add under Control Simultaneous Connections .

The Control Simultaneous Connections dialog box appears.

Step 6 Select how you want to track traffic:

- To track all traffic from a specific source or range of sources, select Source from the Track By drop-down list and type a single IP address or address block in the Network field.

- To track all traffic to a specific destination or range of destinations, select Destination from the Track By drop-down list and type an IP address or address block in the Network field.

Note that the system tracks traffic separately for each IP address included in the Network field. Traffic from an IP address that exceeds the configured rate results in generated events only for that IP address. As an example, you might set a source CIDR block of 10.1.0.0/16 for the network setting and configure the system to generate events when there are ten simultaneous connections open. If eight connections are open from 10.1.4.21 and six from 10.1.5.10, the system does not generate events, because neither source has the triggering number of connections open. However, if eleven simultaneous connections are open from 10.1.4.21, the system generates events only for the connections from 10.1.4.21.

For information on using CIDR notation and prefix lengths in the FireSIGHT System, see IP Address Conventions.

Step 7 Indicate the triggering rate for the rate tracking setting:

- For SYN attack configuration, indicate the number of SYN packets per number of seconds in the Rate fields.

- For simultaneous connection configuration, indicate the number of connections in the Count field.

Step 8 To drop packets matching the rate-based attack prevention settings, select Drop.

Step 9 In the Timeout field, indicate the time period after which to stop generating events, and if applicable, dropping, for traffic with the matching pattern of SYNs or simultaneous connections.

Caution Timeout values can be integers from 1 to 1,000,000. However, setting a high timeout value may entirely block connection to a host in an inline deployment.

Step 10 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Detecting Sensitive Data

License: Protection

Sensitive data such as Social Security numbers, credit card numbers, driver’s license numbers, and so on may be leaked onto the Internet, intentionally or accidentally. The system provides a sensitive data preprocessor that can detect and generate events on sensitive data in ASCII text, which can be particularly useful in detecting accidental data leaks.

The system does not detect encrypted or obfuscated sensitive data, or sensitive data in a compressed or encoded format such as a Base64-encoded email attachment. For example, the system would detect the phone number (555)123-4567, but not an obfuscated version where each number is separated by spaces, as in (5 5 5) 1 2 3 - 4 5 6 7, or by intervening HTML code, such as <b>(555)</b>-<i>123-4567</i>. However, the system would detect, for example, the HTML coded number <b>(555)-123-4567</b> where no intervening codes interrupt the numbering pattern.

Tip The sensitive data preprocessor can detect sensitive data in unencrypted Microsoft Word files that are uploaded and downloaded using FTP or HTTP; this is possible because of the way Word files group ASCII text and formatting commands separately.

The system detects sensitive data per TCP session by matching individual data types against traffic. You can modify the default settings for each data type and for global options that apply to all data types in your intrusion policy. Cisco provides predefined, commonly used data types. You can also create custom data types.

A sensitive data preprocessor rule is associated with each data type. You enable sensitive data detection and event generation for each data type by enabling the corresponding preprocessor rule for the data type. A link on the configuration page takes you to a filtered view of sensitive data rules on the Rules page, where you can enable and disable rules and configure other rule attributes.

When you save changes to your intrusion policy, you are given the option to automatically enable the sensitive data preprocessor if the rule associated with a data type is enabled and sensitive data detection is disabled.

See the following sections for more information:

- Deploying Sensitive Data Detection

- Selecting Global Sensitive Data Detection Options

- Selecting Individual Data Type Options

- Using Predefined Data Types

- Configuring Sensitive Data Detection

- Selecting Application Protocols to Monitor

- Special Case: Detecting Sensitive Data in FTP Traffic

- Using Custom Data Types

Deploying Sensitive Data Detection

License: Protection

Because sensitive data detection can have a high impact on the performance of your FireSIGHT System, Cisco recommends that you adhere to the following guidelines:

- Select the No Rules Active default policy as your base intrusion policy; see Understanding System-Provided Base Policies for more information.

- Ensure that the following settings are enabled in the corresponding network analysis policy:

– FTP and Telnet Configuration under Application Layer Preprocessors

– IP Defragmentation and TCP Stream Configuration under Transport/Network Layer Preprocessors.

- Apply the access control policy that includes the intrusion policy containing your sensitive data configuration to a separate device reserved for sensitive data detection; see Applying an Access Control Policy for more information.

Selecting Global Sensitive Data Detection Options

License: Protection

Global sensitive data preprocessor options control how the preprocessor functions. You can modify global options that specify the following:

- whether the preprocessor replaces all but the last four credit card or Social Security numbers in triggering packets

- which destination hosts on your network to monitor for sensitive data

- how many total occurrences of all data types in a single session result in an event

Note that global sensitive data options are policy-specific and apply to all data types.

You can configure the following global sensitive data detection options.

Mask

Replaces with Xs all but the last four digits of credit card numbers and Social Security numbers in the triggering packet. The masked numbers appear in the intrusion event packet view in the web interface and in downloaded packets. See Using the Packet View for more information.

Networks

Specifies the destination host or hosts to monitor for sensitive data. You can specify a single IP address, address block, or a comma-separated list of either or both. The system interprets a blank field as any, meaning any destination IP address. For information on using IPv4 and IPv6 address blocks in the FireSIGHT System, see IP Address Conventions.

Global Threshold

Specifies the total number of all occurrences of all data types during a single session that the preprocessor must detect in any combination before generating a global threshold event. You can specify 1 through 65535.

Cisco recommends that you set the value for this option higher than the highest threshold value for any individual data type that you enable in your policy. See Selecting Individual Data Type Options for more information.

Note the following points regarding global thresholds:

– You must enable preprocessor rule 139:1 to detect and generate events on combined data type occurrences. See Setting Rule States for information on enabling rules in your intrusion policy.

– The preprocessor generates up to one global threshold event per session.

– Global threshold events are independent of individual data type events; that is, the preprocessor generates an event when the global threshold is reached, regardless of whether the event threshold for any individual data type has been reached, and vice versa.

Selecting Individual Data Type Options

License: Protection

Individual data types identify the sensitive data you can detect and generate events on in your specified destination network traffic. You can modify default settings for data type options that specify the following:

- a threshold that must be met for a detected data type to generate a single per-session event

- the destination ports to monitor for each data type

- the application protocols to monitor for each data type

At a minimum, each data type must specify an event threshold and at least one port or application protocol to monitor.

Each predefined data type provided by Cisco uses an otherwise inaccessible sd_pattern keyword to define a built-in data pattern to detect in traffic. See Table 34-8 for a listing of predefined data types. You can also create custom data types for which you use simple regular expressions to specify your own data patterns. See Using Custom Data Types for more information.

Note that data type names and patterns are system-wide; all other data type options are policy-specific.

The following table describes the data type options you can configure.

Table 34-7 Individual Data Type Options

Option

Description

Data Type

Displays the unique name for the data type.

Threshold

Specifies the number of occurrences of the data type when the system generates an event. You receive an error message when you save the policy if you do not set a threshold for an enabled data type. You can specify 1 through 255.

Note that the preprocessor generates one event for a detected data type per session. Note also that global threshold events are independent of individual data type events; that is, the preprocessor generates an event when the data type event threshold is reached, regardless of whether the global event threshold has been reached, and vice versa.

Destination Ports

Specifies destination ports to monitor for the data type. You can specify a single port, a comma-separated list of ports, or any, meaning any destination port. You receive an error message when you save the policy if you enable the rule for a data type without setting at least one port or application protocol for the data type.

Application Protocols

Note that this feature requires a Control license.

Specifies up to eight application protocols to monitor for the data type. You receive an error message when you save the policy if you enable the rule for a data type without setting at least one port or application protocol for the data type.

At least one detector must be enabled (see Activating and Deactivating Detectors) for each application protocol you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for an application protocol, the system automatically enables all Cisco-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

See Selecting Application Protocols to Monitor for detailed instructions for selecting application protocols for data types.

Pattern

For a custom data type, the specified pattern to detect (data patterns for data types provided by Cisco are predefined). See Using Custom Data Types for more information. The web interface does not display built-in patterns for predefined data types.

Note that custom and predefined data patterns are system-wide.

Using Predefined Data Types

License: Protection

Each intrusion policy includes predefined data types for detecting commonly used data patterns such as credit card numbers, email addresses, U.S. phone numbers, and U.S. Social Security numbers with and without dashes. Each predefined data type is associated with a single sensitive data preprocessor rule that has a generator ID (GID) of 138. You must enable the associated sensitive data rule in the intrusion policy to enable detection, and event generation, for each data type you want to use in your policy. See Setting Rule States for information on enabling rules in an intrusion policy.

To help you enable sensitive data rules, a link on the configuration page takes you to a filtered view of the Rules page that displays all predefined and custom sensitive data rules. You can also display only predefined sensitive data rules by selecting the sensitive-data rule filtering category on the Rules page. See Filtering Rules in an Intrusion Policy for more information. Predefined sensitive data rules are also listed on the Rule Editor page (Policies > Intrusion > Rule Editor), where you can view but not edit them under the sensitive-data rule category.

The following table describes each data type and lists the corresponding preprocessor rule that you must enable to enable detection and event generation for the data type.

Table 34-8 Sensitive Data Types

Data Type

Description

Preprocessor Rule GID:SID

Credit Card Numbers

Matches Visa®, MasterCard®, Discover® and American Express® fifteen- and sixteen-digit credit card numbers, with or without their normal separating dashes or spaces; also uses the Luhn algorithm to verify credit card check digits.

138:2

Email Addresses

Matches email addresses.

138:5

U.S. Phone Numbers

Matches U.S. phone numbers adhering to the pattern (\d{3}) ?\d{3}-\d{4}.

138:6

U.S. Social Security Numbers Without Dashes

Matches 9-digit U.S. Social Security numbers that have valid 3-digit area numbers, valid 2-digit group numbers, and do not have dashes.

138:4

U.S. Social Security Numbers With Dashes

Matches 9-digit U.S. Social Security numbers that have valid 3-digit area numbers, valid 2-digit group numbers, and dashes.

138:3

Custom

Matches a user-defined data pattern in the specified traffic. See Using Custom Data Types for more information.

138:>999999

To reduce false positives from 9-digit numbers other than Social Security numbers, the preprocessor uses an algorithm to validate the 3-digit area number and 2-digit group number that precede the 4-digit serial number in each Social Security number. The preprocessor validates Social Security group numbers through November 2009.

Configuring Sensitive Data Detection

License: Protection

You can modify default global settings and settings for individual data types. You must also enable the preprocessor rule for each data type you want to detect.

If you enable sensitive data preprocessor rules in your policy without enabling sensitive data detection, you are prompted to enable sensitive data detection when you save changes to your policy. See Resolving Conflicts and Committing Policy Changes for more information.

The following table describes actions you can take on the Sensitive Data Detection page.

Table 34-9 Sensitive Data Configuration Actions

To...

You can...

modify global settings

see Table 34-6 for information on the global settings you can modify.

modify data type options

click the data type name in the Targets page area.

The Configuration page area updates to display the current settings for the data type. See the Individual Data Type Options table for information on the options you can modify.

add or remove application protocols to monitor for a data type

Note that this feature requires a Control license.

click inside the Application Protocols field, or click Edit next to the field. The Application Protocols pop-up window appears:

- To add up to eight application protocols to monitor, select one or more application protocols from the Available list on the left, then click the right arrow ( > ) button.

- To remove an application protocol, select it from the Enabled list on the right, then click the left arrow ( < ) button.

Use Ctrl or Shift while clicking to select multiple application protocols. You can also click and drag to select multiple adjacent application protocols.

At least one detector must be enabled (see Activating and Deactivating Detectors) for each application protocol you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for an application protocol, the system automatically enables all Cisco-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.
application protocol. See Special Case: Detecting Sensitive Data in FTP Traffic for more information.

create a custom data type

click the + sign next to Data Types on the left side of the page. The Add Data Type pop-up window appears.

Specify a unique data type name and the pattern you want to detect with this data type and click OK, or click Cancel to abandon your edits. See Using Custom Data Types for more information.

display sensitive data preprocessor rules

click the Configure Rules for Sensitive Data Detection link above the Global Settings page area. A listing of all sensitive data preprocessor rules appears in a filtered display of the Rules page.

Optionally, you can enable or disable any of the listed rules. Note that you must enable the sensitive data preprocessor rule for each data type that you want to use in your intrusion policy. See Setting Rule States for more information.

You can also configure sensitive data rules for any of the other actions available on the Rules page, such as rule suppression, rate-based attack prevention, and so on; see Tuning Intrusion Policies Using Rules for more information.

Click Back to return to the Sensitive Data Detection page.

To configure sensitive data detection:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Sensitive Data Detection page appears. A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You can take any of the actions described in the Sensitive Data Configuration Actions table.

Step 6 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Selecting Application Protocols to Monitor

License: Control

You can specify up to eight application protocols to monitor for each data type. See Working with Servers for more information on the application protocols the system can detect on your network.

At least one detector must be enabled (see Activating and Deactivating Detectors) for each application protocol you select. By default, all Cisco-provided detectors are activated. If no detector is enabled for an application protocol, the system automatically enables all Cisco-provided detectors for the application; if none exist, the system enables the most recently modified user-defined detector for the application.

You must specify at least one application protocol or port to monitor for each data type. However, except in the case where you want to detect sensitive data in FTP traffic, Cisco recommends for the most complete coverage that you specify corresponding ports when you specify application protocols. For example, if you specify HTTP, you might also configure the well-known HTTP port 80. If a new host on your network implements HTTP, the system will monitor port 80 during the interval when it is discovering the new HTTP application protocol.

In the case where you want to detect sensitive data in FTP traffic, you must specify the FTP data application protocol; there is no advantage in specifying a port number. See Special Case: Detecting Sensitive Data in FTP Traffic for more information.

To modify application protocols to detect sensitive data:

Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Sensitive Data Detection page appears.

A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Click the data type name under Data Types to select the data type you want to modify.

The Configuration area updates to display the current settings for the selected data type.

Step 6 Click inside the Application Protocols field, or click Edit next to the field.

The Application Protocols pop-up window appears.

Step 7 You have two choices:

- To add up to eight application protocols to monitor, select one or more application protocols from the Available list on the left, then click the right arrow ( > ) button.

- To remove an application protocol, select it from the Enabled list on the right, then click the left arrow ( < ) button.

Use Ctrl or Shift while clicking to select multiple application protocols. You can also click and drag to select multiple adjacent application protocols.

Note To detect sensitive data in FTP traffic, you must add the FTP data application protocol. See Special Case: Detecting Sensitive Data in FTP Traffic for more information.

Step 8 Click OK to add the application protocols.

The Sensitive Data Detection page is displayed and the application protocols are updated.

Special Case: Detecting Sensitive Data in FTP Traffic

License: Control

You usually determine which traffic to monitor for sensitive data by specifying the ports to monitor or, optionally, specifying application protocols in deployments. However, specifying ports or application protocols is not sufficient for detecting sensitive data in FTP traffic. Sensitive data in FTP traffic is found in traffic for the FTP application protocol, which occurs intermittently and uses a transient port number, making it difficult to detect. To detect sensitive data in FTP traffic, you must include the following in your configuration:

- Specify the FTP data application protocol.

Specifying the FTP data application protocol enables detection of sensitive data in FTP traffic. See Selecting Application Protocols to Monitor for more information.

In the special case of detecting sensitive data in FTP traffic, specifying the FTP data application protocol does not invoke detection; instead, it invokes the rapid processing of the FTP/Telnet processor to detect sensitive data in FTP traffic. See Decoding FTP and Telnet Traffic for more information.

- Ensure that the FTP Data detector, which is enabled by default, is enabled.

See Activating and Deactivating Detectors.

- Ensure that your configuration includes at least one port to monitor for sensitive data.

Note that it is not necessary to specify an FTP port except in the unlikely case where you only want to detect sensitive data in FTP traffic. Most sensitive data configurations will include other ports such as HTTP or email ports. In the case where you do want to specify only one FTP port and no other ports to monitor, Cisco recommends that you specify the FTP command port 23. See Configuring Sensitive Data Detection or more information.

Using Custom Data Types

License: Protection

You can create and modify custom data types to detect data patterns that you specify. For example, a hospital might create a data type to protect patient numbers, or a university might create a data type to detect student numbers that have a unique numbering pattern.

Each custom date type you create also creates a single sensitive data preprocessor rule that has a generator ID (GID) of 138 and a Snort ID of 1000000 or greater, that is, a SID for a local rule. You must enable the associated sensitive data rule to enable detection, and event generation, for each custom data type you want to use in your policy. See Setting Rule States for information on enabling rules in an intrusion policy.

To help you enable sensitive data rules, a link on the configuration page takes you to a filtered view of the Rules page that displays all predefined and custom sensitive data rules. You can also display only custom sensitive data rules by selecting the local rule filtering category on the Rules page. See Filtering Rules in an Intrusion Policy for more information. Note that custom sensitive data rules are not listed on the Rule Editor page.

Custom data types you create are added to all intrusion policies. You must enable the associated sensitive data rule in any policy that you want to use to detect and generate events for a particular custom data type.

Note that you must use the Sensitive Data Detection configuration page to create data types and their associated rules. You cannot use the rule editor to create sensitive data rules.

See the following sections for more information:

- Defining Data Patterns in Custom Data Types

- Configuring Custom Data Types

- Editing Custom Data Type Names and Detection Patterns

Defining Data Patterns in Custom Data Types

License: Protection

You define the data pattern for a custom data type using a simple set of regular expressions comprised of the following:

- three metacharacters

- escaped characters that allow you to use the metacharacters as literal characters

- six character classes

Metacharacters are literal characters that have special meaning within regular expressions. The following table describes the metacharacters you can use when defining a custom data pattern.

Table 34-10 Sensitive Data Pattern Metacharacters

Metacharacter

Description

Example

?

Matches zero or one occurrence of the preceding character or escape sequence; that is, the preceding character or escape sequence is optional.

colou?r matches color or colour

{n}

Matches the preceding character or escape sequence n times.

For example,

\d{2} matches 55, 12, and so on;

\l{3} matches AbC, www, and so on;

\w{3} matches a1B, 25C, and so on;

x{5} matches xxxxx

\

Allows you to use metacharacters as actual characters and is also used to specify a predefined character class. See Table 34-12 for a description of the character classes you can use in sensitive data patterns.

\? matches a question mark,

\\ matches a backslash,

\d matches numeric characters, and so on

Table 34-11 Escaped Sensitive Data Pattern Characters

Use this escaped character...

To represent this literal character...

\?

?

\{

{

\}

}

\\

\

The following table describes the character classes you can use when defining a custom sensitive data pattern.

Table 34-12 Sensitive Data Pattern Character Classes

Character Class

Description

Character Class Definition

\d

Matches any numeric ASCII character 0-9

0-9

\D

Matches any byte that is not a numeric ASCII character

not 0-9

\l (lowercase “ell”)

Matches any ASCII letter

a-zA-Z

\L

Matches any byte that is not an ASCII letter

not a-zA-Z

\w

Matches any ASCII alphanumeric character

Note that, unlike PCRE regular expressions, this does not include an underscore (_).

a-zA-Z0-9

\W

Matches any byte that is not an ASCII alphanumeric character

not a-zA-Z0-9

The preprocessor treats characters entered directly, instead of as part of a regular expression, as literal characters. For example, the data pattern 1234 matches 1234.

The following data pattern example, which is used in predefined sensitive data rule 138:4, uses the escaped digits character class, the multiplier and option-specifier metacharacters, and the literal dash (-) and left and right parentheses () characters to detect U.S. phone numbers:

(\d{3}) ?\d{3}-\d{4}

Exercise caution when creating custom data patterns. Consider the following alternative data pattern for detecting phone numbers which, although using valid syntax, could cause many false positives:

(?\d{3})? ?\d{3}-?\d{4}

Because the second example combines optional parentheses, optional spaces, and optional dashes, it would detect, among others, phone numbers in the following desirable patterns:

- (555)123-4567

- 555123-4567

- 5551234567

However, the second example pattern would also detect, among others, the following potentially invalid patterns, resulting in false positives:

- (555 1234567

- 555)123-4567

- 555) 123-4567

Consider finally, for illustration purposes only, an extreme example in which you create a data pattern that detects the lowercase letter a using a low event threshold in all destination traffic on a small company network. Such a data pattern could overwhelm your system with literally millions of events in only a few minutes.

Configuring Custom Data Types

License: Protection

You configure essentially the same data type options for custom data types that you configure for predefined data types. See Selecting Individual Data Type Options for information on setting options that are common to all data types. In addition, you must also specify the name and data pattern for custom data types.

Note that creating a custom data type also creates an associated custom sensitive data preprocessing rule, which you must enable in each policy where you want to use that data type. See Setting Rule States for information on enabling rules in your intrusion policy.

To create or modify a custom data type:

Admin/Intrusion Admin

Step 1 Select Policies> Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Sensitive Data Detection page appears.

A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 You have the following options:

- To create a custom data type, click the + sign next to Data Types on the left side of the page. The Add Data Type pop-up window appears.

Specify a unique data type name and the pattern you want to detect with this data type and click OK, or click Cancel to abandon your edits. See Editing Custom Data Type Names and Detection Patterns for more information.

The Sensitive Data Detection page appears. If you clicked OK, the page updates to display your changes.

- To modify any of the options that are common to predefined and custom data types, click the data type name in the Targets page area.

The Configuration page area updates to display the current settings for the data type. See Configuring Sensitive Data Detection for more information.

- To edit the system-wide name and data pattern for a custom data type, see Editing Custom Data Type Names and Detection Patterns.

- To delete a custom data type, click the delete icon (

) next to the data type you want to remove and then click OK , or click Cancel to abandon deleting the data type.

Note that you cannot delete a data type when the sensitive data rule for that data type is enabled in any intrusion policy. Deleting a custom data type deletes it from all intrusion policies.

Editing Custom Data Type Names and Detection Patterns

License: Protection

You can modify the system-wide name and detection pattern for custom sensitive data rules. Note that changing these settings changes them in all other policies on the system. Note also that you must reapply any applied access control policies that include intrusion policies that use custom data types that you modify.

Except for custom data type names and data patterns, all data type options are policy-specific for both custom and predefined data types. See Selecting Individual Data Type Options for information on modifying options other than the name and data pattern in your custom data types.

To edit custom data type names and data patterns:

Admin/Intrusion Admin

Step 1 Select Policies> Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Sensitive Data Detection under Specific Threat Detection is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Sensitive Data Detection page appears.

A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 In the Targets page area, click the name of the custom data type you want to modify.

The page updates to show the current settings for the data type, and the Edit Data Type Name and Pattern link appears in the upper right of the Configuration page area.

Step 6 Click the Edit Data Type Name and Pattern link.

The Edit Data Type pop-up window appears.

Step 7 Modify the data type name, pattern, or both and click OK, or click Cancel to abandon your edits. See Defining Data Patterns in Custom Data Types for information on specifying the data pattern.

The Sensitive Data Detection page appears. If you clicked OK, the page displays your changes.

Globally Limiting Intrusion Event Logging

You can use thresholds to limit the number of times the system logs and displays intrusion events. Thresholds, which you configure as part of your intrusion policy, cause the system to generate events based on how many times traffic matching a rule originates from or is targeted to a specific address or address range within a specified time period. This can prevent you from being overwhelmed with a large number of events. This feature requires a Protection license.

You can set event notification thresholds in two ways:

- You can set a global threshold across all traffic to limit how often events from a specific source or destination are logged and displayed per specified time period. For more information, see Understanding Thresholding and Configuring Global Thresholds.

- You can set thresholds per shared object rule, standard text rule, or preprocessor rule in your intrusion policy configuration, as described in Configuring Event Thresholding.

Understanding Thresholding

License: Protection

By default, every intrusion policy contains a global rule threshold. The default threshold limits event generation for each rule to one event every 60 seconds on traffic going to the same destination. This global threshold applies by default to all intrusion rules and preprocessor rules. Note that you can disable the threshold in the Advanced Settings page in an intrusion policy.

You can also override this threshold by setting individual thresholds on specific rules. For example, you might set a global limit threshold of five events every 60 seconds, but then set a specific threshold of ten events for every 60 seconds for SID 1315. All other rules generate no more than five events in each 60-second period, but the system generates up to ten events for each 60-second period for SID 1315.

For more information on setting rule-based thresholds, see Configuring Event Thresholding.

Tip A global or individual threshold on a managed device with multiple CPUs may result in a higher number of events than expected.

The following diagram shows an example where an attack is in progress for a specific rule. A global limit threshold limits event generation for each rule to two events every 20 seconds.

Note that the period starts at one second and ends at 21 seconds. After the period ends, note that the cycle starts again and the next two rule matches generate events, then the system does not generate any more events during that period.

Understanding Thresholding Options

License: Protection

Thresholding allows you to limit intrusion event generation by generating only a specific number of events in a time period, or by generating one event for a set of events. When you configure global thresholding, you must first specify the thresholding type, as described in the following table.

Table 35-1 Thresholding Options

Option

Description

Limit

Logs and displays events for the specified number of packets (specified by the count argument) that trigger the rule during the specified time period. For example, if you set the type to Limit, the Count to 10, and the Seconds to 60, and 14 packets trigger the rule, the system stops logging events for the rule after displaying the first 10 that occur within the same minute.

Threshold

Logs and displays a single event when the specified number of packets (specified by the count argument) trigger the rule during the specified time period. Note that the counter for the time restarts after you hit the threshold count of events and the system logs that event. For example, you set the type to Threshold, Count to 10, and Seconds to 60, and the rule triggers 10 times by second 33. The system generates one event, then resets the Seconds and Count counters to 0. The rule then triggers another 10 times in the next 25 seconds. Because the counters reset to 0 at second 33, the system logs another event.

Both

Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the rule. For example, if you set the type to Both, Count to 2, and Seconds to 10, the following event counts result:

- If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is not met)

- If the rule is triggered twice in 10 seconds, the system generates one event (the threshold is met when the rule triggers the second time)

- If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met when the rule triggered the second time and following events are ignored)

Next, specify the tracking, which determines whether the event instance count is calculated per source or destination IP address. Finally, specify the number of instances and time period that define the threshold.

Table 35-2 Thresholding Instance/Time Options

Option

Description

Count

The number of event instances per specified time period per tracking IP address or address range required to meet the threshold.

Seconds

The number of seconds that elapse before the count resets. If you set the threshold type to Limit, the tracking to Source, Count to 10, and Seconds to 10, the system logs and displays the first 10 events that occur in 10 seconds from a given source port. If only seven events occur in the first 10 seconds, the system logs and displays those, if 40 events occur in the first 10 seconds, the system logs and displays 10, then begins counting again when the 10-second time period elapses.

Configuring Global Thresholds

License: Protection

You can set a global threshold to manage the number of events generated by each rule over a period of time. When you set a global threshold, that threshold applies for each rule that does not have an overriding specific threshold. For more information on configuring thresholds, see Understanding Thresholding.

A global threshold is configured on your system by default. The default values are as follows:

- Type — Limit

- Track By — Destination

- Count — 1

- Seconds — 60

To configure global thresholding:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Global Rule Thresholding under Intrusion Rule Thresholds is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Global Rule Thresholding page appears. A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 From the Type radio buttons, select the type of threshold that will apply over the time specified by the seconds argument. See the Thresholding Options table for more information:

- Select Limit to log and display an event for each packet that triggers the rule until the limit specified by the count argument is exceeded.

- Select Threshold to log and display a single event for each packet that triggers the rule and represents either the instance that matches the threshold set by the count argument or is a multiple of the threshold.

- Select Both to log and display a single event after the number of packets specified by the count argument trigger the rule.

Step 6 Select the tracking method from the Track By radio buttons:

- Select Source to identify rule matches in traffic coming from a particular source IP address or addresses.

- Select Destination to identify rule matches in traffic going to a particular destination IP address.

Step 7 In the Count field:

- For a Limit threshold, specify the number of event instances per specified time period per tracking IP address required to meet the threshold.

- For a Threshold threshold, specify the number of rule matches you want to use as your threshold.

Step 8 In the Seconds field:

- For a Limit threshold, specify the number of seconds that make up the time period when attacks are tracked.

- For a Threshold threshold, specify the number of seconds that elapse before the count resets. Note that the count resets if the number of rule matches indicated by the Count field occur before the number of seconds indicated elapse.

Step 9 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Disabling the Global Threshold

License: Protection

By default, a global limit threshold limits the number of events on traffic going to a destination to one event per 60 seconds. You can disable global thresholding in the highest policy layer if you want to threshold events for specific rules and not apply thresholding to every rule by default.

To disable global thresholding:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Settings in the navigation panel on the left.

The Settings page appears.

Step 4 Under Intrusion Rule Thresholds, disable Global Rule Thresholding.

Step 5 Save your policy, continue editing, discard your changes, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding and Writing Intrusion Rules

An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit vulnerabilities on your network by analyzing network traffic to check if it matches the criteria in the rule. The system compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion event. If it is a pass rule, it ignores the traffic. You can view and evaluate intrusion events from the Defense Center web interface.

Caution Make sure you use a controlled network environment to test any intrusion rules that you write before you use the rules in a production environment. Poorly written intrusion rules may seriously affect the performance of the system.

Note the following:

- For a drop rule in an inline deployment, the system drops the packet and generates an event. For more information on drop rules, see Setting Rule States.

- Cisco provides two types of intrusion rules: shared object rules and standard text rules. The Cisco Vulnerability Research Team (VRT) can use shared object rules to detect attacks against vulnerabilities in ways that traditional standard text rules cannot. You cannot create shared object rules. When you write your own intrusion rule, you create a standard text rule.

You can write custom standard text rules to tune the types of events you are likely to see. Note that while this documentation sometimes discusses rules targeted to detect specific exploits, the most successful rules target traffic that may attempt to exploit known vulnerabilities rather than specific known exploits. By writing rules and specifying the rule’s event message, you can more easily identify traffic that indicates attacks and policy evasions. For more information about evaluating events, see Working with Intrusion Events.

When you enable a custom standard text rule in a custom intrusion policy, keep in mind that some rule keywords and arguments require that traffic first be decoded or preprocessed in a certain way. This chapter explains the options you must configure in your network analysis policy, which governs preprocessing. Note that if you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Note Because preprocessing and intrusion inspection are so closely related, the network analysis and intrusion policies examining a single packet must complement each other. Tailoring preprocessing, especially using multiple custom network analysis policies, is an advanced task. For more information, see Limitations of Custom Policies.

See the following sections for more information:

- Understanding Rule Anatomy describes the components, including the rule header and rule options, that make up a valid standard text rule.

- Understanding Rule Headers provides a detailed description of the parts of a rule header.

- Understanding Keywords and Arguments in Rules explains the usage and syntax of the intrusion rule keywords available in the FireSIGHT System.

- Constructing a Rule explains how to build a new rule using the rule editor.

- Searching for Rules explains how to search for existing rules.

- Filtering Rules on the Rule Editor Page explains how to display a subset of rules to help you find specific rules.

Understanding Rule Anatomy

License: Protection

All standard text rules contain two logical sections: the rule header and the rule options. The rule header contains:

- the rule's action or type

- the protocol

- the source and destination IP addresses and netmasks

- direction indicators showing the flow of traffic from source to destination

- the source and destination ports

The rule options section contains:

- event messages

- keywords and their parameters and arguments

- patterns that a packet’s payload must match to trigger the rule

- specifications of which parts of the packet the rules engine should inspect

Note that the options section of a rule is the section enclosed in parentheses. The rule editor provides an easy-to-use interface to help you build standard text rules.

Understanding Rule Headers

License: Protection

Table 36-1 Rule Header Values

Rule Header Component

Example Value

This Value...

Action

alert

Generates an intrusion event when triggered.

Protocol

tcp

Tests TCP traffic only.

Source IP Address

$EXTERNAL_NET

Tests traffic coming from any host that is not on your internal network.

Source Ports

any

Tests traffic coming from any port on the originating host.

Operator

->

Tests external traffic (destined for the web servers on your network).

Destination IP Address

$HTTP_SERVERS

Tests traffic to be delivered to any host specified as a web server on your internal network.

Destination Ports

$HTTP_PORTS

Tests traffic delivered to an HTTP port on your internal network.

Note The previous example uses default variables, as do most intrusion rules. See Working with Variable Sets for more information about variables, what they mean, and how to configure them.

See the following sections for more information about rule header parameters:

- Specifying Rule Actions describes rule types and explains how to specify the action that occurs when the rule triggers.

- Specifying Protocols explains how to define the traffic protocol for traffic that the rule should test.

- Specifying IP Addresses In Intrusion Rules explains how to define the individual IP addresses and IP address blocks in the rule header.

- Defining Ports in Intrusion Rules explains how to define the individual ports and port ranges in the rule header.

- Specifying Direction describes the available operators and explains how to specify the direction traffic must be traveling to be tested by the rule.

Specifying Rule Actions

License: Protection

Each rule header includes a parameter that specifies the action the system takes when a packet triggers a rule. Rules with the action set to alert generate an intrusion event against the packet that triggered the rule and log the details of that packet. Rules with the action set to pass do not generate an event against, or log the details of, the packet that triggered the rule.

Note In an inline deployment, rules with the rule state set to Drop and Generate Events generate an intrusion event against the packet that triggered the rule. Also, if you apply a drop rule in a passive deployment, the rule acts as an alert rule. For more information on drop rules, see Setting Rule States.

By default, pass rules override alert rules. You can create pass rules to prevent packets that meet criteria defined in the pass rule from triggering the alert rule in specific situations, rather than disabling the alert rule. For example, you might want a rule that looks for attempts to log into an FTP server as the user “anonymous” to remain active. However, if your network has one or more legitimate anonymous FTP servers, you could write and activate a pass rule that specifies that, for those specific servers, anonymous users do not trigger the original rule.

Within the rule editor, you select the rule type from the Action list. For more information about the procedures you use to build a rule header using the rule editor, see Constructing a Rule.

Specifying Protocols

License: Protection

In each rule header, you must specify the protocol of the traffic the rule inspects. You can specify the following network protocols for analysis:

- ICMP (Internet Control Message Protocol)

- IP (Internet Protocol)

Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more information, see Defining Ports in Intrusion Rules.

- TCP (Transmission Control Protocol)

- UDP (User Datagram Protocol)

Use IP as the protocol type to examine all protocols assigned by IANA, including TCP, UDP, ICMP, IGMP, and many more. See http://www.iana.org/assignments/protocol-numbers for a full list of IANA-assigned protocols.

Note You cannot currently write rules that match patterns in the next header (for example, the TCP header) in an IP payload. Instead, content matches begin with the last decoded protocol. As a workaround, you can match patterns in TCP headers by using rule options.

Within the rule editor, you select the protocol type from the Protocol list. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

Specifying IP Addresses In Intrusion Rules

License: Protection

Restricting packet inspection to the packets originating from specific IP addresses or destined to a specific IP address reduces the amount of packet inspection the system must perform. This also reduces false positives by making the rule more specific and removing the possibility of the rule triggering against packets whose source and destination IP addresses do not indicate suspicious behavior.

Tip The system recognizes only IP addresses and does not accept host names for source or destination IP addresses.

Within the rule editor, you specify source and destination IP addresses in the Source IPs and Destination IPs fields. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

When writing standard text rules, you can specify IPv4 and IPv6 addresses in a variety of ways, depending on your needs. You can specify a single IP address, any, IP address lists, CIDR notation, prefix lengths, a network variable, or a network object or network object group. Additionally, you can indicate that you want to exclude a specific IP address or set of IP addresses. When specifying IPv6 addresses, you can use any addressing convention defined in RFC 4291.

Table 36-2 Source/Destination IP Address Syntax

To Specify...

Use...

Example

any IP address

any

any

a specific IP address

the IP address

Note that you would not mix IPv4 and IPv6 source and destination addresses in the same rule.

192.168.1.1

2001:db8::abcd

a list of IP addresses

brackets ([]) to enclose the IP addresses and commas to separate them

[192.168.1.1,192.168.1.15]

[2001:db8::b3ff, 2001:db8::0202]

a block of IP addresses

IPv4 CIDR block or IPv6 address prefix notation

192.168.1.0/24

2001:db8::/32

anything except a specific IP address or set of addresses

the ! character before the IP address or addresses you want to negate

!192.168.1.15

!2001:db8::0202:b3ff:fe1e

anything in a block of IP addresses except one or more specific IP addresses

a block of addresses followed by a list of negated addresses or blocks

[10.0.0/8, !10.2.3.4, !10.1.0.0/16]

[2001:db8::/32, !2001:db8::8329, !2001:db8::0202]

IP addresses defined by a network variable

the variable name, in uppercase letters, preceded by $

Note that preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion rules. See Working with Variable Sets for more information.

$HOME_NET

all IP addresses except addresses defined by an IP address variable

the variable name, in uppercase letters, preceded by !$

See Excluding IP Addresses in Intrusion Rules for more information.

!$HOME_NET

IP addresses defined by a network object or network object group

the object or group name using the format !{object_name}.

See Working with Network Objects for more information.

${192.168sub16}

all IP addresses except addresses defined by a network object or network object group

the object or group name, in curly braces ({}), preceded by !$.

See Working with Network Objects for more information.

!${192.168sub16}

See the following sections for more in-depth information about the syntax you can use to specify source and destination IP addresses, and for information about using variables to specify IP addresses:

- IP Address Conventions.

- Working with Variable Sets

- Specifying Any IP Address

- Specifying Multiple IP Addresses

- Specifying Network Objects

- Excluding IP Addresses in Intrusion Rules

Specifying Any IP Address

License: Protection

You can specify the word any as a rule source or destination IP address to indicate any IPv4 or IPv6 address.

For example, the following rule uses the argument any in the Source IPs and Destination IPs fields and evaluates packets with any IPv4 or IPv6 source or destination address:

alert tcp any any -> any any

You can also specify :: to indicate any IPv6 address.

Specifying Multiple IP Addresses

License: Protection

You can list individual IP addresses by separating the IP addresses with commas and, optionally, by surrounding non-negated lists with brackets, as shown in the following example:

[192.168.1.100,192.168.1.103,192.168.1.105]

You can list IPv4 and IPv6 addresses alone or in any combination, as shown in the following example:

[192.168.1.100,2001:db8::1234,192.168.1.105]

Note that surrounding an IP address list with brackets, which was required in earlier software releases, is not required. Note also that, optionally, you can enter lists with a space before or after each comma.

Note You must surround negated lists with brackets. See Excluding IP Addresses in Intrusion Rules for more information.

You can also use IPv4 Classless Inter-Domain Routing (CIDR) notation or IPv6 prefix lengths to specify address blocks. For example:

- 192.168.1.0/24 specifies the IPv4 addresses in the 192.168.1.0 network with a subnet mask of 255.255.255.0, that is, 192.168.1.0 through 192.168.1.255. For more information, see IP Address Conventions.

- 2001:db8::/32 specifies the IPv6 addresses in the 2001:db8:: network with a prefix length of 32 bits, that is, 2001:db8:: through 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff.

Tip If you need to specify a block of IP addresses but cannot express it using CIDR or prefix length notation alone, you can use CIDR blocks and prefix lengths in an IP address list.

Specifying Network Objects

License: Protection

You can specify a network object or network object group using the syntax:

${object_name | group_name}

where:

- object_name is the name of a network object

- group_name is the name of a network object group

See Working with Network Objects for information on creating network objects and network object groups.

Consider the case where you have created a network object named 192.168sub16 and a network object group named all_subnets. You could specify the following to identify IP addresses using the network object:

${192.168sub16}

and you could specify the following to use the network object group:

${all_subnets}

You can also use negation with network objects and network object groups. For example:

!${192.168sub16}

See Excluding IP Addresses in Intrusion Rules for more information.

Excluding IP Addresses in Intrusion Rules

License: Protection

You can use an exclamation point (!) to negate a specified IP address. That is, you can match any IP address with the exception of the specified IP address or addresses. For example, !192.168.1.1 specifies any IP address other than 192.168.1.1, and !2001:db8:ca2e::fa4c specifies any IP address other than 2001:db8:ca2e::fa4c.

To negate a list of IP addresses, place ! before a bracketed list of IP addresses. For example, ![192.168.1.1,192.168.1.5] would define any IP address other than 192.168.1.1 or 192.168.1.5.

Note You must use brackets to negate a list of IP addresses.

Be careful when using the negation character with IP address lists. For example, if you use [!192.168.1.1,!192.168.1.5] to match any address that is not 192.168.1.1 or 192.168.1.5, the system interprets this syntax as “anything that is not 192.168.1.1, or anything that is not 192.168.1.5.”

Because 192.168.1.5 is not 192.168.1.1, and 192.168.1.1 is not 192.168.1.5, both IP addresses match the IP address value of [!192.168.1.1,!192.168.1.5], and it is essentially the same as using “any.”

Instead, use ![192.168.1.1,192.168.1.5]. The system interprets this as “not 192.168.1.1 and not 192.168.1.5,” which matches any IP address other than those listed between brackets.

Note that you cannot logically use negation with any which, if negated, would indicate no address.

Defining Ports in Intrusion Rules

License: Protection

Within the rule editor, you specify source and destination ports in the Source Port and Destination Port fields. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

The FireSIGHT System uses a specific type of syntax to define the port numbers used in rule headers.

Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more information, see Specifying Protocols.

You can list ports by separating the ports with commas, as shown in the following example:

80, 8080, 8138, 8600-9000, !8650-8675

Optionally, the following example shows how you can surround a port list with brackets, which was required in previous software versions but is no longer required:

[80, 8080, 8138, 8600-9000, !8650-8675]

Note that you must surround negated port lists in brackets, as shown in the following example:

![20, 22, 23]

Note also that a list of source or destination ports in an intrusion rule can include a maximum of 64 characters.

Table 36-3 Source/Destination Port Syntax

To Specify...

Use

Example

any port

any

any

a specific port

the port number

80

a range of ports

a dash between the first and last port number in the range

80-443

all ports less than or equal to a specific port

a dash before the port number

-21

all ports greater than or equal to a specific port

a dash after the port number

80-

all ports except a specific port or range of ports

the ! character before the port, port list, or range of ports you want to negate

Note that you can logically use negation with all port designations except any, which if negated would indicate no port.

!20

all ports defined by a port variable

the variable name, in uppercase letter, preceded by $

See Working with Port Variables for more information.

$HTTP_PORTS

all ports except ports defined by a port variable

the variable name, in uppercase letter, preceded by !$

!$HTTP_PORTS

Specifying Direction

License: Protection

Table 36-4 Directional Options in Rule Headers

Use...

To Test...

Directional

only traffic from the specified source IP address to the specified destination IP address

Bidirectional

all traffic traveling between the specified source and destination IP addresses

See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

Understanding Keywords and Arguments in Rules

License: Protection

Using the rules language, you can specify the behavior of a rule by combining keywords. Keywords and their associated values (called arguments) dictate how the system evaluates packets and packet-related values that the rules engine tests. The FireSIGHT System currently supports keywords that allow you to perform inspection functions, such as content matching, protocol-specific pattern matching, and state-specific matching. You can define up to 100 arguments per keyword, and combine any number of compatible keywords to create highly specific rules. This helps decrease the chance of false positives and false negatives and focus the intrusion information you receive.

Note that you can also use adaptive profiles to dynamically adapt active rule processing for specific packets based on rule metadata and host information. For more information, see Tuning Preprocessing in Passive Deployments.

See the following sections for more information:

- Defining Intrusion Event Details describes the syntax and use of keywords that allow you to define the event’s message, priority information, and references to external information about the exploit the rule detects.

- Searching for Content Matches describes how to use the content or protected_content keywords to test the content of the packet payload.

- Constraining Content Matches describes how to use modifying keywords for the content or protected_content keywords.

- Replacing Content in Inline Deployments describes how to use the replace keyword in inline deployments to replace specified content of equal length.

- Using Byte_Jump and Byte_Test describes how to use the byte_jump and byte_test keywords to calculate where in a packet the rules engine should begin testing for a content match, and which bytes it should evaluate.

- Searching for Content Using PCRE describes how to use the pcre keyword to use Perl-compatible regular expressions in rules.

- Adding Metadata to a Rule describes how to use the metadata keyword to add information to a rule.

- Inspecting IP Header Values describes the syntax and use of keywords that test values in the packet’s IP header.

- Inspecting ICMP Header Values describes the syntax and use of keywords that test values in the packet’s ICMP header.

- Inspecting TCP Header Values and Stream Size describes the syntax and use of keywords that test values in the packet’s TCP header.

- Enabling and Disabling TCP Stream Reassembly describes how to enable and disable stream reassembly for a single connection when inspected traffic on the connection matches the conditions of the rule.

- Extracting SSL Information from a Session describes the use and syntax of keywords that extract version and state information from encrypted traffic.

- Reading Packet Data into Keyword Arguments describes how to read a value from a packet into a variable that you can use later in the same rule to specify the value for arguments in certain other keywords.

- Inspecting Application Layer Protocol Values describes the use and syntax of keywords that test application layer protocol properties.

- Inspecting Packet Characteristics describes the use and syntax of the dsize , sameIP , isdataat , fragoffset , and cvs keywords.

- Initiating Active Responses with Rule Keywords explains how to use the resp keyword to actively close TCP connections or UDP sessions, the react keyword to send an HTML page and then actively close TCP connections, and the config response command to specify the active response interface and the number of TCP resets to attempt in a passive deployment.

- Filtering Events describes how to prevent a rule from triggering an event unless a specified number packets meet the rule’s detection criteria within a specified time.

- Evaluating Post-Attack Traffic describes how to log additional traffic for the host or session.

- Detecting Attacks That Span Multiple Packets describes how to assign state names to packets from attacks that span multiple packets in a single session, then analyze and alert on packets according to their state.

- Generating Events on the HTTP Encoding Type and Location describes how to generate events on the type of encoding in an HTTP request or response URI, header, or cookie, including set-cookies, before normalization.

- Detecting File Types and Versions describes how to point to a specific file type or file version using the file_type or file_group keyword.

- Pointing to a Specific Payload Type describes how to point to the beginning of the HTTP response entity body, SMTP payload, or encoded email attachment.

- Pointing to the Beginning of the Packet Payload describes how to point to the beginning of the packet payload.

- Decoding and Inspecting Base64 Data describes how you can use the base64_decode and base64_data keywords to decode and inspect Base64 data, especially in HTTP requests.

Defining Intrusion Event Details

License: Protection

As you construct a standard text rule, you can include contextual information that describes the vulnerability that the rule detects attempts to exploit. You can also include external references to vulnerability databases and define the priority that the event holds in your organization. When analysts see the event, they then have information about the priority, exploit, and known mitigation readily available.

See the following sections for more information about event-related keywords:

- Defining the Event Message

- Defining the Event Priority

- Defining the Intrusion Event Classification

- Defining the Event Reference

Defining the Event Message

License: Protection

You can specify meaningful text that appears as a message when the rule triggers. The message gives immediate insight into the nature of the vulnerability that the rule detects attempts to exploit. You can use any printable standard ASCII characters except curly braces ({}). The system strips quotes that completely surround the message.

Tip You must specify a rule message. Also, the message cannot consist of white space only, one or more quotation marks only, one or more apostrophes only, or any combination of just white space, quotation marks, or apostrophes.

To define the event message in the rule editor, enter the event message in the Message field. See Constructing a Rule for more information about using the rule editor to build rules.

Defining the Event Priority

License: Protection

By default, the priority of a rule derives from the event classification for the rule. However, you can override the classification priority for a rule by adding the priority keyword to the rule.

To specify a priority using the rule editor, select priority from the Detection Options list, and select high, medium, or low from the drop-down list. For example, to assign a high priority for a rule that detects web application attacks, add the priority keyword to the rule and select high as the priority. See Constructing a Rule for more information about using the rule editor to build rules.

Defining the Intrusion Event Classification

License: Protection

For each rule, you can specify an attack classification that appears in the packet display of the event. The following table lists the name and number for each classification.

Table 36-5 Rule Classifications

Number

Classification Name

Description

1

not-suspicious

Not Suspicious Traffic

2

unknown

Unknown Traffic

3

bad-unknown

Potentially Bad Traffic

4

attempted-recon

Attempted Information Leak

5

successful-recon-limited

Information Leak

6

successful-recon-largescale

Large Scale Information Leak

7

attempted-dos

Attempted Denial of Service

8

successful-dos

Denial of Service

9

attempted-user

Attempted User Privilege Gain

10

unsuccessful-user

Unsuccessful User Privilege Gain

11

successful-user

Successful User Privilege Gain

12

attempted-admin

Attempted Administrator Privilege Gain

13

successful-admin

Successful Administrator Privilege Gain

14

rpc-portmap-decode

Decode of an RPC Query

15

shellcode-detect

Executable Code was Detected

16

string-detect

A Suspicious String was Detected

17

suspicious-filename-detect

A Suspicious Filename was Detected

18

suspicious-login

An Attempted Login Using a Suspicious Username was Detected

19

system-call-detect

A System Call was Detected

20

tcp-connection

A TCP Connection was Detected

21

trojan-activity

A Network Trojan was Detected

22

unusual-client-port-connection

A Client was Using an Unusual Port

23

network-scan

Detection of a Network Scan

24

denial-of-service

Detection of a Denial of Service Attack

25

non-standard-protocol

Detection of a Non-Standard Protocol or Event

26

protocol-command-decode

Generic Protocol Command Decode

27

web-application-activity

Access to a Potentially Vulnerable Web Application

28

web-application-attack

Web Application Attack

29

misc-activity

Misc Activity

30

misc-attack

Misc Attack

31

icmp-event

Generic ICMP Event

32

inappropriate-content

Inappropriate Content was Detected

33

policy-violation

Potential Corporate Privacy Violation

34

default-login-attempt

Attempt to Login By a Default Username and Password

35

sdf

Sensitive Data

36

malware-cnc

Known malware command and control traffic

37

client-side-exploit

Known client side exploit attempt

38

file-format

Known malicious file or file based exploit

To specify a classification in the rule editor, select a classification from the Classification list. See Writing New Rules for more information on the rule editor.

Adding Custom Classifications

License: Protection

If you want more customized content for the packet display description of the events generated by a rule you define, create a custom classification.

To add classifications to the Classification list:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 Under the Classification drop-down list, click Edit Classifications.

A pop-up window appears.

Step 4 Type the name of the classification in the Classification Name field.

You can use up to 255 alphanumeric characters, but the page is difficult to read if you use more than 40 characters. The following characters are not supported: <>()\'"&$; and the space character.

Step 5 Type a description of the classification in the Classification Description field.

You can use up to 255 alphanumeric characters and spaces. The following characters are not supported: <>()\'"&$;

Step 6 Select a priority from the Priority list.

You can select high, medium, or low.

Step 7 Click Add.

The new classification is added to the list and becomes available for use in the rule editor.

Step 8 Click Done.

Defining the Event Reference

License: Protection

You can use the reference keyword to add references to external web sites and additional information about the event. Adding a reference provides analysts with an immediately available resource to help them identify why the packet triggered a rule. The following table lists some of the external systems that can provide data on known exploits and attacks.

Table 36-6 External Attack Identification Systems

System ID

Description

Example ID

bugtraq

Bugtraq page

8550

cve

Common Vulnerabilities and Exposure page

CAN-2003-0702

mcafee

McAfee page

98574

url

Website reference

www.example.com?exploit=14

msb

Microsoft security bulletin

MS11-082

nessus

Nessus page

10039

secure-url

Secure Website Reference (https://...)

intranet/exploits/exploit=14

Note that you can use secure-url with any secure website.

To specify a reference using the rule editor, select reference from the Detection Options list, and enter a value in the corresponding field as follows:

id_system,id

where id_system is the system being used as a prefix, and id is the Bugtraq ID, CVE number, Arachnids ID, or URL (without http://).

For example, to specify the authentication bypass vulnerability on Microsoft Commerce Server 2002 servers documented in Bugtraq ID 17134, enter the following in the reference field:

bugtraq,17134

Note the following when adding references to a rule:

- Do not use a space after the comma.

- Do not use uppercase letters in the system ID.

See Constructing a Rule for more information about using the rule editor to build rules.

Searching for Content Matches

License: Protection

Use the content keyword or the protected_content keyword to specify content that you want to detect in a packet. See the following sections for more information:

- Using the content Keyword

- Using the protected_content Keyword

- Configuring Content Matching

Using the content Keyword

When you use the content keyword, the rules engine searches the packet payload or stream for that string. For example, if you enter /bin/sh as the value for one of the content keywords, the rules engine searches the packet payload for the string /bin/sh.

Match content using either an ASCII string, hexadecimal content (binary byte code), or a combination of both. Surround hexadecimal content with pipe characters (|) in the keyword value. For example, you can mix hexadecimal content and ASCII content using something that looks like |90C8 C0FF FFFF|/bin/sh.

You can specify multiple content matches in a single rule. To do this, use additional instances of the content keyword. For each content match, you can indicate that content matches must be found in the packet payload or stream for the rule to trigger.

Using the protected_content Keyword

The protected_content keyword allows you to encode your search content string before configuring the rule argument. The original rule author uses a hash function (SHA-512, SHA-256, or MD5) to encode the string before configuring the keyword.

When you use the protected_content keyword instead of the content keyword, there is no change to how the rules engine searches the packet payload or stream for that string and most of the keyword options function as expected. The following table summarizes the exceptions, where the protected_content keyword options differ from the content keyword options.

Table 36-7 protected_content Option Exceptions

Option

Description

Hash Type

New option for the protected_content rule keyword. For more information, see Hash Type.

Case Insensitive

Not supported

Within

Not supported

Depth

Not supported

Length

New option for the protected_content rule keyword. For more information, see Length.

Use Fast Pattern Matcher

Not supported

Fast Pattern Matcher Only

Not supported

Fast Pattern Matcher Offset and Length

Not supported

Cisco recommends that you include at least one content keyword in rules that include a protected_content keyword to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. Position the content keyword before the protected_content keyword in the rule. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument.

Configuring Content Matching

You should almost always follow a content or protected_content keyword by modifiers that indicate where the content should be searched for, whether the search is case sensitive, and other options. See Constraining Content Matches for more information about modifiers to the content and protected_content keywords.

Note that all content matches must be true for the rule to trigger an event, that is, each content match has an AND relationship with the others.

Note also that, in an inline deployment, you can set up rules that match malicious content and then replace it with your own text string of equal length. See Replacing Content in Inline Deployments for more information.

To enter content to be matched:

Access: Admin/Intrusion Admin

Step 1 In the content field, type the content you want to find (for example, |90C8 C0FF FFFF|/bin/sh).

If you want to search for any content that is not the specified content, select the Not check box.

Caution You may invalidate your intrusion policy if you create a rule that includes only one content keyword and that keyword has the Not option selected. For more information, see Not.

Step 2 Optionally, add additional keywords that modify the content keyword or add constraints for the keyword. For more information on other keywords, see Understanding Keywords and Arguments in Rules.

For more information on constraining the content keyword, see Constraining Content Matches.

Step 3 Continue with creating or editing the rule.

See Writing New Rules or Modifying Existing Rules for more information.

To enter protected content to be matched:

Access: Admin/Intrusion Admin

Step 1 Using a SHA-512, SHA-256, or MD5 hash generator, encode the content you want to find (for example, run the string Sample1 through a SHA-512 hash generator).

The generator outputs a hash for your string.

Step 2 In the protected_content field, type the hash you generated in step 1 (for example, B20AABAF59605118593404BD42FE69BD8D6506EE7F1A71CE6BB470B1DF848C814BC5DBEC2081999F15691A71FAECA5FBA4A3F8B8AB56B7F04585DA6D73E5DD15).

If you want to search for any content that is not the specified content, select the Not check box.

Caution You may invalidate your intrusion policy if you create a rule that includes only one protected_content keyword and that keyword has the Not option selected. For more information, see Not.

Step 3 From the Hash Type drop-down list, select the hash function you used in step 1 (for example, SHA-512). Note that the number of bits in the hash entered in step 2 must match the hash type or the system does not save the rule. For more information, see Hash Type.

Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function.

Step 4 Type a value in the required Length field. The value must correspond with the length of the original, unhashed string you want to find (for example, the string Sample1 from step 2 has the length 7).

For more information, see Length.

Step 5 Type a value in either the Offset or Distance field. You cannot mix the Offset and Distance options within a single keyword configuration.

For more information, see Using Search Location Options in the protected_content Keyword.

Step 6 Optionally, add additional constraining options that modify the protected_content keyword.

For more information, see Constraining Content Matches.

Step 7 Optionally, add additional keywords that modify the protected_content keyword.

For more information, see Understanding Keywords and Arguments in Rules.

Step 8 Continue with creating or editing the rule.

See Writing New Rules or Modifying Existing Rules for more information.

Constraining Content Matches

License: Protection

You can constrain the location and case-sensitivity of content searches with parameters that modify the content or protected_content keyword. Configure options that modify the content or protected_content keyword to specify the content for which you want to search.

For more information, see the following sections:

- Case Insensitive

- Hash Type

- Raw Data

- Not

- Search Location Options

- HTTP Content Options

- Use Fast Pattern Matcher

Case Insensitive

License: Protection

Note This option is not supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

You can instruct the rules engine to ignore case when searching for content matches in ASCII strings. To make your search case-insensitive, check Case Insensitive when specifying a content search.

To specify Case Insensitive when doing a content search:

Access: Admin/Intrusion Admin

Step 1 Select Case Insensitive for the content keyword you are adding.

Step 2 Continue with creating or editing the rule.

See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

Hash Type

License: Protection

Note This option is only configurable with the protected_content keyword. For more information, see Using the protected_content Keyword.

Use the Hash Type drop-down to identify the hash function you used to encode your search string. The system supports SHA-512, SHA-256, and MD5 hashing for protected_content search strings. If the length of your hashed content does not match the selected hash type, the system does not save the rule.

The system automatically selects the Cisco-set default value. When Default is selected, no specific hash function is written into the rule and the system assumes SHA-512 for the hash function.

To specify a hash function when doing a protected content search:

Step 1 From the Hash Type drop-down list, select Default, SHA-512, SHA-256, or MD5 as the hash for the protected_content keyword you are adding.

Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function. For more information, see Hash Type.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Raw Data

License: Protection

The Raw Data option instructs the rules engine to analyze the original packet payload before analyzing the normalized payload data (decoded by a network analysis policy) and does not use an argument value. You can use this keyword when analyzing telnet traffic to check the telnet negotiation options in the payload before normalization.

You cannot use the Raw Data option together in the same content or protected_content keyword with any HTTP content option. See HTTP Content Options for more information.

Tip You can configure the HTTP Inspect preprocessor Client Flow Depth and Server Flow Depth options to determine whether raw data is inspected in HTTP traffic, and how much raw data is inspected. For more information, see Selecting Server-Level HTTP Normalization Options.

To analyze raw data:

Access: Admin/Intrusion Admin

Step 1 Select the Raw Data check box for the content or protected_content keyword you are adding.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Not

License: Protection

Select the Not option to search for content that does not match the specified content. If you create a rule that includes a content or protected_content keyword with the Not option selected, you must also include in the rule at least one other content or protected_content keyword without the Not option selected.

Caution Do not create a rule that includes only one content or protected_content keyword if that keyword has the Not option selected. You may invalidate your intrusion policy.

For example, SMTP rule 1:2541:9 includes three content keywords, one of which has the Not option selected. A custom rule based on this rule would be invalid if you removed all of the content keywords except the one with the Not option selected. Adding such a rule to your intrusion policy could invalidate the policy.

To search for content that does not match the specified content:

Access: Admin/Intrusion Admin

Step 1 Select the Not check box for the content or protected_content keyword you are adding.

Tip You cannot select the Not check box and the Use Fast Pattern Matcher check box with the same content keyword.

Step 2 Include in the rule at least one other content or protected_content keyword that does not have the Not option selected.

Step 3 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Search Location Options

License: Protection

You can use search location options to specify where to begin searching for the specified content and how far to continue searching. For details about each option, see:

- Depth

- Distance

- Length

- Offset

- Within

For information about how to use search location options within the content or protected_content keyword, see:

- Using Search Location Options in the content Keyword

- Using Search Location Options in the protected_content Keyword

Depth

Note This option is only supported when configuring the content keyword. For more information, see Using the content Keyword.

Specifies the maximum content search depth, in bytes, from the beginning of the offset value, or if no offset is configured, from the beginning of the packet payload.

For example, in a rule with a content value of cgi-bin/phf, and offset value of 3, and a depth value of 22, the rule starts searching for a match to the cgi-bin/phf string at byte 3, and stops after processing 22 bytes (byte 25) in packets that meet the parameters specified by the rule header.

You must specify a value that is greater than or equal to the length of the specified content, up to a maximum of 65535 bytes. You cannot specify a value of 0.

The default depth is to search to the end of the packet.

Distance

Instructs the rules engine to identify subsequent content matches that occur a specified number of bytes after the previous successful content match.

Because the distance counter starts at byte 0, specify one less than the number of bytes you want to move forward from the last successful content match. For example, if you specify 4, the search begins at the fifth byte.

You can specify a value of -65535 to 65535 bytes. If you specify a negative Distance value, the byte you start searching on may fall outside the beginning of a packet. Any calculations will take into account the bytes outside the packet, even though the search actually starts on the first byte in the packet. For example, if the current location in the packet is the fifth byte, and the next content rule option specifies a Distance value of -10 and a Within value of 20, the search starts at the beginning of the payload and the Within option is adjusted to 15.

The default distance is 0, meaning the current location in the packet subsequent to the last content match.

Length

Note This option is only supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

The Length protected_content keyword option indicates the length, in bytes, of the unhashed search string.

For example, if you used the content Sample1 to generate a secure hash, use 7 for the Length value. You must enter a value in this field.

Offset

Specifies in bytes where in the packet payload to start searching for content relative to the beginning of the packet payload. You can specify a value of-65535 to 65535 bytes.

Because the offset counter starts at byte 0, specify one less than the number of bytes you want to move forward from the beginning of the packet payload. For example, if you specify 7, the search begins at the eighth byte.

The default offset is 0, meaning the beginning of the packet.

Within

Note This option is only supported when configuring the content keyword. For more information, see Using the content Keyword.

The Within option indicates that, to trigger the rule, the next content match must occur within the specified number of bytes after the end of the last successful content match. For example, if you specify a Within value of 8, the next content match must occur within the next eight bytes of the packet payload or it does not meet the criteria that triggers the rule.

You can specify a value that is greater than or equal to the length of the specified content, up to a maximum of 65535 bytes.

The default for Within is to search to the end of the packet.

Using Search Location Options in the content Keyword

You can use either of two content location pairs to specify where to begin searching for the specified content and how far to continue searching, as follows:

- Use Offset and Depth together to search relative to the beginning of the packet payload.

- Use Distance and Within together to search relative to the current search location.

When you specify only one of a pair, the default for the other option in the pair is assumed.

You cannot mix the Offset and Depth options with the Distance and Within options. For example, you cannot pair Offset and Within. You can use any number of location options in a rule.

When no location is specified, the defaults for Offset and Depth are assumed; that is, the content search starts at the beginning of the packet payload and continues to the end of the packet.

You can also use an existing byte_extract variable to specify the value for a location option. See Reading Packet Data into Keyword Arguments for more information.

To specify a search location value in a content keyword via the web interface:

Access: Admin/Intrusion Admin

Step 1 Type the value in the field for the content keyword you are adding. You have the following choices:

- Offset

- Depth

- Distance

- Within

You can use any number of location options in a rule.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

Using Search Location Options in the protected_content Keyword

Use the required Length protected_content location option in combination with either the Offset or Distance location option to specify where to begin searching for the specified content and how far to continue searching, as follows:

- Use Length and Offset together to search for the protected string relative to the beginning of the packet payload.

- Use Length and Distance together to search for the protected string relative to the current search location.

Tip You cannot mix the Offset and Distance options within a single keyword configuration, but you can use any number of location options in a rule.

When no location is specified, the defaults are assumed; that is, the content search starts at the beginning of the packet payload and continues to the end of the packet.

You can also use an existing byte_extract variable to specify the value for a location option. For more information, see Reading Packet Data into Keyword Arguments.

To specify a search location value in a protected_content keyword via the web interface:

Access: Admin/Intrusion Admin

Step 1 Type the value in the field for the protected_content keyword you are adding. You have the following choices:

- Length (required)

- Offset

- Distance

You cannot mix the Offset and Distance options within a single protected_content keyword, but you can use any number of location options in a rule.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

HTTP Content Options

License: Protection

HTTP content or protected_content keyword options let you specify where to search for content matches within an HTTP message decoded by the HTTP Inspect preprocessor.

Two options search status fields in HTTP responses:

- HTTP Status Code

- HTTP Status Message

Note that although the rules engine searches the raw, unnormalized status fields, these options are listed here separately to simplify explanation below of the restrictions to consider when combining other raw HTTP fields and normalized HTTP fields.

Five options search normalized fields in HTTP requests, responses, or both, as appropriate (see HTTP Content Options for more information):

- HTTP URI

- HTTP Method

- HTTP Header

- HTTP Cookie

- HTTP Client Body

Three options search raw (unnormalized) non-status fields in HTTP requests, responses, or both, as appropriate (see HTTP Content Options for more information):

- HTTP Raw URI

- HTTP Raw Header

- HTTP Raw Cookie

Use the following guidelines when selecting HTTP content options:

- HTTP content options apply only to TCP traffic.

- To avoid a negative impact on performance, select only those parts of the message where the specified content might appear.

For example, when traffic is likely to include large cookies such as those in shopping cart messages, you might search for the specified content in the HTTP header but not in HTTP cookies.

- To take advantage of HTTP Inspect preprocessor normalization, and to improve performance, any HTTP-related rule you create should at a minimum include at least one content or protected_content keyword with an HTTP URI , HTTP Method , HTTP Header , or HTTP Client Body option selected.

- You cannot use the replace keyword in conjunction with HTTP content or protected_content keyword options.

You can specify a single normalized HTTP option or status field, or use normalized HTTP options and status fields in any combination to target a content area to match. However, note the following restrictions when using HTTP field options:

- You cannot use the Raw Data option together in the same content or protected_content keyword with any HTTP option.

- You cannot use a raw HTTP field option ( HTTP Raw URI , HTTP Raw Header , or HTTP Raw Cookie ) together in the same content or protected_content keyword with its normalized counterpart ( HTTP URI , HTTP Header , or HTTP Cookie , respectively).

- You cannot select Use Fast Pattern Matcher in combination with one or more of the following HTTP field options:

HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP Status Message, or HTTP Status Code

However, you can include the options above in a content or protected_content keyword that also uses the fast pattern matcher to search one of the following normalized fields:

HTTP URI, HTTP Header, or HTTP Client Body

For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher is applied only to the HTTP header, not to the HTTP cookie.

- When you combine restricted and unrestricted options, the fast pattern matcher searches only the unrestricted fields you specify to test whether to pass the rule to the rule editor for complete evaluation, including evaluation of the restricted fields. See Use Fast Pattern Matcher for more information.

The above restrictions are reflected in the description of each option in the following list describing the HTTP content and protected_content keyword options.

HTTP URI

Select this option to search for content matches in the normalized request URI field.

Note that you cannot use this option in combination with the pcre keyword HTTP URI (U) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a content match.

HTTP Raw URI

Select this option to search for content matches in the normalized request URI field.

Note that you cannot use this option in combination with the pcre keyword HTTP URI (U) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a content match.

HTTP Method

Select this option to search for content matches in the request method field, which identifies the action such as GET and POST to take on the resource identified in the URI.

HTTP Header

Select this option to search for content matches in the normalized header field, except for cookies, in HTTP requests; also in responses when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled.

Note that you cannot use this option in combination with the pcre keyword HTTP header (H) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

HTTP Raw Header

Select this option to search for content matches in the raw header field, except for cookies, in HTTP requests; also in responses when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled.

Note that you cannot use this option in combination with the pcre keyword HTTP raw header (D) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

HTTP Cookie

Select this option to search for content matches in any cookie identified in a normalized HTTP client request header; also in response set-cookie data when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled. Note that the system treats cookies included in the message body as body content.

You must enable the HTTP Inspect preprocessor Inspect HTTP Cookies option to search only the cookie for a match; otherwise, the rules engine searches the entire header, including the cookie. See Selecting Server-Level HTTP Normalization Options for more information.

Note the following:

– You cannot use this option in combination with the pcre keyword HTTP cookie (C) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

– The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

HTTP Raw Cookie

Select this option to search for content matches in any cookie identified in a raw HTTP client request header; also in response set-cookie data when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled; note that the system treats cookies included in the message body as body content.

You must enable the HTTP Inspect preprocessor Inspect HTTP Cookies option to search only the cookie for a match; otherwise, the rules engine searches the entire header, including the cookie. See Selecting Server-Level HTTP Normalization Options for more information.

Note the following:

– You cannot use this option in combination with the pcre keyword HTTP raw cookie (K) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

– The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

HTTP Client Body

Select this option to search for content matches in the message body in an HTTP client request.

Note that for this option to function, you must specify a value of 0 to 65535 for the HTTP Inspect preprocessor HTTP Client Body Extraction Depth option. See Selecting Server-Level HTTP Normalization Options for more information.

HTTP Status Code

Select this option to search for content matches in the 3-digit status code in an HTTP response.

You must enable the HTTP Inspect preprocessor Inspect HTTP Responses option for this option to return a match. See Selecting Server-Level HTTP Normalization Options for more information.

HTTP Status Message

Select this option to search for content matches in the textual description that accompanies the status code in an HTTP response.

You must enable the HTTP Inspect preprocessor Inspect HTTP Responses option for this option to return a match. See Selecting Server-Level HTTP Normalization Options for more information.

To specify an HTTP content option when doing a content search of TCP traffic:

Access: Admin/Intrusion Admin

Step 1 Optionally, to take advantage of HTTP Inspect preprocessor normalization, and to improve performance, select:

- at least one from among the HTTP URI , HTTP Raw URI , HTTP Method , HTTP Header , HTTP Raw Header , or HTTP Client Body options for the content or protected_content keyword you are adding

- the HTTP Cookie or HTTP Raw Cookie option

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Use Fast Pattern Matcher

License: Protection

Note These options are not supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

The fast pattern matcher quickly determines which rules to evaluate before passing a packet to the rules engine. This initial determination improves performance by significantly reducing the number of rules used in packet evaluation.

By default, the fast pattern matcher searches packets for the longest content specified in a rule; this is to eliminate as much as possible needless evaluation of a rule. Consider the following example rule fragment:

alert tcp any any -> any 80 (msg:"Exploit"; content:"GET";

http_method; nocase; content:"/exploit.cgi"; http_uri;

nocase;)

Almost all HTTP client requests contain the content GET, but few will contain the content /exploit.cgi. Using GET as the fast pattern content would cause the rules engine to evaluate this rule in most cases and would rarely result in a match. However, most client GET requests would not be evaluated using /exploit.cgi, thus increasing performance.

The rules engine evaluates the packet against the rule only when the fast pattern matcher detects the specified content. For example, if one content keyword in a rule specifies the content short, another specifies longer, and a third specifies longest, the fast pattern matcher will use the content longest and the rule will be evaluated only if the rules engine finds longest in the payload.

You can use the Use Fast Pattern Matcher option to specify a shorter search pattern for the fast pattern matcher to use. Ideally, the pattern you specify is less likely to be found in the packet than the longest pattern and, therefore, more specifically identifies the targeted exploit.

Note the following restrictions when selecting Use Fast Pattern Matcher and other options in the same content keyword:

- You can specify Use Fast Pattern Matcher only one time per rule.

- You cannot use Distance , Within , Offset , or Depth when you select Use Fast Pattern Matcher in combination with Not .

- You cannot select Use Fast Pattern Matcher in combination with any of the following HTTP field options:

HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP Status Message, or HTTP Status Code

However, you can include the options above in a content keyword that also uses the fast pattern matcher to search one of the following normalized fields:

HTTP URI, HTTP Header, or HTTP Client Body

For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher is applied only to the HTTP header, not to the HTTP cookie.

Note that you cannot use a raw HTTP field option (HTTP Raw URI, HTTP Raw Header, or HTTP Raw Cookie) together in the same content keyword with its normalized counterpart (HTTP URI, HTTP Header, or HTTP Cookie, respectively). See HTTP Content Options for more information.

When you combine restricted and unrestricted options, the fast pattern matcher searches only the unrestricted fields you specify to test whether to pass the packet to the rules engine for complete evaluation, including evaluation of the restricted fields.

- Optionally, when you select Use Fast Pattern Matcher you can also select Fast Pattern Matcher Only or Fast Pattern Matcher Offset and Length , but not both.

- You cannot use the fast pattern matcher when inspecting Base64 data; see Decoding and Inspecting Base64 Data for more information.

Using the Fast Pattern Matcher Only

The Fast Pattern Matcher Only option allows you to use the content keyword only as a fast pattern matcher option and not as a rule option. You can use this option to conserve resources when rules engine evaluation of the specified content is not necessary. For example, consider a case where a rule requires only that the content 12345 be anywhere in the payload. When the fast pattern matcher detects the pattern, the packet can be evaluated against additional keywords in the rule. There is no need for the rules engine to reevaluate the packet to determine if it includes the pattern 12345.

You would not use this option when the rule contains other conditions relative to the specified content. For example, you would not use this option to search for the content 1234 if another rule condition sought to determine if abcd occurs before 1234. In this case, the rules engine could not determine the relative location because specifying Fast Pattern Matcher Only instructs the rules engine not to search for the specified content.

Note the following conditions when using this option:

- The specified content is location-independent; that is, it may occur anywhere in the payload; thus, you cannot use positional options ( Distance , Within , Offset , Depth , or Fast Pattern Matcher Offset and Length ).

- You cannot use this option in combination with Not .

- You cannot use this option in combination with Fast Pattern Matcher Offset and Length .

- The specified content will be treated as case-insensitive, because all patterns are inserted into the fast pattern matcher in a case-insensitive manner; this is handled automatically, so it is not necessary to select Case Insensitive when you select this option.

- You should not immediately follow a content keyword that uses the Fast Pattern Matcher Only option with the following keywords, which set the search location relative to the current search location:

- isdataat

- pcre

- content when Distance or Within is selected

- content when HTTP URI is selected

- asn1

- byte_jump

- byte_test

- byte_extract

- base64_decode

Specifying Fast Pattern Matcher Offset and Length

The Fast Pattern Matcher Offset and Length option allows you to specify a portion of the content to search. This can reduce memory consumption in cases where the pattern is very long and only a portion of the pattern is sufficient to identify the rule as a likely match. When a rule is selected by the fast pattern matcher, the entire pattern is evaluated against the rule.

You determine the portion for the fast pattern matcher to use by specifying in bytes where to begin the search (offset) and how far into the content (length) to search, using the syntax:

offset,length

For example, for the content:

1234567

if you specify the number of offset and length bytes as:

1,5

the fast pattern matcher searches only for the content 23456.

Note that you cannot use this option together with Fast Pattern Matcher Only.

To specify the content searched for by the fast pattern matcher:

Access: Admin/Intrusion Admin

Step 1 Select Use Fast Pattern Matcher for the content keyword you are adding.

Step 2 Optionally, select Fast Pattern Matcher Only to determine without rules engine evaluation if the specified pattern exists in the packet.

Evaluation proceeds only if the fast pattern matcher detects the specified content.

Step 3 Optionally, specify in Fast Pattern Matcher Offset and Length a portion of the pattern to search for the content using the syntax:

offset,length

where offset specifies how many bytes from the beginning of the content to begin the search, and length specifies the number of bytes to continue.

Step 4 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Using PCRE, Writing New Rules, or Modifying Existing Rules for more information.

Replacing Content in Inline Deployments

License: Protection

You can use the replace keyword in an inline deployment to replace specified content.

Note You cannot use the replace keyword to replace content in SSL traffic detected by the Cisco SSL Appliance. The original encrypted data, not the replacement data, will be transmitted. See the Cisco SSL Appliance Administration and Deployment Guide for more information.

To use the replace keyword, construct a custom standard text rule that uses the content keyword to look for a specific string. Then use the replace keyword to specify a string to replace the content. The replace value and content value must be the same length.

Note You cannot use the replace keyword to replace hashed content in a protected_content keyword. For more information, see Using the protected_content Keyword.

Optionally, you can enclose the replacement string in quotation marks for backward compatibility with previous FireSIGHT System software versions. If you do not include quotation marks, they are added to the rule automatically so the rule is syntactically correct. To include a leading or trailing quotation mark as part of the replacement text, you must use a backslash to escape it, as shown in the following example:

"replacement text plus \"quotation\" marks""

A rule can contain multiple replace keywords, but only one per content keyword. Only the first instance of the content found by the rule is replaced.

The following explain example uses of the replace keyword:

- If the system detects an incoming packet that contains an exploit, you can replace the malicious string with a harmless one. Sometimes this technique is more successful than simply dropping the offending packet. In some attack scenarios, the attacker simply resends the dropped packet until it bypasses your network defenses or floods your network. By substituting one string for another rather than dropping the packet, you may trick the attacker into believing that the attack was launched against a target that was not vulnerable.

- If you are concerned about reconnaissance attacks that try to learn whether you are running a vulnerable version of, for example, a web server, then you can detect the outgoing packet and replace the banner with your own text.

Note Make sure that you set the rule state to Generate Events in the inline intrusion policy where you want to use the replace rule; setting the rule to Drop and Generate events would cause the packet to drop, which would prevent replacing the content.

As part of the string replacement process, the system automatically updates the packet checksums so that the destination host can receive the packet without error.

Note that you cannot use the replace keyword in combination with HTTP request message content keyword options. See Searching for Content Matches and HTTP Content Options for more information.

To replace content in an inline deployment:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select content in the drop-down list and click Add Option.

The content keyword appears.

Step 2 Specify the content you want to detect in the content field and, optionally, select any applicable arguments. Note that you cannot use the HTTP request message content keyword options with the replace keyword.

Step 3 Select replace in the drop-down list and click Add Option.

The replace keyword appears beneath the content keyword.

Step 4 Specify the replacement string for the specified content in the replace: field.

Using Byte_Jump and Byte_Test

License: Protection

You can use byte_jump and byte_test to calculate where in a packet the rules engine should begin testing for a data match, and which bytes it should evaluate.

You can also use the byte_jump and byte_test DCE/RPC argument to tailor either keyword for traffic processed by the DCE/RPC preprocessor. When you use the DCE/RPC argument, you can also use byte_jump and byte_test in conjunction with other specific DCE/RPC keywords. See Decoding DCE/RPC Traffic and DCE/RPC Keywords for more information.

See the following sections for more information:

- byte_jump

- byte_test

byte_jump

License: Protection

The byte_jump keyword calculates the number of bytes defined in a specified byte segment, and then skips that number of bytes within the packet, either forward from the end of the specified byte segment, or from the beginning of the packet payload, depending on the options you specify. This is useful in packets where a specific segment of bytes describe the number of bytes included in variable data within the packet.

Table 36-8 Required byte_jump Arguments

Argument

Description

Bytes

The number of bytes to calculate from the packet.

Offset

The number of bytes into the payload to start processing. The offset counter starts at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you want to jump forward from the beginning of the packet payload or the last successful content match.

You can also use an existing byte_extract variable to specify the value for this argument. See Reading Packet Data into Keyword Arguments for more information.

Table 36-9 Additional Optional byte_jump Arguments

Argument

Description

Relative

Makes the offset relative to the last pattern found in the last successful content match.

Align

Rounds the number of converted bytes up to the next 32-bit boundary.

Multiplier

Indicates the value by which the rules engine should multiply the byte_jump value obtained from the packet to get the final byte_jump value.

That is, instead of skipping the number of bytes defined in a specified byte segment, the rules engine skips that number of bytes multiplied by an integer you specify with the Multiplier argument.

Post Jump Offset

The number of bytes -63535 through 63535 to skip forward or backward after applying other byte_jump arguments. A positive value skips forward and a negative value skips backward. Leave the field blank or enter 0 to disable.

See the DCE/RPC argument in the Endianness Arguments table for byte_jump arguments that do not apply when you select the DCE/RPC argument.

From Beginning

Indicates that the rules engine should skip the specified number of bytes in the payload starting from the beginning of the packet payload, rather than from the end of the byte segment that specifies the number of bytes to skip.

You can specify only one of DCE/RPC, Endian, or Number Type.

Table 36-10 Endianness Arguments

Argument

Description

Big Endian

Processes data in big endian byte order, which is the default network byte order.

Little Endian

Processes data in little endian byte order.

DCE/RPC

Specifies a byte_jump keyword for traffic processed by the DCE/RPC preprocessor. See Decoding DCE/RPC Traffic for more information.

The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type, Endian, and From Beginning arguments do not apply.

When you enable this argument, you can also use byte_jump in conjunction with other specific DCE/RPC keywords. See DCE/RPC Keywords for more information.

Define how the system views string data in a packet by using one of the arguments in the following table.

Table 36-11 Number Type Arguments

Argument

Description

Hexadecimal String

Represents converted string data in hexadecimal format.

Decimal String

Represents converted string data in decimal format.

Octal String

Represents converted string data in octal format.

For example, if the values you set for byte_jump are as follows:

- Bytes = 4

- Offset = 12

- Relative enabled

- Align enabled

the rules engine calculates the number described in the four bytes that appear 13 bytes after the last successful content match, and skips ahead that number of bytes in the packet. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31. Because align is specified (which instructs the engine to move to the next 32-bit boundary), the rules engine skips ahead 32 bytes in the packet.

Alternately, if the values you set for byte_jump are as follows:

- Bytes = 4

- Offset = 12

- From Beginning enabled

- Multiplier = 2

the rules engine calculates the number described in the four bytes that appear 13 bytes after the beginning of the packet. Then, the engine multiplies that number by two to obtain the total number of bytes to skip. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31, then multiply it by two to get 62. Because From Beginning is enabled, the rules engine skips the first 63 bytes in the packet.

To use byte_jump:

Access: Admin/Intrusion Admin

Step 1 Select byte_jump in the drop-down list and click Add Option.

The byte_jump section appears beneath the last keyword you selected.

byte_test

License: Protection

The byte_test keyword calculates the number of bytes in a specified byte segment and compares them, according to the operator and value you specify.

Table 36-12 Required byte_test Arguments

Argument

Description

Bytes

The number of bytes to calculate from the packet. You can specify 1 to 10 bytes.

Operator and Value

Compares the specified value to <, >, =, !, &, ^, !>, !<, !=, !&, or !^.

For example, if you specify !1024, byte_test would convert the specified number, and if it did not equal 1024, it would generate an event (if all other keyword parameters matched).

Note that ! and != are equivalent.

You can also use an existing byte_extract variable to specify the value for this argument. See Reading Packet Data into Keyword Arguments for more information.

Offset

The number of bytes into the payload to start processing. The offset counter starts at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you want to count forward from the beginning of the packet payload or the last successful content match.

You can also use an existing byte_extract variable to specify the value for this argument. See Reading Packet Data into Keyword Arguments for more information.

You can further define how the system uses byte_test arguments with the arguments described in the following table.

Table 36-13 Additional Optional byte_test Arguments

Argument

Description

Relative

Makes the offset relative to the last successful pattern match.

Align

Rounds the number of converted bytes up to the next 32-bit boundary.

You can specify only one of DCE/RPC, Endian, or Number Type.

Table 36-14 Endianness byte_test Arguments

Argument

Description

Big Endian

Processes data in big endian byte order, which is the default network byte order.

Little Endian

Processes data in little endian byte order.

DCE/RPC

Specifies a byte_test keyword for traffic processed by the DCE/RPC preprocessor. See Decoding DCE/RPC Traffic for more information.

The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian argument do not apply.

When you enable this argument, you can also use byte_test in conjunction with other specific DCE/RPC keywords. See DCE/RPC Keywords for more information.

You can define how the system views string data in a packet by using one of the arguments in the following table.

Table 36-15 Number Type byte-test Arguments

Argument

Description

Hexadecimal String

Represents converted string data in hexadecimal format.

Decimal String

Represents converted string data in decimal format.

Octal String

Represents converted string data in octal format.

For example, if the value for byte_test is specified as the following:

- Bytes = 4

- Operator and Value > 128

- Offset = 8

- Relative enabled

the rules engine calculates the number described in the four bytes that appear 9 bytes away from (relative to) the last successful content match, and, if the calculated number is larger than 128 bytes, the rule is triggered.

To use byte_test:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select byte_test in the drop-down list and click Add Option.

The byte_test section appears beneath the last keyword you selected.

Searching for Content Using PCRE

License: Protection

The pcre keyword allows you to use Perl-compatible regular expressions (PCRE) to inspect packet payloads for specified content. You can use PCRE to avoid writing multiple rules to match slight variations of the same content.

Regular expressions are useful when searching for content that could be displayed in a variety of ways. The content may have different attributes that you want to account for in your attempt to locate it within a packet’s payload.

Note that the regular expression syntax used in intrusion rules is a subset of the full regular expression library and varies in some ways from the syntax used in commands in the full library. When adding a pcre keyword using the rule editor, enter the full value in the following format:

!/pcre/ ismxAEGRBUIPHDMCKSY

where:

- ! is an optional negation (use this if you want to match patterns that do not match the regular expression).

- / pcre / is a Perl-compatible regular expression.

- ismxAEGRBUIPHDMCKSY is any combination of modifier options.

Table 36-16 Escaped PCRE Characters

You must escape...

with a backslash...

or Hex code...

# (hash mark)

\#

\x23

; (semicolon)

\;

\x3B

| (vertical bar)

\|

\x7C

: (colon)

\:

\x3A

Tip Optionally, you can surround your Perl-compatible regular expression with quote characters, for example, pcre_expression or “pcre_expression“.The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The rule editor does not display quotation marks when you display a rule after saving it.

You can also use m?regex?, where ? is a delimiter other than /. You may want to use this in situations where you need to match a forward slash within a regular expression and do not want to escape it with a backslash. For example, you might use m?regex? ismxAEGRBUIPHDMCKSY where regex is your Perl-compatible regular expression and ismxAEGRBUIPHDMCKSY is any combination of modifier options. See Perl-Compatible Regular Expression Basics for more information about regular expression syntax.

The following sections provide more information about building valid values for the pcre keyword:

- Perl-Compatible Regular Expression Basics describes the common syntax used in Perl-compatible regular expressions.

- PCRE Modifier Options describes the options you can use to modify your regular expression.

- Example PCRE Keyword Values gives example usage of the pcre keyword in rules.

Perl-Compatible Regular Expression Basics

License: Protection

The pcre keyword accepts standard Perl-compatible regular expression (PCRE) syntax. The following sections describe that syntax.

Tip While this section describes the basic syntax you may use for PCRE, you may want to consult an online reference or book dedicated to Perl and PCRE for more advanced information.

Metacharacters

License: Protection

Metacharacters are literal characters that have special meaning within regular expressions. When you use them within a regular expression, you must “escape” them by preceding them with a backslash.

Table 36-17 PCRE Metacharacters

Metacharacter

Description

Example

.

Matches any character except newlines. If s is used as a modifying option, it also includes newline characters.

abc. matches abcd, abc1, abc#, and so on.

*

Matches zero or more occurrences of a character or expression.

abc* matches abc, abcc, abccc, abccccc, and so on.

?

Matches zero or one occurrence of a character or expression.

abc? matches abc.

+

Matches one or more occurrences of a character or expression.

abc+ matches abc, abcc, abccc, abccccc, and so on.

()

Groups expressions.

(abc)+ matches abc, abcabc, abcabcabc and so on.

{}

Specifies a limit for the number of matches for a character or expression. If you want to set a lower and upper limit, separate the lower limit and upper limit with a comma.

a{4,6} matches aaaa, aaaaa, or aaaaaa.

(ab){2} matches abab.

[]

Allows you to define character classes, and matches any character or combination of characters described in the set.

[abc123] matches a or b or c, and so on.

^

Matches content at the beginning of a string. Also used for negation, if used within a character class.

^in matches the “in” in info, but not in bin. [^a] matches anything that does not contain a.

$

Matches content at the end of a string.

ce$ matches the “ce” in announce, but not cent.

|

Indicates an OR expression.

(MAILTO|HELP) matches MAILTO or HELP.

\

Allows you to use metacharacters as actual characters and is also used to specify a predefined character class.

\. matches a period, \* matches an asterisk, \\ matches a backslash and so on. \d matches the numeric characters, \w matches alphanumeric characters, and so on. See Character Classes for more information about using character classes in PCRE.

Character Classes

License: Protection

Character classes include alphabetic characters, numeric characters, alphanumeric characters, and white space characters. While you can create your own character classes within brackets (see Metacharacters), you can use the predefined classes as shortcuts for different types of character types. When used without additional qualifiers, a character class matches a single digit or character.

Table 36-18 PCRE Character Classes

Character Class

Description

Character Class Definition

\d

Matches a numeric character (“digit”).

[0-9]

\D

Matches anything that is not an numeric character.

[^0-9]

\w

Matches an alphanumeric character (“word”).

[a-zA-Z0-9_]

\W

Matches anything that is not an alphanumeric character.

[^a-zA-Z0-9_]

\s

Matches white space characters, including spaces, carriage returns, tabs, newlines, and form feeds.

[ \r\t\n\f]

\S

Matches anything that is not a white space character.

[^ \r\t\n\f]

PCRE Modifier Options

License: Protection

You can use modifying options after you specify regular expression syntax in the pcre keyword’s value. These modifiers perform Perl, PCRE, and Snort-specific processing functions. Modifiers always appear at the end of the PCRE value, and appear in the following format:

/pcre/ismxAEGRBUIPHDMCKSY

where ismxAEGRBUPHMC can include any of the modifying options that appear in the following tables.

Tip Optionally, you can surround the regular expression and any modifying options with quotes, for example, “/pcre/ismxAEGRBUIPHDMCKSY”. The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The rule editor does not display quotation marks when you display a rule after saving it.

Table 36-19 Perl-Related Post Regular Expression Options

Option

Description

i

Makes the regular expression case-insensitive.

s

The dot character (.) describes all characters except the newline or \n character. You can use "s" as an option to override this and have the dot character match all characters, including the newline character.

m

By default, a string is treated as a single line of characters, and ^ and $ match the beginning and ending of a specific string. When you use "m" as an option, ^ and $ match content immediately before or after any newline character in the buffer, as well as at the beginning or end of the buffer.

x

Ignores white space data characters that may appear within the pattern, except when escaped (preceded by a backslash) or included inside a character class.

The following table describes the PCRE modifiers you can use after the regular expression.

Table 36-20 PCRE-Related Post Regular Expression Options

Option

Description

A

The pattern must match at the beginning of the string (same as using ^ in a regular expression).

E

Sets $ to match only at the end of the subject string. (Without E, $ also matches immediately before the final character if it is a newline, but not before any other newline characters).

G

By default, * + and ? are “greedy,” which means that if two or more matches are found, they will choose the longest match. Use the G character to change this so that these characters always choose the first match unless followed by a question mark character (?). For example, *? +? and ?? would be greedy in a construct using the G modifier, and any incidences of *, +, or ? without the additional question mark will not be greedy.

The following table describes the Snort-specific modifiers that you can use after the regular expression.

.

Table 36-21 Snort-Specific Post Regular Expression Modifiers

Option

Description

R

Searches for matching content relative to the end of the last match found by the rules engine.

B

Searches for the content within data before it is decoded by a preprocessor (this option is similar to using the Raw Data argument with the content or protected_content keyword).

U

Searches for the content within the URI of a normalized HTTP request message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the content or protected_content keyword HTTP URI option to search the same content. See HTTP Content Options for more information.
selected, either with or without an accompanying PCRE expression that uses the U option.

I

Searches for the content within the URI of a raw HTTP request message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the content or protected_content keyword HTTP Raw URI option to search the same content. See HTTP Content Options for more information.

P

Searches for the content within the body of a normalized HTTP request message decoded by the HTTP Inspect preprocessor. See the content and protected_content keyword HTTP Client Body option in HTTP Content Options for more information.

H

Searches for the content within the header, excluding cookies, of an HTTP request or response message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the content or protected_content keyword HTTP Header option to search the same content. See HTTP Content Options for more information.

D

Searches for the content within the header, excluding cookies, of a raw HTTP request or response message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the content or protected_content keyword HTTP Raw Header option to search the same content. See HTTP Content Options for more information.

M

Searches for the content within the method field of a normalized HTTP request message decoded by the HTTP Inspect preprocessor; the method field identifies the action such as GET, PUT, CONNECT, and so on to take on the resource identified in the URI. See the content and protected_content keyword HTTP Method option in HTTP Content Options for more information.

C

When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled, searches for the normalized content within any cookie in an HTTP request header, and also within any set-cookie in an HTTP response header when the preprocessor Inspect HTTP Responses option is enabled. When Inspect HTTP Cookies is not enabled, searches the entire header, including the cookie or set-cookie data.

Note the following:

- Cookies included in the message body are treated as body content.

- You cannot use this option in combination with the content or protected_content keyword HTTP Cookie option to search the same content. See HTTP Content Options for more information.

- The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

K

When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled, searches for the raw content within any cookie in an HTTP request header, and also within any set-cookie in an HTTP response header when the preprocessor Inspect HTTP Responses option is enabled. When Inspect HTTP Cookies is not enabled, searches the entire header, including the cookie or set-cookie data.

Note the following:

- Cookies included in the message body are treated as body content.

- You cannot use this option in combination with the content or protected_content keyword HTTP Raw Cookie option to search the same content. See HTTP Content Options for more information.

- The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

S

Searches the 3-digit status code in an HTTP response. See the content and protected_content keyword HTTP Status Code option in HTTP Content Options for more information.

Y

Searches the textual description that accompanies the status code in an HTTP response. See the content and protected_content keyword HTTP Status Message option in HTTP Content Options for more information.

Note Do not use the U option in combination with the R option. This could cause performance problems. Also, do not use the U option in combination with any other HTTP content option (I, P, H, D, M, C, K, S, or Y).

Example PCRE Keyword Values

License: Protection

The following examples show values that you could enter for pcre, with descriptions of what each example would match.

- /feedback[(\d{0,1})]?\.cgi/U

This example searches packet payload for feedback, followed by zero or one numeric character, followed by .cgi, and located only in URI data.

This example would match:

- feedback.cgi

- feedback1.cgi

- feedback2.cgi

- feedback3.cgi

This example would not match:

- feedbacka.cgi

- feedback11.cgi

- feedback21.cgi

- feedbackzb.cgi

- /^ez(\w{3,5})\.cgi/iU

This example searches packet payload for ez at the beginning of a string, followed by a word of 3 to 5 letters, followed by .cgi. The search is case-insensitive and only searches URI data.

This example would match:

- EZBoard.cgi

- ezman.cgi

- ezadmin.cgi

- EZAdmin.cgi

This example would not match:

- ezez.cgi

- fez.cgi

- abcezboard.cgi

- ezboardman.cgi

- /mail(file|seek)\.cgi/U

This example searches packet payload for mail, followed by either file or seek, in URI data.

This example would match:

- mailfile.cgi

- mailseek.cgi

This example would not match:

- MailFile.cgi

- mailfilefile.cgi

- m?http\\x3a\x2f\x2f.*(\n|\t)+?U

This example searches packet payload for URI content for a tab or newline character in an HTTP request, after any number of characters. This example uses m?regex? to avoid using http\:\/\/ in the expression. Note that the colon is preceded by a backslash.

This example would match:

- http://www.example.com?scriptvar=x&othervar=\n\..\..

- http://www.example.com?scriptvar=\t

This example would not match:

- ftp://ftp.example.com?scriptvar=&othervar=\n\..\..

- http://www.example.com?scriptvar=|/bin/sh -i|

- m?http\\x3a\x2f\x2f.*=\|.*\|+?sU

This example searches packet payload for a URL with any number of characters, including newlines, followed by an equal sign, and pipe characters that contain any number of characters or white space. This example uses m?regex? to avoid using http\:\/\/ in the expression.

This example would match:

- http://www.example.com?value=|/bin/sh/ -i|

- http://www.example.com?input=|cat /etc/passwd|

This example would not match:

- ftp://ftp.example.com?value=|/bin/sh/ -i|

- http://www.example.com?value=x&input?|cat /etc/passwd|

- /[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}/i

This example searches packet payload for any MAC address. Note that it escapes the colon characters with backslashes.

Adding Metadata to a Rule

License: Protection

You can use the metadata keyword to add descriptive information to a rule. You can use the information you add to organize or identify rules in ways that suit your needs, and to search for rules.

The system validates metadata based on the format:

key value

where key and value provide a combined description separated by a space. This is the format used by the Cisco VRT for adding metadata to rules provided by Cisco.

Alternatively, you can also use the format:

key=value

For example, you could use the key value format to identify rules by author and date, using a category and sub-category as follows:

author SnortGuru_20050406

You can use multiple metadata keywords in a rule. You can also use commas to separate multiple key value statements in a single metadata keyword, as seen in the following example:

author SnortGuru_20050406, revised_by SnortUser1_20050707,

revised_by SnortUser2_20061003, revised_by

SnortUser1_20070123

You are not limited to using a key value or key=value format; however, you should be aware of limitations resulting from validation based on these formats.

Avoiding Restricted Characters

License: Protection

Note the following character restrictions:

- Do not use a semicolon (;) or colon (:) in a metadata keyword.

- Be aware when using commas that the system interprets a comma as a separator for multiple key value or key = value statements. For example:

key value, key value, key value

- Be aware when using the equal to (=) character or space character that the system interprets these characters as separators between key and value . For example:

key value

key=value

All other characters are permitted.

Adding service Metadata

License: Protection

The rules engine applies active rules with service metadata that match the application protocol information for the host in a packet to analyze and process traffic. If it does not match, the system does not apply the rule to the traffic. If a host does not have application protocol information, or if the rule does not have service metadata, the system checks the port in the traffic against the port in the rule to determine whether to apply the rule to the traffic.

To match a rule with an identified application protocol, you must define the metadata keyword and a key value statement, with service as the key and an application for the value. For example, the following key value statement in a metadata keyword associates the rule with HTTP traffic:

service http

The following table describes the most common application values.

Note Contact Support for assistance in defining applications not in the table.

Table 36-22 service Values

Value

Description

dcerpc

Distributed Computing Environment/Remote Procedure Calls System

dns

Domain Name System

finger

Finger user information protocol

ftp

File Transfer Protocol

ftp-data

File Transfer Protocol (Data Channel)

http

Hypertext Transfer Protocol

imap

Internet Message Access Protocol

isakmp

Internet Security Association and Key Management Protocol

netbios-dgm

NETBIOS Datagram Service

netbios-ns

NETBIOS Name Service

netbios-ssn

NETBIOS Session Service

nntp

Network News Transfer Protocol

oracle

Oracle Net Services

pop2

Post Office Protocol, version 2

pop3

Post Office Protocol, version 3

smtp

Simple Mail Transfer Protocol

ssh

Secure Shell network protocol

telnet

Telnet network protocol

tftp

Trivial File Transfer Protocol

x11

X Window System

Avoiding Reserved Metadata

License: Protection

Avoid using the following words in a metadata keyword, either as a single argument or as the key in a key value statement; these are reserved for use by the VRT:

application

engine

impact_flag

os

policy

rule-type

rule-flushing

soid

Note Contact Support for assistance in adding restricted metadata to local rules that might not otherwise function as expected. See Importing Local Rule Files for more information.

Searching for Rules with Metadata

License: Protection

To search for rules that use the metadata keyword, select the metadata keyword on the rules Search page and, optionally, type any portion of the metadata. For example, you can type:

- author to display all rules where you have used author for key .

- author snortguru to display all rules where you have used author for key and SnortGuru for value .

- author s to display all rules where you have used author for key and any terms such as SnortGuru or SnortUser1 or SnortUser2 for value .

Tip When you search for both key and value, use the same connecting operator (equal to [=] or a space character) in searches that is used in the key value statement in the rule; searches return different results depending on whether you follow key with equal to (=) or a space character.

Note that regardless of the format you use to add metadata, the system interprets your metadata search term as all or part of a key value or key=value statement. For example, the following would be valid metadata that does not follow a key value or key=value format:

ab cd ef gh

However, the system would interpret each space in the example as a separator between a key and value. Thus, you could successfully locate a rule containing the example metadata using any of the following searches for juxtaposed and single terms:

cd ef

ef gh

ef

but you would not locate the rule using the following search, which the system would interpret as a single key value statement:

ab ef

For more information, see Searching for Rules.

Setting Impact Level 1

License: Protection

You can use the following reserved key value statement in a metadata keyword:

impact_flag red

This key value statement sets the impact flag to red (level 1) for a local rule you import or a custom rule you create using the rule editor.

Note that when the VRT includes the impact_flag red statement in a rule provided by Cisco, the VRT has determined that a packet triggering the rule indicates that the source or destination host is potentially compromised by a virus, trojan, or other piece of malicious software. See Using Impact Levels to Evaluate Events a for more information.

Inspecting IP Header Values

License: Protection

You can use keywords to identify possible attacks or security policy violations in the IP headers of packets. See the following sections for more information:

- Inspecting Fragments and Reserved Bits

- Inspecting the IP Header Identification Value

- Identifying Specified IP Options

- Identifying Specified IP Protocol Numbers

- Inspecting a Packet’s Type of Service

- Inspecting a Packet’s Time-To-Live Value

Inspecting Fragments and Reserved Bits

License: Protection

Table 36-23 Fragbits Argument Values

Argument

Description

R

Reserved bit

M

More Fragments bit

D

Don’t Fragment bit

To further refine a rule using the fragbits keyword, you can specify any operator described in the following table after the argument value in the rule.

Table 36-24 Fragbit Operators

Operator

Description

plus sign (+)

The packet must match against all specified bits.

asterisk (*)

The packet can match against any of the specified bits.

exclamation point (!)

The packet meets the criteria if none of the specified bits are set.

For example, to generate an event against packets that have the Reserved Bit set (and possibly any other bits), use R+ as the fragbits value.

Inspecting the IP Header Identification Value

License: Protection

The id keyword tests the IP header fragment identification field against the value you specify in the keyword’s argument. Some denial-of-service tools and scanners set this field to a specific number that is easy to detect. For example, in SID 630, which detects a Synscan portscan, the id value is set to 39426, the static value used as the ID number in packets transmitted by the scanner.

Note id argument values must be numeric.

Identifying Specified IP Options

License: Protection

The IPopts keyword allows you to search packets for specified IP header options. The following table lists the available argument values.

Table 36-25 IPoption Arguments

Argument

Description

rr

record route

eol

end of list

nop

no operation

ts

time stamp

sec

IP security option

lsrr

loose source routing

ssrr

strict source routing

satid

stream identifier

Analysts most frequently watch for strict and loose source routing because these options may be an indication of a spoofed source IP address.

Identifying Specified IP Protocol Numbers

License: Protection

The ip_proto keyword allows you to identify packets with the IP protocol specified as the keyword’s value. You can specify the IP protocols as a number, 0 through 255. You can find the complete list of protocol numbers at http://www.iana.org/assignments/protocol-numbers. You can combine these numbers with the following operators: <, >, or !. For example, to inspect traffic with any protocol that is not ICMP, use !1 as a value to the ip_proto keyword. You can also use the ip_proto keyword multiple times in a single rule; note, however, that the rules engine interprets multiple instances of the keyword as having a Boolean AND relationship. For example, if you create a rule containing ip_proto:!3; ip_proto:!6, the rule ignores traffic using the GGP protocol AND the TCP protocol.

Inspecting a Packet’s Type of Service

License: Protection

Some networks use the type of service (ToS) value to set precedence for packets traveling on that network. The tos keyword allows you to test the packet’s IP header ToS value against the value you specify as the keyword’s argument. Rules using the tos keyword will trigger on packets whose ToS is set to the specified value and that meet the rest of the criteria set forth in the rule.

Note Argument values for tos must be numeric.

The ToS field has been deprecated in the IP header protocol and replaced with the Differentiated Services Code Point (DSCP) field.

Inspecting a Packet’s Time-To-Live Value

License: Protection

A packet’s time-to-live (ttl) value indicates how many hops it can make before it is dropped. You can use the ttl keyword to test the packet’s IP header ttl value against the value, or range of values, you specify as the keyword’s argument. It may be helpful to set the ttl keyword parameter to a low value such as 0 or 1, as low time-to-live values are sometimes indicative of a traceroute or intrusion evasion attempt. (Note, though, that the appropriate value for this keyword depends on your managed device placement and network topology.) Use syntax as follows:

- Use an integer from 0 to 255 to set a specific value for the TTL value. You can also precede the value with an equal (=) sign (for example, you can specify 5 or =5 ).

- Use a hyphen ( - ) to specify a range of TTL values (for example, 0-2 specifies all values 0 through 2, -5 specifies all values 0 through 5, and 5- specifies all values 5 through 255).

- Use the greater than (>) sign to specify TTL values greater than a specific value (for example, >3 specifies all values greater than 3).

- Use the greater than and equal to signs (>=) to specify TTL values greater than or equal to a specific value (for example, >=3 specifies all values greater than or equal to 3).

- Use the less than (<) sign to specify TTL values less than a specific value (for example, <3 specifies all values less than 3).

- Use the less than and equal to signs (<=) to specify TTL values less than or equal to a specific value (for example, <=3 specifies all values less than or equal to 3).

Inspecting ICMP Header Values

License: Protection

The FireSIGHT System supports keywords that you can use to identify attacks and security policy violations in the headers of ICMP packets. Note, however, that predefined rules exist that detect most ICMP types and codes. Consider enabling an existing rule or creating a local rule based on an existing rule; you may be able to find a rule that meets your needs more quickly than if you build an ICMP rule from scratch.

See the following sections for more information about ICMP-specific keywords:

- Identifying Static ICMP ID and Sequence Values

- Inspecting the ICMP Message Type

- Inspecting the ICMP Message Code

Identifying Static ICMP ID and Sequence Values

License: Protection

The ICMP identification and sequence numbers help associate ICMP replies with ICMP requests. In normal traffic, these values are dynamically assigned to packets. Some covert channel and Distributed Denial of Server (DDoS) programs use static ICMP ID and sequence values. The following keywords allow you to identify ICMP packets with static values.

icmp_id

The icmp_id keyword inspects an ICMP echo request or reply packet's ICMP ID number. Use a numeric value that corresponds with the ICMP ID number as the argument for the icmp_id keyword.

icmp_seq

The icmp_seq keyword inspects an ICMP echo request or reply packet's ICMP sequence. Use a numeric value that corresponds with the ICMP sequence number as the argument for the icmp_seq keyword.

Inspecting the ICMP Message Type

License: Protection

Use the itype keyword to look for packets with specific ICMP message type values. You can specify either a valid ICMP type value (see http://www.iana.org/assignments/icmp-parameters or http://www.faqs.org/rfcs/rfc792.html for a full list of ICMP type numbers) or an invalid ICMP type value to test for different types of traffic. For example, attackers may set ICMP type values out of range to cause denial of service and flooding attacks.

You can specify a range for the itype argument value using less than (<) and greater than (>).

For example:

- <35

- >36

- 3<>55

Tip See http://www.iana.org/assignments/icmp-parameters or http://www.faqs.org/rfcs/rfc792.html for a full list of ICMP type numbers.

Inspecting the ICMP Message Code

License: Protection

ICMP messages sometimes include a code value that provides details when a destination is unreachable. (See the second section in http://www.iana.org/assignments/icmp-parameters for a full list of ICMP message codes correlated with the message types for which they can be used.)

You can use the icode keyword to identify packets with specific ICMP code values. You can choose to specify either a valid ICMP code value or an invalid ICMP code value to test for different types of traffic.

You can specify a range for the icode argument value using less than (<) and greater than (>).

For example:

- to find values less than 35, specify <35.

- to find values greater than 36, specify >36.

- to find values between 3 and 55, specify 3<>55.

Tip You can use the icode and itype keywords together to identify traffic that matches both. For example, to identify ICMP traffic that contains an ICMP Destination Unreachable code type with an ICMP Port Unreachable code type, specify an itype keyword with a value of 3 (for Destination Unreachable) and an icode keyword with a value of 3 (for Port Unreachable).

Inspecting TCP Header Values and Stream Size

License: Protection

The FireSIGHT System supports keywords that are designed to identify attacks attempted using TCP headers of packets and TCP stream size. See the following sections for more information about TCP-specific keywords:

- Inspecting the TCP Acknowledgment Value

- Inspecting TCP Flag Combinations

- Applying Rules to a TCP or UDP Client or Server Flow

- Identifying Static TCP Sequence Numbers

- Identifying TCP Windows of a Given Size

- Identifying TCP Streams of a Given Size

Inspecting the TCP Acknowledgment Value

License: Protection

You can use the ack keyword to compare a value against a packet’s TCP acknowledgment number. The rule triggers if a packet’s TCP acknowledgment number matches the value specified for the ack keyword.

Argument values for ack must be numeric.

Inspecting TCP Flag Combinations

License: Protection

You can use the flags keyword to specify any combination of TCP flags that, when set in an inspected packet, cause the rule to trigger.

Note In situations where you would traditionally use A+ as the value for flags, you should instead use the flow keyword with a value of established. Generally, you should use the flow keyword with a value of stateless when using flags to ensure that all combinations of flags are detected. See Applying Rules to a TCP or UDP Client or Server Flow for more information about the flow keyword.

Table 36-26 flag Arguments

Argument

TCP Flag

Ack

Acknowledges data.

Psh

Data should be sent in this packet.

Syn

A new connection.

Urg

Packet contains urgent data.

Fin

A closed connection.

Rst

An aborted connection.

CWR

An ECN congestion window has been reduced. This was formerly the R1 argument, which is still supported for backward compatibility.

ECE

ECN echo. This was formerly the R2 argument, which is still supported for backward compatibility.

Tip For more information on Explicit Congestion Notification (ECN), see the information provided at: http://www.faqs.org/rfcs/rfc3168.html.

Table 36-27 Operators Used with flags

Operator

Description

Example

all

The packet must contain all specified flags.

Select Urg and all to specify that a packet must contain the Urgent flag and may contain any other flags.

any

The packet can contain any of the specified flags.

Select Ack, Psh, and any to specify that either or both the Ack and Psh flags must be set to trigger the rule, and that other flags may also be set on a packet.

not

The packet must not contain the specified flag set.

Select Urg and not to specify that the Urgent flag is not set on packets that trigger this rule.

Applying Rules to a TCP or UDP Client or Server Flow

License: Protection

You can use the flow keyword to select packets for inspection by a rule based on session characteristics. The flow keyword allows you to specify the direction of the traffic flow to which a rule applies, applying rules to either the client flow or server flow. To specify how the flow keyword inspects your packets, you can set the direction of traffic you want analyzed, the state of packets inspected, and whether the packets are part of a rebuilt stream.

Stateful inspection of packets occurs when rules are processed. If you want a TCP rule to ignore stateless traffic (traffic without an established session context), you must add the flow keyword to the rule and select the Established argument for the keyword. If you want a UDP rule to ignore stateless traffic, you must add the flow keyword to the rule and select either the Established argument or a directional argument, or both. This causes the TCP or UDP rule to perform stateful inspection of a packet.

When you add a directional argument, the rules engine inspects only those packets that have an established state with a flow that matches the direction specified. For example, if you add the flow keyword with the established argument and the From Client argument to a rule that triggers when a TCP or UDP connection is detected, the rules engine only inspects packets that are sent from the client.

Tip For maximum performance, always include a flow keyword in a TCP rule or a UDP session rule.

To specify flow, select the flow keyword from the Detection Options list on the Create Rule page and click Add Option. Next, select the arguments from the list provided for each field.

The following table describes the stream-related arguments you can specify for the flow keyword:

Table 36-28 State-Related flow Arguments

Argument

Description

Established

Triggers on established connections.

Stateless

Triggers regardless of the state of the stream processor.

The following table describes the directional options you can specify for the flow keyword:

Table 36-29 flow Directional Arguments

Argument

Description

To Client

Triggers on server responses.

To Server

Triggers on client responses.

From Client

Triggers on client responses.

From Server

Triggers on server responses.

Notice that From Server and To Client perform the same function, as do To Server and From Client. These options exist to add context and readability to the rule. For example, if you create a rule designed to detect an attack from a server to a client, use From Server. But, if you create a rule designed to detect an attack from the client to the server, use From Client.

Table 36-30 Stream-Related flow Arguments

Argument

Description

Ignore Stream Traffic

Does not trigger on rebuilt stream packets.

Only Stream Traffic

Triggers only on rebuilt stream packets.

For example, you can use To Server, Established, Only Stream Traffic as the value for the flow keyword to detect traffic, traveling from a client to the server in an established session, that has been reassembled by the stream preprocessor.

Identifying Static TCP Sequence Numbers

License: Protection

The seq keyword allows you to specify a static sequence number value. Packets whose sequence number matches the specified argument trigger the rule containing the keyword. While this keyword is used rarely, it is helpful in identifying attacks and network scans that use generated packets with static sequence numbers.

Identifying TCP Windows of a Given Size

License: Protection

You can use the window keyword to specify the TCP window size you are interested in. A rule containing this keyword triggers whenever it encounters a packet with the specified TCP window size. While this keyword is used rarely, it is helpful in identifying attacks and network scans that use generated packets with static TCP window sizes.

Identifying TCP Streams of a Given Size

License: Protection

You can use the stream_size keyword in conjunction with the stream preprocessor to determine the size in bytes of a TCP stream, using the format:

direction,operator,bytes

where bytes is number of bytes. You must separate each option in the argument with a comma (,).

Table 36-31 stream_size Keyword Directional Arguments

Argument

Description

client

triggers on a stream from the client matching the specified stream size.

server

triggers on a stream from the server matching the specified stream size.

both

triggers on traffic from the client and traffic from the server both matching the specified stream size.

For example, the argument both, >, 200 would trigger when traffic from the client is greater than 200 bytes AND traffic from the server is greater than 200 bytes.

either

triggers on traffic from either the client or the server matching the specified stream size, whichever occurs first.

For example, the argument either, >, 200 would trigger when traffic from the client is greater than 200 bytes OR traffic from the server is greater than 200 bytes.

The following table describes the operators you can use with the stream_size keyword:

Table 36-32 stream_size Keyword Argument Operators

Operator

Description

=

equal to

!=

not equal to

>

greater than

<

less than

>=

greater than or equal to

<=

less than or equal to

For example, you could use client, >=, 5001216 as the argument for the stream_size keyword to detect a TCP stream traveling from a client to a server and greater than or equal to 5001216 bytes.

Enabling and Disabling TCP Stream Reassembly

License: Protection

You can use the stream_reassemble keyword to enable or disable TCP stream reassembly for a single connection when inspected traffic on the connection matches the conditions of the rule. Optionally, you can use this keyword multiple times in a rule.

Use the following syntax to enable or disable stream reassembly:

enable|disable, server|client|both, option, option

The following table describes the optional arguments you can use with the stream_reassemble keyword.

Table 36-33 stream_reassemble Optional Arguments

Argument

Description

noalert

Generate no events regardless of any other detection options specified in the rule.

fastpath

Ignore the rest of the connection traffic when there is a match.

For example, the following rule disables TCP client-side stream reassembly without generating an event on the connection where a 200 OK status code is detected in an HTTP response:

alert tcp any 80 -> any any (flow:to_client, established; content: “200 OK”; stream_reassemble:disable, client, noalert

To use stream_reassemble:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select stream_reassemble in the drop-down list and click Add Option.

The stream_reassemble section appears.

Extracting SSL Information from a Session

License: Protection

You can use SSL rule keywords to invoke the Secure Sockets Layer (SSL) preprocessor and extract information about SSL version and session state from packets in an encrypted session.

When a client and server communicate to establish an encrypted session using SSL or Transport Layer Security (TLS), they exchange handshake messages. Although the data transmitted in the session is encrypted, the handshake messages are not.

The SSL preprocessor extracts state and version information from specific handshake fields. Two fields within the handshake indicate the version of SSL or TLS used to encrypt the session and the stage of the handshake.

For more information, see the following sections:

- ssl_state

- ssl_version

ssl_state

License: Protection

The ssl_state keyword can be used to match against state information for an encrypted session. To check for two or more SSL versions used simultaneously, use multiple ssl_version keywords in a rule.

When a rule uses the ssl_state keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL state information.

For example, to detect an attacker’s attempt to cause a buffer overflow on a server by sending a ClientHello message with an overly long challenge length and too much data, you could use the ssl_state keyword with client_hello as an argument then check for abnormally large packets.

Use a comma-separated list to specify multiple arguments for the SSL state. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you specify client_hello and server_hello as arguments, the system evaluates the rule against traffic that has a client_hello OR a server_hello.

You can also negate any argument; for example:

!client_hello, !unknown

To ensure the connection has reached each of a set of states, multiple rules using the ssl_state rule option should be used. The ssl_state keyword takes the following identifiers as arguments:

Table 36-34 ssl_state Arguments

Argument

Purpose

client_hello

Matches against a handshake message with ClientHello as the message type, where the client requests an encrypted session.

server_hello

Matches against a handshake message with ServerHello as the message type, where the server responds to the client’s request for an encrypted session.

client_keyx

Matches against a handshake message with ClientKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

server_keyx

Matches against a handshake message with ServerKeyExchange as the message type, where the client transmits a key to the server to confirm receipt of a key from the server.

unknown

Matches against any handshake message type.

ssl_version

License: Protection

The ssl_version keyword can be used to match against version information for an encrypted session. When a rule uses the ssl_version keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL version information.

For example, if you know there is a buffer overflow vulnerability in SSL version 2, you could use the ssl_version keyword with the sslv2 argument to identify traffic using that version of SSL.

Use a comma-separated list to specify multiple arguments for the SSL version. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you wanted to identify any encrypted traffic that was not using SSLv2, you could add ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 to a rule. The rule would evaluate any traffic using SSL Version 3, TLS Version 1.0, TLS Version 1.1, or TLS Version 1.2.

The ssl_version keyword takes the following SSL/TLS version identifiers as arguments:

Table 36-35 ssl_version Arguments

Argument

Purpose

sslv2

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 2.

sslv3

Matches against traffic encoded using Secure Sockets Layer (SSL) Version 3.

tls1.0

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.0.

tls1.1

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.1.

tls1.2

Matches against traffic encoded using Transport Layer Security (TLS) Version 1.2.

Inspecting Application Layer Protocol Values

License: Protection

Although preprocessors perform most of the normalization and inspection of application layer protocol values, you can continue to inspect application layer values using the keywords described in the following sections:

- RPC

- ASN.1

- urilen

- DCE/RPC Keywords

- SIP Keywords

- GTP Keywords

- Modbus Keywords

- DNP3 Keywords

RPC

License: Protection

Table 36-36 rpc Keyword Arguments

Argument

Description

application

The RPC application number

procedure

The RPC procedure invoked

version

The RPC version

To specify the arguments for the rpc keyword, use the following syntax:

application,procedure,version

where application is the RPC application number, procedure is the RPC procedure number, and version is the RPC version number. You must specify all arguments for the rpc keyword — if you are not able to specify one of the arguments, replace it with an asterisk (*).

For example, to search for RPC portmapper (which is the RPC application indicated by the number 100000), with any procedure or version, use 100000,*,* as the arguments.

ASN.1

License: Protection

The asn1 keyword allows you to decode a packet or a portion of a packet, looking for various malicious encodings.

The following table describes the arguments for the asn1 keyword.

Table 36-37 asn.1 Keyword Arguments

Argument

Description

Bitstring Overflow

Detects invalid, remotely exploitable bitstring encodings.

Double Overflow

Detects a double ASCII encoding that is larger than a standard buffer. This is known to be an exploitable function in Microsoft Windows, but it is unknown at this time which services may be exploitable.

Oversize Length

Detects ASN.1 type lengths greater than the supplied argument. For example, if you set the Oversize Length to 500, any ASN.1 type greater than 500 triggers the rule.

Absolute Offset

Sets an absolute offset from the beginning of the packet payload. (Remember that the offset counter starts at byte 0.) For example, if you want to decode SNMP packets, set Absolute Offset to 0 and do not set a Relative Offset. Absolute Offset may be positive or negative.

Relative Offset

This is the relative offset from the last successful content match, pcre, or byte_jump. To decode an ASN.1 sequence right after the content "foo", set Relative Offset to 0, and do not set an Absolute Offset. Relative Offset may be positive or negative. (Remember that the offset counter starts at 0.)

For example, there is a known vulnerability in the Microsoft ASN.1 Library that creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted authentication packet. When the system decodes the asn.1 data, exploit code in the packet could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the asn1 keyword to detect attempts to exploit this vulnerability:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445

(flow:to_server, established; content:”|FF|SMB|73|”; nocase;

offset:4; depth:5;

asn1:bitstring_overflow,double_overflow,oversize_length

100,relative_offset 54;)

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using port 445. In addition, it only executes the rule on established TCP connections to servers. The rule then tests for specific content in specific locations. Finally, the rule uses the asn1 keyword to detect bitstring encodings and double ASCII encodings and to identify asn.1 type lengths over 100 bytes in length starting 55 bytes from the end of the last successful content match. (Remember that the offset counter starts at byte 0.)

urilen

License: Protection

You can use the urilen keyword in conjunction with the HTTP Inspect preprocessor to inspect HTTP traffic for URIs of a specific length, less than a maximum length, greater than a minimum length, or within a specified range.

After the HTTP Inspect preprocessor normalizes and inspects the packet, the rules engine evaluates the packet against the rule and determines whether the URI matches the length condition specified by the urilen keyword. You can use this keyword to detect exploits that attempt to take advantage of URI length vulnerabilities, for example, by creating a buffer overflow that allows the attacker to cause a DoS condition or execute code on the host with system-level privileges.

Note the following when using the urilen keyword in a rule:

- In practice, you always use the urilen keyword in combination with the flow:established keyword and one or more other keywords.

- The rule protocol is always TCP. See Specifying Protocols for more information.

- Target ports are always HTTP ports. See Defining Ports in Intrusion Rules and Optimizing Predefined Default Variables for more information.

You specify the URI length using a decimal number of bytes, less than (<) and greater than (>).

For example:

- specify 5 to detect a URI 5 bytes long.

- specify < 5 (separated by one space character) to detect a URI less than 5 bytes long.

- specify > 5 (separated by one space character) to detect a URI greater than 5 bytes long.

- specify 3 <> 5 (with one space character before and after <> ) to detect a URI between 3 and 5 bytes long inclusive.

For example, there is a known vulnerability in Novell’s server monitoring and diagnostics utility iMonitor version 2.4, which comes with eDirectory version 8.8. A packet containing an excessively long URI creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted packet that could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the urilen keyword to detect attempts to exploit this vulnerability:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS

(msg:"EXPLOIT eDirectory 8.8 Long URI iMonitor buffer

overflow attempt";flow:to_server,established;

urilen:> 8192; uricontent:"/nds/"; nocase;

classtype:attempted-admin; sid:x; rev:1;)

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using the ports defined in the $HTTP_PORTS variable. In addition, packets are evaluated against the rule only on established TCP connections to servers. The rule uses the urilen keyword to detect any URI over 8192 bytes in length. Finally, the rule searches the URI for the specific case-insensitive content /nds/.

DCE/RPC Keywords

License: Protection

The three DCE/RPC keywords described in the following table allow you to monitor DCE/RPC session traffic for exploits. When the system processes rules with these keywords, it invokes the DCE/RPC preprocessor. See Decoding DCE/RPC Traffic for more information.

Table 36-38 DCE/RPC Keywords

Use...

In this way...

To detect...

dce_iface

alone

packets identifying a specific DCE/RPC service

dce_opnum

preceded by dce_iface

packets identifying specific DCE/RPC service operations

dce_stub_data

preceded by dce_iface + dce_opnum

stub data defining a specific operation request or response

Note in the table that you should always precede dce_opnum with dce_iface, and you should always precede dce_stub_data with dce_iface + dce_opnum.

You can also use these DCE/RPC keywords in combination with other rule keywords. Note that for DCE/RPC rules, you use the byte_jump, byte_test, and byte_extract keywords with their DCE/RPC arguments selected. For more information, see Using Byte_Jump and Byte_Test and Reading Packet Data into Keyword Arguments.

Cisco recommends that you include at least one content keyword in rules that include DCE/RPC keywords to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument. See Searching for Content Matches and Use Fast Pattern Matcher for more information.

You can use the DCE/RPC version and adjoining header information as the matching content in the following cases:

- the rule does not include another content keyword

- the rule contains another content keyword, but the DCE/RPC version and adjoining information represent a more unique pattern than the other content

For example, the DCE/RPC version and adjoining information are more likely to be unique than a single byte of content.

You should end qualifying rules with one of the following version and adjoining information content matches:

- For connection-oriented DCE/RPC rules, use the content |05 00 00| (for major version 05, minor version 00, and the request PDU (protocol data unit) type 00).

- For connectionless DCE/RPC rules, use the content |04 00| (for version 04, and the request PDU type 00).

In either case, position the content keyword for version and adjoining information as the last keyword in the rule to invoke the fast pattern matcher without repeating processing already completed by the DCE/RPC preprocessor. Note that placing the content keyword at the end of the rule applies to version content used as a device to invoke the fast pattern matcher, and not necessarily to other content matches in the rule.

See the following sections for more information:

- dce_iface

- dce_opnum

- dce_stub_data

dce_iface

License: Protection

You can use the dce_iface keyword to identify a specific DCE/RPC service.

Optionally, you can also use dce_iface in combination with the dce_opnum and dce_stub_data keywords to further limit the DCE/RPC traffic to inspect. See dce_opnum and dce_stub_data for more information.

A fixed, sixteen-byte Universally Unique Identifier (UUID) identifies the application interface assigned to each DCE/RPC service. For example, the UUID 4b324fc8-670-01d3-1278-5a47bf6ee188 identifies the DCE/RPC lanmanserver service, also known as the srvsvc service, which provides numerous management functions for sharing peer-to-peer printers, files, and SMB named pipes. The DCE/RPC preprocessor uses the UUID and associated header values to track DCE/RPC sessions.

The interface UUID is comprised of five hexadecimal strings separated by hyphens:

<4hexbytes>-<2hexbytes>-<2hexbytes>-<2hexbytes>-<6hexbytes>

You specify the interface by entering the entire UUID including hyphens, as seen in the following UUID for the netlogon interface:

12345678-1234-abcd-ef00-01234567cffb

Note that you must specify the first three strings in the UUID in big endian byte order. Although published interface listings and protocol analyzers typically display UUIDs in the correct byte order, you might encounter a need to rearrange the UUID byte order before entering it. Consider the following messenger service UUID shown as it might sometimes be displayed in raw ASCII text with the first three strings in little endian byte order:

f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc

You would specify the same UUID for the dce_iface keyword by inserting hyphens and putting the first three strings in big endian byte order as follows:

5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

Although a DCE/RPC session can include requests to multiple interfaces, you should include only one dce_iface keyword in a rule. Create additional rules to detect additional interfaces.

DCE/RPC application interfaces also have interface version numbers. You can optionally specify an interface version with an operator indicating that the version equals, does not equal, is less than, or greater than the specified value.

Both connection-oriented and connectionless DCE/RPC can be fragmented in addition to any TCP segmentation or IP fragmentation. Typically, it is not useful to associate any DCE/RPC fragment other than the first with the specified interface, and doing so may result in a large number of false positives. However, for flexibility you can optionally evaluate all fragments against the specified interface.

Table 36-39 dce_iface Arguments

Argument

Description

Interface UUID

The UUID, including hyphens, that identifies the application interface of the specific service that you want to detect in DCE/RPC traffic. Any request associated with the specified interface would match the interface UUID.

Version

Optionally, the application interface version number 0 to 65535 and an operator indicating whether to detect a version greater than (>), less than (<), equal to (=), or not equal to (!) the specified value.

All Fragments

Optionally, enable to match against the interface in all associated DCE/RPC fragments and, if specified, on the interface version. This argument is disabled by default, indicating that the keyword matches only if the first fragment or the entire unfragmented packet is associated with the specified interface. Note that enabling this argument may result in false positives.

dce_opnum

License: Protection

You can use the dce_opnum keyword in conjunction with the DCE/RPC preprocessor to detect packets that identify one or more specific operations that a DCE/RPC service provides.

Client function calls request specific service functions, which are referred to in DCE/RPC specifications as operations. An operation number (opnum) identifies a specific operation in the DCE/RPC header. It is likely that an exploit would target a specific operation.

For example, the UUID 12345678-1234-abcd-ef00-01234567cffb identifies the interface for the netlogon service, which provides several dozen different operations. One of these is operation 6, the NetrServerPasswordSet operation.

You should precede a dce_opnum keyword with a dce_iface keyword to identify the service for the operation. See dce_iface for more information.

You can specify a single decimal value 0 to 65535 for a specific operation, a range of operations separated by a hyphen, or a comma-separated list of operations and ranges in any order.

Any of the following examples would specify valid netlogon operation numbers:

15

15-18

15, 18-20

15, 20-22, 17

15, 18-20, 22, 24-26

dce_stub_data

License: Protection

You can use the dce_stub_data keyword in conjunction with the DCE/RPC preprocessor to specify that the rules engine should start inspection at the beginning of the stub data, regardless of any other rule options. Packet payload rule options that follow the dce_stub_data keyword are applied relative to the stub data buffer.

DCE/RPC stub data provides the interface between a client procedure call and the DCE/RPC run-time system, the mechanism that provides the routines and services central to DCE/RPC. DCE/RPC exploits are identified in the stub data portion of the DCE/RPC packet. Because stub data is associated with a specific operation or function call, you should always precede dce_stub_data with dce_iface and dce_opnum to identify the related service and operation.

The dce_stub_data keyword has no arguments. See dce_iface and dce_opnum for more information.

SIP Keywords

License: Protection

Four SIP keywords allow you to monitor SIP session traffic for exploits.

Note that the SIP protocol is vulnerable to denial of service (DoS) attacks. Rules addressing these attacks can benefit from rate-based attack prevention. See Adding Dynamic Rule States and Preventing Rate-Based Attacks for more information.

See the following sections for more information:

- sip_header

- sip_body

- sip_method

- sip_stat_code

sip_header

License: Protection

You can use the sip_header keyword to start inspection at the beginning of the extracted SIP request or response header and restrict inspection to header fields.

The sip_header keyword has no arguments. See sip_method and sip_stat_code for more information.

The following example rule fragment points to the SIP header and matches the CSeq header field:

alert udp any any -> any 5060 ( sip_header; content:"CSeq"; )

sip_body

License: Protection

You can use the sip_body keyword to start inspection at the beginning of the extracted SIP request or response message body and restrict inspection to the message body.

The sip_body keyword has no arguments.

The following example rule fragment points to the SIP message body and matches a specific IP address in the c (connection information) field in extracted SDP data:

alert udp any any -> any 5060 ( sip_body; content:"c=IN 192.168.12.14"; )

Note that rules are not limited to searching for SDP content. The SIP preprocessor extracts the entire message body and makes it available to the rules engine.

sip_method

License: Protection

A method field in each SIP request identifies the purpose of the request. You can use the sip_method keyword to test SIP requests for specific methods. Separate multiple methods with commas.

You can specify any of the following currently defined SIP methods:

ack, benotify, bye, cancel, do, info, invite, join, message, notify, options, prack, publish, quath, refer, register, service, sprack, subscribe, unsubscribe, update

Methods are case-insensitive. You can separate multiple methods with commas.

Because new SIP methods might be defined in the future, you can also specify a custom method, that is, a method that is not a currently defined SIP method. Accepted field values are defined in RFC 2616, which allows all characters except control characters and separators such as =, (, and }. See RFC 2616 for the complete list of excluded separators. When the system encounters a specified custom method in traffic, it will inspect the packet header but not the message.

The system supports up to 32 methods, including the 21 currently defined methods and an additional 11 methods. The system ignores any undefined methods that you might configure. Note that the 32 total methods includes methods specified using the Methods to Check SIP preprocessor option. See Selecting SIP Preprocessor Options for more information.

You can specify only one method when you use negation. For example:

!invite

Note, however, that multiple sip_method keywords in a rule are linked with an AND operation. For example, to test for all extracted methods except invite and cancel, you would use two negated sip_method keywords:

sip_method: !invite

sip_method: !cancel

Cisco recommends that you include at least one content keyword in rules that include the sip_method keyword to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument. See Searching for Content Matches and Use Fast Pattern Matcher for more information.

sip_stat_code

License: Protection

A three-digit status code in each SIP response indicates the outcome of the requested action. You can use the sip_stat_code keyword to test SIP responses for specific status codes.

You can specify a one-digit response-type number 1-9, a specific three-digit number 100-999, or a comma-separated list of any combination of either. A list matches if any single number in the list matches the code in the SIP response.

The following table describes the SIP status code values you can specify.

Table 36-40 sip_stat_code Values

To detect...

Specify...

For example...

Detects...

a specific status code

the three-digit status code

189

189

any three-digit code that begins with a specified single digit

the single digit

1

1xx; that is, 100, 101, 102, and so on

a list of values

any comma-separated combination of specific codes and single digits

222, 3

222 plus 300, 301, 302, and so on

Note also that the rules engine does not use the fast pattern matcher to search for the value specify using the sip_stat_code keyword, regardless of whether your rule includes a content keyword.

GTP Keywords

License: Protection

Three GSRP Tunneling Protocol (GTP) keywords allow you to inspect the GTP command channel for GTP version, message type, and information elements. You cannot use GTP keywords in combination with other intrusion rule keywords such as content or byte_jump. You must use the gtp_version keyword in each rule that uses the gtp_info or gtp_type keyword.

See the following sections for more information:

- gtp_version

- gtp_type

- gtp_info

gtp_version

You can use the gtp_version keyword to inspect GTP control messages for GTP version 0, 1, or 2.

Because different GTP versions define different message types and information elements, you must use this keyword when you use the gtp_type or gtp_info keyword. You can specify the value 0, 1, or 2.

To specify the GTP version:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select gtp_version in the drop-down list and click Add Option.

The gtp_version keyword appears.

Step 2 Specify 0, 1, or 2 to identify the GTP version.

gtp_type

Each GTP message is identified by a message type, which is comprised of both a numeric value and a string. You can use the gtp_type keyword in combination with the gtp_version keyword to inspect traffic for specific GTP message types.

You can specify a defined decimal value for a message type, a defined string, or a comma-separated list of either or both in any combination, as seen in the following example:

10, 11, echo_request

The system uses an OR operation to match each value or string that you list. The order in which you list values and strings does not matter. Any single value or string in the list matches the keyword. You receive an error if you attempt to save a rule that includes an unrecognized string or an out-of-range value.

Note in the table that different GTP versions sometimes use different values for the same message type. For example, the sgsn_context_request message type has a value of 50 in GTPv0 and GTPv1, but a value of 130 in GTPv2.

The gtp_type keyword matches different values depending on the version number in the packet. In the example above, the keyword matches the message type value 50 in a GTPv0 or GTPv1 packet and the value 130 in a GTPv2 packet. The keyword does not match a packet when the message type value in the packet is not a known value for the version specified in the packet.

If you specify an integer for the message type, the keyword matches if the message type in the keyword matches the value in the GTP packet, regardless of the version specified in the packet.

The following table lists the defined values and strings recognized by the system for each GTP message type.

Table 36-41 GTP Message Types

Value

Version 0

Version 1

Version 2

1

echo_request

echo_request

echo_request

2

echo_response

echo_response

echo_response

3

version_not_supported

version_not_supported

version_not_supported

4

node_alive_request

node_alive_request

N/A

5

node_alive_response

node_alive_response

N/A

6

redirection_request

redirection_request

N/A

7

redirection_response

redirection_response

N/A

16

create_pdp_context_request

create_pdp_context_request

N/A

17

create_pdp_context_response

create_pdp_context_response

N/A

18

update_pdp_context_request

update_pdp_context_request

N/A

19

update_pdp_context_response

update_pdp_context_response

N/A

20

delete_pdp_context_request

delete_pdp_context_request

N/A

21

delete_pdp_context_response

delete_pdp_context_response

N/A

22

create_aa_pdp_context_request

init_pdp_context_activation_request

N/A

23

create_aa_pdp_context_response

init_pdp_context_activation_response

N/A

24

delete_aa_pdp_context_request

N/A

N/A

25

delete_aa_pdp_context_response

N/A

N/A

26

error_indication

error_indication

N/A

27

pdu_notification_request

pdu_notification_request

N/A

28

pdu_notification_response

pdu_notification_response

N/A

29

pdu_notification_reject_request

pdu_notification_reject_request

N/A

30

pdu_notification_reject_response

pdu_notification_reject_response

N/A

31

N/A

supported_ext_header_notification

N/A

32

send_routing_info_request

send_routing_info_request

create_session_request

33

send_routing_info_response

send_routing_info_response

create_session_response

34

failure_report_request

failure_report_request

modify_bearer_request

35

failure_report_response

failure_report_response

modify_bearer_response

36

note_ms_present_request

note_ms_present_request

delete_session_request

37

note_ms_present_response

note_ms_present_response

delete_session_response

38

N/A

N/A

change_notification_request

39

N/A

N/A

change_notification_response

48

identification_request

identification_request

N/A

49

identification_response

identification_response

N/A

50

sgsn_context_request

sgsn_context_request

N/A

51

sgsn_context_response

sgsn_context_response

N/A

52

sgsn_context_ack

sgsn_context_ack

N/A

53

N/A

forward_relocation_request

N/A

54

N/A

forward_relocation_response

N/A

55

N/A

forward_relocation_complete

N/A

56

N/A

relocation_cancel_request

N/A

57

N/A

relocation_cancel_response

N/A

58

N/A

forward_srns_contex

N/A

59

N/A

forward_relocation_complete_ack

N/A

60

N/A

forward_srns_contex_ack

N/A

64

N/A

N/A

modify_bearer_command

65

N/A

N/A

modify_bearer_failure_indication

66

N/A

N/A

delete_bearer_command

67

N/A

N/A

delete_bearer_failure_indication

68

N/A

N/A

bearer_resource_command

69

N/A

N/A

bearer_resource_failure_indication

70

N/A

ran_info_relay

downlink_failure_indication

71

N/A

N/A

trace_session_activation

72

N/A

N/A

trace_session_deactivation

73

N/A

N/A

stop_paging_indication

95

N/A

N/A

create_bearer_request

96

N/A

mbms_notification_request

create_bearer_response

97

N/A

mbms_notification_response

update_bearer_request

98

N/A

mbms_notification_reject_request

update_bearer_response

99

N/A

mbms_notification_reject_response

delete_bearer_request

100

N/A

create_mbms_context_request

delete_bearer_response

101

N/A

create_mbms_context_response

delete_pdn_request

102

N/A

update_mbms_context_request

delete_pdn_response

103

N/A

update_mbms_context_response

N/A

104

N/A

delete_mbms_context_request

N/A

105

N/A

delete_mbms_context_response

N/A

112

N/A

mbms_register_request

N/A

113

N/A

mbms_register_response

N/A

114

N/A

mbms_deregister_request

N/A

115

N/A

mbms_deregister_response

N/A

116

N/A

mbms_session_start_request

N/A

117

N/A

mbms_session_start_response

N/A

118

N/A

mbms_session_stop_request

N/A

119

N/A

mbms_session_stop_response

N/A

120

N/A

mbms_session_update_request

N/A

121

N/A

mbms_session_update_response

N/A

128

N/A

ms_info_change_request

identification_request

129

N/A

ms_info_change_response

identification_response

130

N/A

N/A

sgsn_context_request

131

N/A

N/A

sgsn_context_response

132

N/A

N/A

sgsn_context_ack

133

N/A

N/A

forward_relocation_request

134

N/A

N/A

forward_relocation_response

135

N/A

N/A

forward_relocation_complete

136

N/A

N/A

forward_relocation_complete_ack

137

N/A

N/A

forward_access

138

N/A

N/A

forward_access_ack

139

N/A

N/A

relocation_cancel_request

140

N/A

N/A

relocation_cancel_response

141

N/A

N/A

configuration_transfer_tunnel

149

N/A

N/A

detach

150

N/A

N/A

detach_ack

151

N/A

N/A

cs_paging

152

N/A

N/A

ran_info_relay

153

N/A

N/A

alert_mme

154

N/A

N/A

alert_mme_ack

155

N/A

N/A

ue_activity

156

N/A

N/A

ue_activity_ack

160

N/A

N/A

create_forward_tunnel_request

161

N/A

N/A

create_forward_tunnel_response

162

N/A

N/A

suspend

163

N/A

N/A

suspend_ack

164

N/A

N/A

resume

165

N/A

N/A

resume_ack

166

N/A

N/A

create_indirect_forward_tunnel_request

167

N/A

N/A

create_indirect_forward_tunnel_response

168

N/A

N/A

delete_indirect_forward_tunnel_request

169

N/A

N/A

delete_indirect_forward_tunnel_response

170

N/A

N/A

release_access_bearer_request

171

N/A

N/A

release_access_bearer_response

176

N/A

N/A

downlink_data

177

N/A

N/A

downlink_data_ack

179

N/A

N/A

pgw_restart

180

N/A

N/A

pgw_restart_ack

200

N/A

N/A

update_pdn_request

201

N/A

N/A

update_pdn_response

211

N/A

N/A

modify_access_bearer_request

212

N/A

N/A

modify_access_bearer_response

231

N/A

N/A

mbms_session_start_request

232

N/A

N/A

mbms_session_start_response

233

N/A

N/A

mbms_session_update_request

234

N/A

N/A

mbms_session_update_response

235

N/A

N/A

mbms_session_stop_request

236

N/A

N/A

mbms_session_stop_response

240

data_record_transfer_request

data_record_transfer_request

N/A

241

data_record_transfer_response

data_record_transfer_response

N/A

254

N/A

end_marker

N/A

255

pdu

pdu

N/A

To specify GTP message types:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select gtp_type in the drop-down list and click Add Option.

The gtp_type keyword appears.

Step 2 Specify a defined decimal value 0 to 255 for the message type, a defined string, or a comma-separated list of either or both in any combination. See the GTP Message Types table for values and strings recognized by the system.

gtp_info

A GTP message can include multiple information elements, each of which is identified by both a defined numeric value and a defined string. You can use the gtp_info keyword in combination with the gtp_version keyword to start inspection at the beginning of a specified information element and restrict inspection to the specified information element.

You can specify either the defined decimal value or the defined string for an information element. You can specify a single value or string, and you can use multiple gtp_info keywords in a rule to inspect multiple information elements.

When a message includes multiple information elements of the same type, all are inspected for a match. When information elements occur in an invalid order, only the last instance is inspected.

Note that different GTP versions sometimes use different values for the same information element. For example, the cause information element has a value of 1 in GTPv0 and GTPv1, but a value of 2 in GTPv2.

The gtp_info keyword matches different values depending on the version number in the packet. In the example above, the keyword matches the information element value 1 in a GTPv0 or GTPv1 packet and the value 2 in a GTPv2 packet. The keyword does not match a packet when the information element value in the packet is not a known value for the version specified in the packet.

If you specify an integer for the information element, the keyword matches if the message type in the keyword matches the value in the GTP packet, regardless of the version specified in the packet.

Table 36-42 GTP Information Elements

Value

Version 0

Version 1

Version 2

1

cause

cause

imsi

2

imsi

imsi

cause

3

rai

rai

recovery

4

tlli

tlli

N/A

5

p_tmsi

p_tmsi

N/A

6

qos

N/A

N/A

8

recording_required

recording_required

N/A

9

authentication

authentication

N/A

11

map_cause

map_cause

N/A

12

p_tmsi_sig

p_tmsi_sig

N/A

13

ms_validated

ms_validated

N/A

14

recovery

recovery

N/A

15

selection_mode

selection_mode

N/A

16

flow_label_data_1

teid_1

N/A

17

flow_label_signalling

teid_control

N/A

18

flow_label_data_2

teid_2

N/A

19

ms_unreachable

teardown_ind

N/A

20

N/A

nsapi

N/A

21

N/A

ranap

N/A

22

N/A

rab_context

N/A

23

N/A

radio_priority_sms

N/A

24

N/A

radio_priority

N/A

25

N/A

packet_flow_id

N/A

26

N/A

charging_char

N/A

27

N/A

trace_ref

N/A

28

N/A

trace_type

N/A

29

N/A

ms_unreachable

N/A

71

N/A

N/A

apn

72

N/A

N/A

ambr

73

N/A

N/A

ebi

74

N/A

N/A

ip_addr

75

N/A

N/A

mei

76

N/A

N/A

msisdn

77

N/A

N/A

indication

78

N/A

N/A

pco

79

N/A

N/A

paa

80

N/A

N/A

bearer_qos

80

N/A

N/A

flow_qos

82

N/A

N/A

rat_type

83

N/A

N/A

serving_network

84

N/A

N/A

bearer_tft

85

N/A

N/A

tad

86

N/A

N/A

uli

87

N/A

N/A

f_teid

88

N/A

N/A

tmsi

89

N/A

N/A

cn_id

90

N/A

N/A

s103pdf

91

N/A

N/A

s1udf

92

N/A

N/A

delay_value

93

N/A

N/A

bearer_context

94

N/A

N/A

charging_id

95

N/A

N/A

charging_char

96

N/A

N/A

trace_info

97

N/A

N/A

bearer_flag

99

N/A

N/A

pdn_type

100

N/A

N/A

pti

101

N/A

N/A

drx_parameter

103

N/A

N/A

gsm_key_tri

104

N/A

N/A

umts_key_cipher_quin

105

N/A

N/A

gsm_key_cipher_quin

106

N/A

N/A

umts_key_quin

107

N/A

N/A

eps_quad

108

N/A

N/A

umts_key_quad_quin

109

N/A

N/A

pdn_connection

110

N/A

N/A

pdn_number

111

N/A

N/A

p_tmsi

112

N/A

N/A

p_tmsi_sig

113

N/A

N/A

hop_counter

114

N/A

N/A

ue_time_zone

115

N/A

N/A

trace_ref

116

N/A

N/A

complete_request_msg

117

N/A

N/A

guti

118

N/A

N/A

f_container

119

N/A

N/A

f_cause

120

N/A

N/A

plmn_id

121

N/A

N/A

target_id

123

N/A

N/A

packet_flow_id

124

N/A

N/A

rab_contex

125

N/A

N/A

src_rnc_pdcp

126

N/A

N/A

udp_src_port

127

charge_id

charge_id

apn_restriction

128

end_user_address

end_user_address

selection_mode

129

mm_context

mm_context

src_id

130

pdp_context

pdp_context

N/A

131

apn

apn

change_report_action

132

protocol_config

protocol_config

fq_csid

133

gsn

gsn

channel

134

msisdn

msisdn

emlpp_pri

135

N/A

qos

node_type

136

N/A

authentication_qu

fqdn

137

N/A

tft

ti

138

N/A

target_id

mbms_session_duration

139

N/A

utran_trans

mbms_service_area

140

N/A

rab_setup

mbms_session_id

141

N/A

ext_header

mbms_flow_id

142

N/A

trigger_id

mbms_ip_multicast

143

N/A

omc_id

mbms_distribution_ack

144

N/A

ran_trans

rfsp_index

145

N/A

pdp_context_pri

uci

146

N/A

addi_rab_setup

csg_info

147

N/A

sgsn_number

csg_id

148

N/A

common_flag

cmi

149

N/A

apn_restriction

service_indicator

150

N/A

radio_priority_lcs

detach_type

151

N/A

rat_type

ldn

152

N/A

user_loc_info

node_feature

153

N/A

ms_time_zone

mbms_time_to_transfer

154

N/A

imei_sv

throttling

155

N/A

camel

arp

156

N/A

mbms_ue_context

epc_timer

157

N/A

tmp_mobile_group_id

signalling_priority_indication

158

N/A

rim_routing_addr

tmgi

159

N/A

mbms_config

mm_srvcc

160

N/A

mbms_service_area

flags_srvcc

161

N/A

src_rnc_pdcp

nmbr

162

N/A

addi_trace_info

N/A

163

N/A

hop_counter

N/A

164

N/A

plmn_id

N/A

165

N/A

mbms_session_id

N/A

166

N/A

mbms_2g3g_indicator

N/A

167

N/A

enhanced_nsapi

N/A

168

N/A

mbms_session_duration

N/A

169

N/A

addi_mbms_trace_info

N/A

170

N/A

mbms_session_repetition_num

N/A

171

N/A

mbms_time_to_data

N/A

173

N/A

bss

N/A

174

N/A

cell_id

N/A

175

N/A

pdu_num

N/A

177

N/A

mbms_bearer_capab

N/A

178

N/A

rim_routing_disc

N/A

179

N/A

list_pfc

N/A

180

N/A

ps_xid

N/A

181

N/A

ms_info_change_report

N/A

182

N/A

direct_tunnel_flags

N/A

183

N/A

correlation_id

N/A

184

N/A

bearer_control_mode

N/A

185

N/A

mbms_flow_id

N/A

186

N/A

mbms_ip_multicast

N/A

187

N/A

mbms_distribution_ack

N/A

188

N/A

reliable_inter_rat_handover

N/A

189

N/A

rfsp_index

N/A

190

N/A

fqdn

N/A

191

N/A

evolved_allocation1

N/A

192

N/A

evolved_allocation2

N/A

193

N/A

extended_flags

N/A

194

N/A

uci

N/A

195

N/A

csg_info

N/A

196

N/A

csg_id

N/A

197

N/A

cmi

N/A

198

N/A

apn_ambr

N/A

199

N/A

ue_network

N/A

200

N/A

ue_ambr

N/A

201

N/A

apn_ambr_nsapi

N/A

202

N/A

ggsn_backoff_timer

N/A

203

N/A

signalling_priority_indication

N/A

204

N/A

signalling_priority_indication_nsapi

N/A

205

N/A

high_bitrate

N/A

206

N/A

max_mbr

N/A

251

charging_gateway_addr

charging_gateway_addr

N/A

255

private_extension

private_extension

private_extension

You can use the following procedure to specify a GTP information element.

To specify a GTP information element:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select gtp_info in the drop-down list and click Add Option.

The gtp_info keyword appears.

Step 2 Specify a single defined decimal value 0 to 255 for the information element, or a single defined string. See the GTP Information Elements table for values and strings recognized by the system.

Modbus Keywords

License: Protection

You can use Modbus keywords to point to the beginning of the Data field in a Modbus request or response, to match against the Modbus Function Code, and to match against a Modbus Unit ID. You can use Modbus keywords alone or in combination with other keywords such as content and byte_jump.

See the following sections for more information:

- modbus_data

- modbus_func

- modbus_unit

modbus_data

You can use the modbus_data keyword to point to the beginning of the Data field in a Modbus request or response.

To point to the beginning of the Modbus Data field:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select modbus_data from the drop-down list and click Add Option.

The modbus_data keyword appears.

The modbus_data keyword has no arguments.

modbus_func

You can use the modbus_func keyword to match against the Function Code field in a Modbus application layer request or response header. You can specify either a single defined decimal value or a single defined string for a Modbus function code.

The following table lists the defined values and strings recognized by the system for Modbus function codes.

Table 36-43 Modbus Function Codes

Value

String

1

read_coils

2

read_discrete_inputs

3

read_holding_registers

4

read_input_registers

5

write_single_coil

6

write_single_register

7

read_exception_status

8

diagnostics

11

get_comm_event_counter

12

get_comm_event_log

15

write_multiple_coils

16

write_multiple_registers

17

report_slave_id

20

read_file_record

21

write_file_record

22

mask_write_register

23

read_write_multiple_registers

24

read_fifo_queue

43

encapsulated_interface_transport

To specify a Modbus function code:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select modbus_func in the drop-down list and click Add Option.

The modbus_func keyword appears.

Step 2 Specify a single defined decimal value 0 to 255 for the function code, or a single defined string. See the Modbus Function Codes table for values and strings recognized by the system.

modbus_unit

You can use the modbus_unit keyword to match a single decimal value against the Unit ID field in a Modbus request or response header.

To specify a Modbus unit ID:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select modbus_unit in the drop-down list and click Add Option.

The modbus_unit keyword appears.

Step 2 Specify a decimal value 0 through 255.

DNP3 Keywords

License: Protection

You can use DNP3 keywords to point to the beginning of application layer fragments, to match against DNP3 function codes and objects in DNP3 responses and requests, and to match against internal indication flags in DNP3 responses. You can use DNP3 keywords alone or in combination with other keywords such as content and byte_jump.

See the following sections for more information:

- dnp3_data

- dnp3_func

- dnp3_ind

- dnp3_obj

dnp3_data

You can use the dnp3_data keyword to point to the beginning of reassembled DNP3 application layer fragments.

The DNP3 preprocessor reassembles link layer frames into application layer fragments. The dnp3_data keyword points to the beginning of each application layer fragment; other rule options can match against the reassembled data within fragments without separating the data and adding checksums every 16 bytes.

To point to the beginning of reassembled DNP3 fragments:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select modbus_data from the drop-down list and click Add Option.

The dnp3_data keyword appears.

The dnp3_data keyword has no arguments.

dnp3_func

You can use the dnp3_func keyword to match against the Function Code field in a DNP3 application layer request or response header. You can specify either a single defined decimal value or a single defined string for a DNP3 function code.

The following table lists the defined values and strings recognized by the system for DNP3 function codes.

Table 36-44 DNP3 Function Codes

Value

String

0

confirm

1

read

2

write

3

select

4

operate

5

direct_operate

6

direct_operate_nr

7

immed_freeze

8

immed_freeze_nr

9

freeze_clear

10

freeze_clear_nr

11

freeze_at_time

12

freeze_at_time_nr

13

cold_restart

14

warm_restart

15

initialize_data

16

initialize_appl

17

start_appl

18

stop_appl

19

save_config

20

enable_unsolicited

21

disable_unsolicited

22

assign_class

23

delay_measure

24

record_current_time

25

open_file

26

close_file

27

delete_file

28

get_file_info

29

authenticate_file

30

abort_file

31

activate_config

32

authenticate_req

33

authenticate_err

129

response

130

unsolicited_response

131

authenticate_resp

To specify DNP3 function codes:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select dnp3_func in the drop-down list and click Add Option.

The dnp3_func keyword appears.

Step 2 Specify a single defined decimal value 0 to 255 for the function code, or a single defined string. See the DNP3 Function Codes table for values and strings recognized by the system.

dnp3_ind

You can use the dnp3_ind keyword to match against flags in the Internal Indications field in a DNP3 application layer response header.

You can specify the string for a single known flag or a comma-separated list of flags, as seen in the following example:

class_1_events, class_2_events

When you specify multiple flags, the keyword matches against any flag in the list. To detect a combination of flags, use the dnp3_ind keyword multiple times in a rule.

The following list provides the string syntax recognized by the system for defined DNP3 internal indications flags.

class_1_events

class_2_events

class_3_events

need_time

local_control

device_trouble

device_restart

no_func_code_support

object_unknown

parameter_error

event_buffer_overflow

already_executing

config_corrupt

reserved_2

reserved_1

To specify DNP3 internal indications flags:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select dnp3_ind in the drop-down list and click Add Option.

The dnp3_ind keyword appears.

Step 2 You can specify the string for a single known flag or a comma-separated list of flags.

dnp3_obj

You can use the dnp3_obj keyword to match against DNP3 object headers in a request or response.

DNP3 data is comprised of a series of DNP3 objects of different types such as analog input, binary input, and so on. Each type is identified with a group such as analog input group, binary input group, and so on, each of which can be identified by a decimal value. The objects in each group are further identified by an object variation such as 16-bit integers, 32-bit integers, short floating point, and so on, each of which specifies the data format of the object. Each type of object variation can also be identified by a decimal value.

You identify object headers by specifying the decimal number for the type of object header group and the decimal number for the type of object variation. The combination of the two defines a specific type of DNP3 object.

To specify a DNP3 object:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select dnp3_obj in the drop-down list and click Add Option.

The dnp3_obj keyword appears.

Step 2 Specify a decimal value 0 through 255 to identify a known object group, and another decimal value 0 through 255 to identify a known object variation type.

CIP and ENIP Keywords

License: Protection

You can use the following keywords alone or in combination to create custom intrusion rules that identify attacks against CIP and ENIP traffic detected by the CIP preprocessor. For configurable keywords, specify a single integer within the allowed range. See Configuring the CIP Preprocessor for more information.

Table 36-45 CIP and ENIP Keywords

Keyword

Range

cip_attribute

0 - 65535

cip_class

0 - 65535

cip_conn_path_class

0 - 65535

cip_instance

0 - 4284927295

cip_req

N/A

cip_rsp

N/A

cip_service

0 - 127

cip_status

0 - 255

enip_command

0 - 65535

enip_req

N/A

enip_rsp

N/A

Inspecting Packet Characteristics

License: Protection

You can write rules that only generate events against packets with specific packet characteristics. The FireSIGHT System provides the following keywords to evaluate packet characteristics:

- dsize

- isdataat

- sameip

- fragoffset

- cvs

dsize

License: Protection

The dsize keyword tests the packet payload size. With it, you can use the greater than and less than operators (< and >) to specify a range of values. You can use the following syntax to specify ranges:

>number_of_bytes

<number_of_bytes

number_of_bytes<>number_of_bytes

For example, to indicate a packet size greater than 400 bytes, use >400 as the dtype value. To indicate a packet size of less than 500 bytes, use <500. To specify that the rule trigger against any packet between 400 and 500 bytes inclusive, use 400<>500.

Caution The dsize keyword tests packets before they are decoded by any preprocessors.

isdataat

License: Protection

The isdataat keyword instructs the rules engine to verify that data resides at a specific location in the payload.

Table 36-46 isdataat Arguments

Argument

Type

Description

Offset

Required

The specific location in the payload. For example, to test that data appears at byte 50 in the packet payload, you would specify 50 as the offset value. A ! modifier negates the results of the isdataat test; it alerts if a certain amount of data is not present within the payload.

You can also use an existing byte_extract variable to specify the value for this argument. See Reading Packet Data into Keyword Arguments for more information.

Relative

Optional

Makes the location relative to the last successful content match. If you specify a relative location, note that the counter starts at byte 0, so calculate the location by subtracting 1 from the number of bytes you want to move forward from the last successful content match. For example, to specify that the data must appear at the ninth byte after the last successful content match, you would specify a relative offset of 8.

Raw Data

Optional

Specifies that the data is located in the original packet payload before decoding or application layer normalization by any FireSIGHT System preprocessor. You can use this argument with Relative if the previous content match was in the raw packet data.

For example, in a rule searching for the content foo, if the value for isdataat is specified as the following:

- Offset = !10

- Relative = enabled

The system alerts if the rules engine does not detect 10 bytes after foo before the payload ends.

To use isdataat:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select isdataat in the drop-down list and click Add Option.

The isdataat section appears.

sameip

License: Protection

The sameip keyword tests that a packet’s source and destination IP addresses are the same. It does not take an argument.

fragoffset

License: Protection

The fragoffset keyword tests the offset of a fragmented packet. This is useful because some exploits (such as WinNuke denial-of-service attacks) use hand-generated packet fragments that have specific offsets.

For example, to test whether the offset of a fragmented packet is 31337 bytes, specify 31337 as the fragoffset value.

You can use the following operators when specifying arguments for the fragoffset keyword.

Table 36-47 fragoffset Keyword Argument Operators

Operator

Description

!

not

>

greater than

<

less than

Note that you cannot use the not (!) operator in combination with < or >.

cvs

License: Protection

The cvs keyword tests Concurrent Versions System (CVS) traffic for malformed CVS entries. An attacker can use a malformed entry to force a heap overflow and execute malicious code on the CVS server. This keyword can be used to identify attacks against two known CVS vulnerabilities: CVE-2004-0396 (CVS 1.11.x up to 1.11.15, and 1.12.x up to 1.12.7) and CVS-2004-0414 (CVS 1.12.x through 1.12.8, and 1.11.x through 1.11.16). The cvs keyword checks for a well-formed entry, and generates alerts when a malformed entry is detected.

Your rule should include the ports where CVS runs. In addition, any ports where traffic may occur should be added to the list of ports for stream reassembly in your TCP policies so state can be maintained for CVS sessions. The TCP ports 2401 (pserver) and 514 (rsh) are included in the list of client ports where stream reassembly occurs. However, note that if your server runs as an xinetd server (i.e., pserver), it can run on any TCP port. Add any non-standard ports to the stream reassembly Client Ports list. For more information, see Selecting Stream Reassembly Options.

To detect malformed CVS entries:

Access: Admin/Intrusion Admin

Step 1 Add the cvs option to a rule and type invalid-entry as the keyword argument.

Reading Packet Data into Keyword Arguments

License: Protection

You can use the byte_extract keyword to read a specified number of bytes from a packet into a variable. You can then use the variable later in the same rule as the value for specific arguments in certain other detection keywords.

This is useful, for example, for extracting data size from packets where a specific segment of bytes describes the number of bytes included in data within the packet. For example, a specific segment of bytes might say that subsequent data is comprised of four bytes; you can extract the data size of four bytes to use as your variable value.

You can use byte_extract to create up to two separate variables in a rule concurrently. You can redefine a byte_extract variable any number of times; entering a new byte_extract keyword with the same variable name and a different variable definition overwrites the previous definition of that variable.

Table 36-48 Required byte_extract Arguments

Argument

Description

Bytes to Extract

The number of bytes to extract from the packet. You can specify 1, 2, 3, or 4 bytes.

Offset

The number of bytes into the payload to begin extracting data. You can specify -65534 to 65535 bytes. The offset counter starts at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you want to count forward. For example, specify 7 to count forward 8 bytes. The rules engine counts forward from the beginning of the packet payload or, if you also specify Relative, after the last successful content match. Note that you can specify negative numbers only when you also specify Relative; see the Additional Optional byte_extract Arguments table for more information.

Variable Name

The variable name to use in arguments for other detection keywords. You can specify an alphanumeric string that must begin with a letter.

To further define how the system locates the data to extract, you can use the arguments described in the following table.

Table 36-49 Additional Optional byte_extract Arguments

Argument

Description

Multiplier

A multiplier for the value extracted from the packet. You can specify 0 to 65535. If you do not specify a multiplier, the default value is 1.

Align

Rounds the extracted value to the nearest 2-byte or 4-byte boundary. When you also select Multiplier, the system applies the multiplier before the alignment.

Relative

Makes Offset relative to the end of the last successful content match instead of the beginning of the payload. See the Required byte_extract Arguments table for more information.

You can specify only one of DCE/RPC, Endian, or Number Type.

Table 36-50 Endianness byte_extract Arguments

Argument

Description

Big Endian

Processes data in big endian byte order, which is the default network byte order.

Little Endian

Processes data in little endian byte order.

DCE/RPC

Specifies a byte_extract keyword for traffic processed by the DCE/RPC preprocessor. See Decoding DCE/RPC Traffic for more information.

The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian arguments do not apply.

When you enable this argument, you can also use byte_extract in conjunction with other specific DCE/RPC keywords. See DCE/RPC Keywords for more information.

You can specify a number type to read data as an ASCII string. To define how the system views string data in a packet, you can select one of the arguments in the following table.

Table 36-51 Number Type byte_extract arguments

Argument

Description

Hexadecimal String

Reads extracted string data in hexadecimal format.

Decimal String

Reads extracted string data in decimal format.

Octal String

Reads extracted string data in octal format.

For example, if the value for byte_extract is specified as the following:

- Bytes to Extract = 4

- Variable Name = var

- Offset = 8

- Relative = enabled

the rules engine reads the number described in the four bytes that appear 9 bytes away from (relative to) the last successful content match into a variable named var, which you can specify later in the rule as the value for certain keyword arguments.

The following table lists the keyword arguments where you can specify a variable defined in the byte_extract keyword.

Table 36-52 Arguments Accepting a byte_extract Variable

Keyword

Argument

For more information, see...

content

Depth, Offset, Distance, Within

Constraining Content Matches

byte_jump

Offset

byte_jump

byte_test

Offset, Value

byte_test

isdataat

Offset

isdataat

To use byte_extract:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select t byte_extract in the drop-down list and click Add Option.

The byte_extract section appears beneath the last keyword you selected.

Initiating Active Responses with Rule Keywords

License: Protection

The system can initiate active responses to close TCP connections in response to triggered TCP rules or UDP sessions in response to triggered UDP rules. Two keywords provide you with separate approaches to initiating active responses. When a packet triggers a rule containing either of the keywords, the system initiates a single active response. You can also use the config response command to configure the active response interface to use and the number of TCP resets to attempt in a passive deployment.

Active responses are most effective in inline deployments because resets are more likely to arrive in time to affect the connection or session. For example, in response to the react keyword in an inline deployment, the system inserts a TCP reset (RST) packet directly into the traffic for each end of the connection, which normally should close the connection.

Active responses are not intended to take the place of a firewall for a number of reasons, including that the system cannot insert packets in passive deployments and an attacker may have chosen to ignore or circumvent active responses.

Because active responses can be routed back, the system does not allow TCP resets to initiate TCP resets; this prevents an unending sequence of active responses. The system also does not allow ICMP unreachable packets to initiate ICMP unreachable packets in keeping with standard practice.

You can configure the TCP stream preprocessor to detect additional traffic on a connection or session after an intrusion rule has triggered an active response. When the preprocessor detects additional traffic, it sends additional active responses up to a specified maximum to both ends of the connection or session. See Initiating Active Responses with Intrusion Drop Rules for more information.

See the following sections for information specific to the keywords you can use to initiate active responses:

- Initiating Active Responses by Type and Direction

- Sending an HTML Page Before a TCP Reset

- Setting the Active Response Reset Attempts and Interface

Initiating Active Responses by Type and Direction

License: Protection

You can use the resp keyword to actively respond to TCP connections or UDP sessions, depending on whether you specify the TCP or UDP protocol in the rule header. See Specifying Protocols for more information.

Keyword arguments allow you to specify the packet direction and whether to use TCP reset (RST) packets or ICMP unreachable packets as active responses.

You can use any of the TCP reset or ICMP unreachable arguments to close TCP connections. You should use only ICMP unreachable arguments to close UDP sessions.

Different TCP reset arguments also allow you to target active responses to the packet source, destination, or both. All ICMP unreachable arguments target the packet source and allow you to specify whether to use an ICMP network, host, or port unreachable packet, or all three.

Table 36-53 resp Arguments

Argument

Description

reset_source

Directs a TCP reset packet to the endpoint that sent the packet that triggered the rule. Alternatively, you can specify rst_snd, which is supported for backward compatibility.

reset_dest

Directs a TCP reset packet to the intended destination endpoint of the packet that triggered the rule. Alternatively, you can specify rst_rcv, which is supported for backward compatibility.

reset_both

Directs a TCP reset packet to both the sending and receiving endpoints. Alternatively, you can specify rst_all, which is supported for backward compatibility.

icmp_net

Directs an ICMP network unreachable message to the sender.

icmp_host

Directs an ICMP host unreachable message to the sender.

icmp_port

Directs an ICMP port unreachable message to the sender. This argument is used to terminate UDP traffic.

icmp_all

Directs the following ICMP messages to the sender:

- network unreachable

- host unreachable

- port unreachable

For example, to configure a rule to reset both sides of a connection when a rule is triggered, use reset_both as the value for the resp keyword.

You can use a comma-separated list to specify multiple arguments as follows:

argument,argument,argument

See Setting the Active Response Reset Attempts and Interface for information on using the config response command to configure the active response interface to use and the number of TCP resets to attempt in a passive deployment.

To specify active responses:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select resp in the drop-down list and click Add Option.

The resp keyword appears.

Step 2 Specify any of the arguments in the resp Arguments table in the resp field; use a comma-separated list to specify multiple arguments.

Sending an HTML Page Before a TCP Reset

License: Protection

You can use the react keyword to send a default HTML page to the TCP connection client when a packet triggers the rule; after sending the HTML page, the system uses TCP reset packets to initiate active responses to both ends of the connection. The react keyword does not trigger active responses for UDP traffic.

Optionally, you can specify the following argument:

msg

When a packet triggers a react rule that uses the msg argument, the HTML page includes the rule event message. See Understanding Rule Anatomy for a description of the event message field.

If you do not specify the msg argument, the HTML page includes the following message:

You are attempting to access a forbidden site.

Consult your system administrator for details.

Note Because active responses can be routed back, ensure that the HTML response page does not trigger a react rule; this could result in an unending sequence of active responses. Cisco recommends that you test react rules extensively before activating them in a production environment.

See Setting the Active Response Reset Attempts and Interface for information on using the config response command to configure the active response interface to use and the number of TCP resets to attempt in a passive deployment.

To send an HTML page before initiating an active responses:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select react in the drop-down list and click Add Option.

The react keyword appears.

Step 2 You have two choices:

- To send an HTML page that includes the event message configured for the rule to the client before closing a connection, type msg in the react field.

- To send an HTML page that includes the following default message to the client before closing a connection, leave the react field blank:

You are attempting to access a forbidden site.

Consult your system administrator for details

Setting the Active Response Reset Attempts and Interface

License: Protection

You can use the config response command to further configure the behavior of TCP resets initiated by resp and react rules. This command also affects the behavior of active responses initiated by drop rules; see Initiating Active Responses with Intrusion Drop Rules for more information.

You use the config response command by inserting it on a separate line in the USER_CONF advanced variable. See Understanding Advanced Variables for information on using a USER_CONF variable.

Caution Do not use the USER_CONF advanced variable to configure an intrusion policy feature unless you are instructed to do so in the feature description or by Support. Conflicting or duplicate configurations will halt the system.

To specify active response reset attempts, the active response interface, or both:

Access: Admin/Intrusion Admin

Step 1 Depending on whether you want to specify only the number of active responses, only the active response interface, or both, insert a form of the config response command on a separate line in the USER_CONF advanced variable. You have the following choices:

- To specify only the number of active response attempts, insert the command:

config response: attempts att

For example: config response: attempts 10

- To specify only the active response interface, insert the command:

config response: device dev

For example: config response: device eth0

- To specify both the number of active response attempts and the active response interface, insert the command:

config response: attempts att, device dev

For example: config response: attempts 10, device eth0

where:

att is the number 1 to 20 of attempts to land each TCP reset packet within the current connection window so the receiving host accepts the packet. This sequence strafing is useful only in passive deployments; in inline deployments, the system inserts reset packets directly into the stream in place of triggering packets. the system sends only 1 ICMP reachable active response.

dev is an alternate interface where you want the system to send active responses in a passive deployment or insert active responses in an inline deployment.

Filtering Events

License: Protection

You can use the detection_filter keyword to prevent a rule from generating events unless a specified number of packets trigger the rule within a specified time. This can stop the rule from prematurely generating events. For example, two or three failed login attempts within a few seconds could be expected behavior, but a large number of attempts within the same time could indicate a brute force attack.

The detection_filter keyword requires arguments that define whether the system tracks the source or destination IP address, the number of times the detection criteria must be met before triggering an event, and how long to continue the count.

Use the following syntax to delay the triggering of events:

track by_src/by_dst, count count, seconds number_of_seconds

The track argument specifies whether to use the packet’s source or destination IP address when counting the number of packets that meet the rule’s detection criteria. Select from the argument values described in the following table to specify how the system tracks event instances.

Table 36-54 detection_filter Track Arguments

Argument

Description

by_src

Detection criteria count by source IP address.

by_dst

Detection criteria count by destination IP address.

The count argument specifies the number of packets that must trigger the rule for the specified IP address within the specified time before the rule generates an event.

The seconds argument specifies the number of seconds within which the specified number of packets must trigger the rule before the rule generates an event.

Consider the case of a rule that searches packets for the content foo and uses the detection_filter keyword with the following arguments:

track by_src, count 10, seconds 20

In the example, the rule will not generate an event until it has detected foo in 10 packets within 20 seconds from a given source IP address. If the system detects only 7 packets containing foo within the first 20 seconds, no event is generated. However, if foo occurs 40 times in the first 20 seconds, the rule generates 30 events and the count begins again when 20 seconds have elapsed.

Comparing the threshold and detection_filter Keywords

The detection_filter keyword replaces the deprecated threshold keyword. The threshold keyword is still supported for backward compatibility and operates the same as thresholds that you set within an intrusion policy.

The detection_filter keyword is a detection feature that is applied before a packet triggers a rule. The rule does not generate an event for triggering packets detected before the specified packet count and, in an inline deployment, does not drop those packets if the rule is set to drop packets. Conversely, the rule does generate events for packets that trigger the rule and occur after the specified packet count and, in an inline deployment, drops those packets if the rule is set to drop packets.

Thresholding is an event notification feature that does not result in a detection action. It is applied after a packet triggers an event. In an inline deployment, a rule that is set to drop packets drops all packets that trigger the rule, independent of the rule threshold.

Note that you can use the detection_filter keyword in any combination with the intrusion event thresholding, intrusion event suppression, and rate-based attack prevention features in an intrusion policy. Note also that policy validation fails if you enable an imported local rule that uses the deprecated threshold keyword in combination with the intrusion event thresholding feature in an intrusion policy. See Configuring Event Thresholding, Configuring Suppression Per Intrusion Policy, Setting a Dynamic Rule State, and Importing Local Rule Files for more information.

Evaluating Post-Attack Traffic

License: Protection

Use the tag keyword to tell the system to log additional traffic for the host or session. Use the following syntax when specifying the type and amount of traffic you want to capture using the tag keyword:

tagging_type, count, metric, optional_direction

The next three tables describe the other available arguments.

Table 36-55 Tag Arguments

Argument

Description

session

Logs packets in the session that triggered the rule.

host

Logs packets from the host that sent the packet that triggered the rule. You can add a directional modifier to log only the traffic coming from the host (src) or going to the host (dst).

To indicate how much traffic you want to log, use the following argument:

Table 36-56 Count Argument

Argument

Description

count

The number of packets or seconds you want to log after the rule triggers.

This unit of measure is specified with the metric argument, which follows the count argument.

Table 36-57 Logging Metrics Arguments

Argument

Description

packets

Logs the number of packets specified by the count after the rule triggers.

seconds

Logs traffic for the number of seconds specified by the count after the rule triggers.

For example, when a rule with the following tag keyword value triggers:

host, 30, seconds, dst

all packets that are transmitted from the client to the host for the next 30 seconds are logged.

Detecting Attacks That Span Multiple Packets

License: Protection

Use the flowbits keyword to assign state names to sessions. By analyzing subsequent packets in a session according to the previously named state, the system can detect and alert on exploits that span multiple packets in a single session.

The flowbits state name is a user-defined label assigned to packets in a specific part of a session. You can label packets with state names based on packet content to help distinguish malicious packets from those you do not want to alert on. You can define up to 1024 state names per managed device. For example, if you want to alert on malicious packets that you know only occur after a successful login, you can use the flowbits keyword to filter out the packets that constitute an initial login attempt so you can focus only on the malicious packets. You can do this by first creating a rule that labels all packets in the session that have an established login with a logged_in state, then creating a second rule where flowbits checks for packets with the state you set in the first rule and acts only on those packets. See flowbits Example Using state_name for an example that uses flowbits to determine if a user is logged in.

An optional group name allows you to include a state name in a group of states. A state name can belong to several groups. States not associated with a group are not mutually exclusive, so a rule that triggers and sets a state that is not associated with a group does not affect other currently set states. See flowbits Example Resulting in a False Positive for an example that illustrates how including a state name in a group can prevent false positives by unsetting another state in the same group.

Table 36-58 flowbits Options

Operator

State Option

Group

Description

set

state_name

optional

Sets the specified state for a packet. Sets the state in the specified group if a group is defined.

state_name&state_name

optional

Sets the specified states for a packet. Sets the states in the specified group if a group is defined.

setx

state_name

mandatory

Sets the specified state in the specified group for a packet, and unsets all other states in the group.

state_name&state_name

mandatory

Sets the specified states in the specified group for a packet, and unsets all other states in the group.

unset

state_name

no group

Unsets the specified state for a packet.

state_name&state_name

no group

Unsets the specified states for a packet.

all

mandatory

Unsets all the states in the specified group.

toggle

state_name

no group

Unsets the specified state if it is set, and sets the specified state if it is unset.

state_name&state_name

no group

Unsets the specified states if they are set, and sets the specified states if they are unset.

all

mandatory

Unsets all states set in the specified group, and sets all states unset in the specified group.

isset

state_name

no group

Determines if the specified state is set in the packet.

state_name&state_name

no group

Determines if the specified states are set in the packet.

state_name|state_name

no group

Determines if any of the specified states are set in the packet.

any

mandatory

Determines if any state is set in the specified group.

all

mandatory

Determines if all states are set in the specified group.

isnotset

state_name

no group

Determines if the specified state is not set in the packet.

state_name&state_name

no group

Determines if the specified states are not set in the packet.

state_name|state_name

no group

Determines if any of the specified states is not set in the packet.

any

mandatory

Determines if any state is not set in the packet.

all

mandatory

Determines if all states are not set in the packet.

reset

(no state)

optional

Unsets all states for all packets. Unsets all states in a group if a group is specified.

noalert

(no state)

no group

Use this in conjunction with any other operator to suppress event generation.

Note the following when using the flowbits keyword:

- When using the setx operator, the specified state can only belong to the specified group, and not to any other group.

- You can define the setx operator multiple times, specifying different states and the same group with each instance.

- When you use the setx operator and specify a group, you cannot use the set , toggle , or unset operators on that specified group.

- The isset and isnotset operators evaluate for the specified state regardless of whether the state is in a group.

- During intrusion policy saves, intrusion policy reapplies, and access control policy applies (regardless of whether the access control policy references one intrusion policy or multiple intrusion policies), if you enable a rule that contains the isset or isnotset operator without a specified group, and you do not enable at least one rule that affects flowbits assignment ( set , setx , unset , toggle ) for the corresponding state name and protocol, all rules that affect flowbits assignment for the corresponding state name are enabled.

- During intrusion policy saves, intrusion policy reapplies, and access control policy applies (regardless of whether the access control policy references one intrusion policy or multiple intrusion policies), if you enable a rule that contains the isset or isnotset operator with a specified group, all rules that affect flowbits assignment ( set , setx , unset , toggle ) and define a corresponding group name are also enabled.

flowbits Example Using state_name

Consider the IMAP vulnerability described in Bugtraq ID #1110. This vulnerability exists in an implementation of IMAP, specifically in the LIST, LSUB, RENAME, FIND, and COPY commands. However, to take advantage of the vulnerability, the attacker must be logged into the IMAP server. Because the LOGIN confirmation from the IMAP server and the exploit that follows are necessarily in different packets, it is difficult to construct non-flow-based rules that catch this exploit. Using the flowbits keyword, you can construct a series of rules that track whether the user is logged into the IMAP server and, if so, generate an event if one of the attacks is detected. If the user is not logged in, the attack cannot exploit the vulnerability and no event is generated.

The two rule fragments that follow illustrate this example. The first rule fragment looks for an IMAP login confirmation from the IMAP server:

alert tcp any 143 -> any any (msg:"IMAP login"; content:"OK

LOGIN"; flowbits:set,logged_in; flowbits:noalert;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

Note that flowbits:set sets a state of logged_in, while flowbits:noalert suppresses the alert because you are likely to see many innocuous login sessions on an IMAP server.

The next rule fragment looks for a LIST string, but does not generate an event unless the logged_in state has been set as a result of some previous packet in the session:

alert tcp any any -> any 143 (msg:"IMAP LIST";

content:"LIST"; flowbits:isset,logged_in;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

In this case, if a previous packet has caused a rule containing the first fragment to trigger, then a rule containing the second fragment triggers and generates an event.

flowbits Example Resulting in a False Positive

Including different state names that are set in different rules in a group can prevent false positive events that might otherwise occur when content in a subsequent packet matches a rule whose state is no longer valid. The following example illustrates how you can get false positives when you do not include multiple state names in a group.

Consider the case where the following three rule fragments trigger in the order shown during a single session:

(msg:"JPEG transfer"; content:"image/";pcre:"/^Content-

Type\x3a(\s*|\s*\r?\n\s+)image\x2fp?jpe?g/smi";

flowbits:set,http.jpeg; flowbits:noalert;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

The content and pcre keywords in the first rule fragment match a JPEG file download, flowbits:set,http.jpeg sets the http.jpeg flowbits state, and flowbits:noalert stops the rule from generating events. No event is generated because the rule’s purpose is to detect the file download and set the flowbits state so one or more companion rules can test for the state name in combination with malicious content and generate events when malicious content is detected.

The next rule fragment detects a GIF file download subsequent to the JPEG file download above:

(msg:"GIF transfer"; content:"image/"; pcre:"/^Content-

Type\x3a(\s*|\s*\r?\n\s+)image\x2fgif/smi";

flowbits:set,http.tif,image_downloads; flowbits:noalert;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

The content and pcre keywords in the second rule match the GIF file download, flowbits:set,http.tif sets the http.tif flowbit state, and flowbits:noalert stops the rule from generating an event. Note that the http.jpeg state set by the first rule fragment is still set even though it is no longer needed; this is because the JPEG download must have ended if a subsequent GIF download has been detected.

The third rule fragment is a companion to the first rule fragment:

(msg:"JPEG exploit";

flowbits:isset,http.jpeg;content:"|FF|"; pcre:"

/\xFF[\xE1\xE2\xED\xFE]\x00[\x00\x01]/";)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

In the third rule fragment, flowbits:isset,http.jpeg determines that the now-irrelevant http.jpeg state is set, and content and pcre match content that would be malicious in a JPEG file but not in a GIF file. The third rule fragment results in a false positive event for a nonexistent exploit in a JPEG file.

flowbits Example for Preventing False Positives

The following example illustrates how including state names in a group and using the setx operator can prevent false positives.

Consider the same case as the previous example, except that the first two rules now include their two different state names in the same state group.

(msg:"JPEG transfer"; content:"image/";pcre:"/^Content-

Type\x3a(\s*|\s*\r?\n\s+)image\x2fp?jpe?g/smi";

flowbits:setx,http.jpeg,image_downloads; flowbits:noalert;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

When the first rule fragment detects a JPEG file download, the flowbits:setx,http.jpeg,image_downloads keyword sets the flowbits state to http.jpeg and includes the state in the image_downloads group.

The next rule then detects a subsequent GIF file download:

(msg:"GIF transfer"; content:"image/"; pcre:"/^Content-

Type\x3a(\s*|\s*\r?\n\s+)image\x2fgif/smi";

flowbits:setx,http.tif,image_downloads; flowbits:noalert;)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

When the second rule fragment matches the GIF download, the flowbits:setx,http.tif,image_downloads keyword sets the http.tif flowbits state and unsets http.jpeg, the other state in the group.

The third rule fragment does not result in a false positive:

(msg:"JPEG exploit";

flowbits:isset,http.jpeg;content:"|FF|"; pcre:"/

\xFF[\xE1\xE2\xED\xFE]\x00[\x00\x01]/";)

The following diagram illustrates the effect of the flowbits keyword in the preceding rule fragment:

Because flowbits:isset,http.jpeg is false, the rules engine stops processing the rule and no event is generated, thus avoiding a false positive even in a case where content in the GIF file matches exploit content for a JPEG file.

Generating Events on the HTTP Encoding Type and Location

License: Protection

You can use the http_encode keyword to generate events on the type of encoding in an HTTP request or response before normalization, either in the HTTP URI, in non-cookie data in an HTTP header, in cookies in HTTP requests headers, or set-cookie data in HTTP responses.

You must configure the HTTP Inspect preprocessor to inspect HTTP responses and HTTP cookies to return matches for rules using the http_encode keyword. See Decoding HTTP Traffic and Selecting Server-Level HTTP Normalization Options for more information.

Also, you must enable both the decoding and alerting option for each specific encoding type in your HTTP Inspect preprocessor configuration for the http_encode keyword in an intrusion rule to trigger events on that encoding type. See Selecting Server-Level HTTP Normalization Encoding Options for more information.

Note that the base36 encoding type has been deprecated. For backward compatibility, the base36 argument is allowed in existing rules, but it does not cause the rules engine to inspect base36 traffic.

Table 36-59 http_encode Encoding Types

Encoding Type

Description

utf8

Detects UTF-8 encoding in the specified location when this encoding type is enabled for decoding by the HTTP Inspect preprocessor.

double_encode

Detects double encoding in the specified location when this encoding type is enabled for decoding by the HTTP Inspect preprocessor.

non_ascii

Detects non-ASCII characters in the specified location when non-ASCII characters are detected but the detected encoding type is not enabled.

uencode

Detects Microsoft %u encoding in the specified location when this encoding type is enabled for decoding by the HTTP Inspect preprocessor.

bare_byte

Detects bare byte encoding in the specified location when this encoding type is enabled for decoding by the HTTP Inspect preprocessor.

To identify the HTTP encoding type and location in an intrusion rule:

Access: Admin/Intrusion Admin

Step 1 Add the http_encode keyword to a rule.

Step 2 From the Encoding Location drop-down list, select whether to search for the specified encoding type in an HTTP URI, header, or cookie, including a set-cookie.

Step 3 Specify one or more encoding types using one of the following formats:

encode_type

encode_type|encode_type|encode_type...

!encode_type

where encode_type is one of the following:

utf8, double_encode, non_ascii, uencode, bare_byte

Note that you cannot use the negation (!) and OR (|) operators together.

Step 4 Optionally, add multiple http_encode keywords to the same rule to AND the conditions for each. For example, enter two keywords with the following conditions:

First http_encode keyword:

- Encoding Location : HTTP UR I

- Encoding Type : utf8

Additional http_encode keyword:

- Encoding Location : HTTP URI

- Encoding Type : uencode

The example configuration searches the HTTP URI for UTF-8 AND Microsoft IIS %u encoding.

Detecting File Types and Versions

License: Protection

The file_type and file_group keywords allow you to detect files transmitted via FTP, HTTP, SMTP, IMAP, POP3, and NetBIOS-ssn (SMB) based on their type and version. Do not use more than one file_type or file_group keyword in a single intrusion rule.

Tip Updating your vulnerability database (VDB) populates the rule editor with the most up-to-date file types, versions, and groups. For more information, see Updating the Vulnerability Database.

Table 36-60 file_type and file_group Intrusion Event Generation

Transmission Protocol

Required Preprocessor or Preprocessor Option

FTP

FTP/Telnet preprocessor and the Normalize TCP Payload inline normalization preprocessor option; see Decoding FTP and Telnet Traffic and Normalizing Inline Traffic.

HTTP

HTTP Inspect preprocessor; see Decoding HTTP Traffic.

SMTP

SMTP preprocessor; see Decoding SMTP Traffic.

IMAP

IMAP preprocessor; see Decoding IMAP Traffic.

POP3

POP preprocessor; see Decoding POP Traffic.

NetBIOS-ssn (SMB)

the SMB File Inspection DCE/RPC preprocessor option; see Decoding DCE/RPC Traffic.

For more information, see the following sections:

- file_type

- file_group

file_type

The file_type keyword allows you to specify the file type and version of a file detected in traffic. File type arguments (for example, JPEG and PDF) identify the format of the file you want to find in traffic.

Note Do not use the file_type keyword with another file_type or file_group keyword in the same intrusion rule.

The system selects Any Version by default, but some file types allow you to select version options (for example, PDF version 1.7) to identify specific file type versions you want to find in traffic.

To view and configure the most up-to-date file types and versions, update your VDB. For more information, see Updating the Vulnerability Database.

To select file types and versions in an intrusion rule:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select file_type from the drop-down list and click Add Option.

The file_type keyword appears.

Step 2 Select one or more file types from the drop-down list. Selecting a file type automatically adds the argument to the rule.

) next to the file type you want to remove.

Step 3 Optionally, customize the target versions for each file type. The system selects Any Version by default, but some file types allow you to select individual target versions.

Note Updating your VDB populates the rule editor with the most up-to-date file types and versions. If you select Any Version, the system configures your rule to include new versions when they are added in later VDB updates.

file_group

The file_group keyword allows you to select a Cisco-defined group of similar file types to find in traffic (for example, multimedia or audio). File groups also include Cisco-defined versions for each file type in the group.

Note Do not use the file_group keyword with another file_group or file_type keyword in the same intrusion rule.

To view and configure the most up-to-date file groups, update your VDB. For more information, see Updating the Vulnerability Database.

To select a file group in an intrusion rule:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select file_group from the drop-down list and click Add Option.

The file_group keyword appears.

Step 2 Optionally, to view version information for the file types in a group, hover your pointer over the file group and click on (Show Version Info).

The file group information expands to show the versions.

Step 3 Select a file group to add to the rule.

Pointing to a Specific Payload Type

License: Protection

The file_data keyword provides a pointer that serves as a reference for the positional arguments available for other keywords such as content, byte_jump, byte_test, and pcre. The detected traffic determines the type of data the file_data keyword points to. You can use the file_data keyword to point to the beginning of the following payload types:

- HTTP response body

To inspect HTTP response packets, the HTTP Inspect preprocessor must be enabled and you must configure the preprocessor to inspect HTTP responses. See Decoding HTTP Traffic and Inspect HTTP Responses in Selecting Server-Level HTTP Normalization Options for more information. The file_data keyword matches if the HTTP Inspect preprocessor detects HTTP response body data.

- Uncompressed gzip file data

To inspect uncompressed gzip files in the HTTP response body, the HTTP Inspect preprocessor must be enabled and you must configure the preprocessor to inspect HTTP responses and to decompress gzip-compressed files in the HTTP response body. For more information, see Decoding HTTP Traffic, and the Inspect HTTP Responses and Inspect Compressed Data options in Selecting Server-Level HTTP Normalization Options. The file_data keyword matches if the HTTP Inspect preprocessor detects uncompressed gzip data in the HTTP response body.

- Normalized JavaScript

To inspect normalized JavaScript data, the HTTP Inspect preprocessor must be enabled and you must configure the preprocessor to inspect HTTP responses. See Decoding HTTP Traffic and Inspect HTTP Responses in Selecting Server-Level HTTP Normalization Options for more information. The file_data keyword matches if the HTTP Inspect preprocessor detects JavaScript in response body data.

- SMTP payload

To inspect the SMTP payload, the SMTP preprocessor must be enabled. See Configuring SMTP Decoding for more information. The file_data keyword matches if the SMTP preprocessor detects SMTP data.

- Encoded email attachments in SMTP, POP, or IMAP traffic

To inspect email attachments in SMTP, POP, or IMAP traffic, the SMTP, POP, or IMAP preprocessor, respectively, must be enabled, alone or in any combination. Then, for each enabled preprocessor, you must ensure that the preprocessor is configured to decode each attachment encoding type that you want decoded. The attachment decoding options that you can configure for each preprocessor are: Base64 Decoding Depth, 7-Bit/8-Bit/Binary Decoding Depth, Quoted-Printable Decoding Depth, and Unix-to-Unix Decoding Depth. See Decoding IMAP Traffic, Decoding POP Traffic, and Decoding SMTP Traffic for more information.

You can use multiple file_data keywords in a rule.

To point to the beginning of a specific payload type:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select file_data from the drop-down list and click Add Option.

The file_data keyword appears.

The file_data keyword has no arguments.

Pointing to the Beginning of the Packet Payload

License: Protection

The pkt_data keyword provides a pointer that serves as a reference for the positional arguments available for other keywords such as content, byte_jump, byte_test, and pcre.

When normalized FTP, telnet, or SMTP traffic is detected, the pkt_data keyword points to the beginning of the normalized packet payload. When other traffic is detected, the pkt_data keyword points to the beginning of the raw TCP or UDP payload.

The following normalization options must be enabled for the system to normalize the corresponding traffic for inspection by intrusion rules:

- To normalize FTP traffic for inspection, you must enable the FTP and Telnet preprocessor Detect Telnet Escape codes within FTP commands option; see Configuring Server-Level FTP Options.

- To normalize telnet traffic for inspection, you must enable the FTP & Telnet preprocessor Normalize telnet option; see Understanding Telnet Options.

- To normalize SMTP traffic for inspection, you must enable the SMTP preprocessor Normalize option; see Understanding SMTP Decoding.

You can use multiple pkt_data keywords in a rule.

To point to the beginning of the packet payload:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select pkt_data from the drop-down list and click Add Option.

The pkt_data keyword appears.

The pkt_data keyword has no arguments.

Decoding and Inspecting Base64 Data

License: Protection

You can use the base64_decode and base64_data keywords in combination to instruct the rules engine to decode and inspect specified data as Base64 data. This can be useful, for example, for inspecting Base64-encoded HTTP Authentication request headers and Base64-encoded data in HTTP PUT and POST requests.

These keywords are particularly useful for decoding and inspecting Base64 data in HTTP requests. However, you can also use them with any protocol such as SMTP that uses the space and tab characters the same way HTTP uses these characters to extend a lengthy header line over multiple lines. When this line extension, which is known as folding, is not present in a protocol that uses it, inspection ends at any carriage return or line feed that is not followed with a space or tab.

See the following sections for more information:

- base64_decode

- base64_data

base64_decode

License: Protection

The base64_decode keyword instructs the rules engine to decode packet data as Base64 data. Optional arguments let you specify the number of bytes to decode and where in the data to begin decoding.

You can use the base64_decode keyword once in a rule; it must precede at least one instance of the base64_data keyword. See base64_data for more information.

Before decoding Base64 data, the rules engine unfolds lengthy headers that are folded across multiple lines. Decoding ends when the rules engine encounters any the following:

- the end of a header line

- the specified number of bytes to decode

- the end of the packet

Table 36-61 Optional base64_decode Arguments

Argument

Description

Bytes

Specifies the number of bytes to decode. When not specified, decoding continues to the end of a header line or the end of the packet payload, whichever comes first. You can specify a positive, non-zero value.

Offset

Determines the offset relative to the start of the packet payload or, when you also specify Relative, relative to the current inspection location. You can specify a positive, non-zero value.

Relative

Specifies inspection relative to the current inspection location.

To decode Base64 data:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select base64_decode from the drop-down list and click Add Option.

The base64_decode keyword appears.

Step 2 Optionally, select any of the arguments described in the Optional base64_decode Arguments table.

base64_data

License: Protection

The base64_data keyword provides a reference for inspecting Base64 data decoded using the base64_decode keyword. The base64_data keyword sets inspection to begin at the start of the decoded Base64 data. Optionally, you can then use the positional arguments available for other keywords such as content or byte_test to further specify the location to inspect.

You must use the base64_data keyword at least once after using the base64_decode keyword; optionally, you can use base64_data multiple times to return to the beginning of the decoded Base64 data.

Note the following when inspecting Base64 data:

- You cannot use the fast pattern matcher; see Use Fast Pattern Matcher for more information.

- If you interrupt Base64 inspection in a rule with an intervening HTTP content argument, you must insert another base64_data keyword in the rule before further inspecting Base64 data; see HTTP Content Options for more information.

To inspect decoded Base64 data:

Access: Admin/Intrusion Admin

Step 1 On the Create Rule page, select base64_data from the drop-down list and click Add Option.

The base64_data keyword appears.

Constructing a Rule

License: Protection

Just as you can create your own custom standard text rules, you can also modify existing standard text rules and shared object rule provided by Cisco and save your changes as a new rule. Note that for shared object rules provided by Cisco, you are limited to modifying rule header information such as the source and destination ports and IP addresses. You cannot modify the rule keywords and arguments in a shared object rule.

See the following sections for more information:

- Writing New Rules

- Modifying Existing Rules

- Adding Comments to Rules

- Deleting Custom Rules

Writing New Rules

License: Protection

You can create your own standard text rules.

In a custom standard text rule, you set the rule header settings and the rule keywords and arguments. Optionally, you can use the rule header settings to focus the rule to only match traffic using a specific protocol and traveling to or from specific IP addresses or ports.

After you create a new rule, you can find it again quickly using the rule number, which has the format GID:SID:Rev. The rule number for all standard text rules starts with 1. The second part of the rule number, the Snort ID (SID) number, indicates whether the rule is a local rule or a rule provided by Cisco. When you create a new rule, the system assigns the rule the next available Snort ID number for a local rule and saves the rule in the local rule category. Snort ID numbers for local rules start at 1,000,000 (although intrusion rules created on the secondary Defense Center in a high availability pair begin with the number 1,000,000,000) and the SID for each new local rule is incremented by one. The last part of the rule number is the revision number. For a new rule, the revision number is one. Each time you modify a custom rule the revision number increments by one.

Note The system assigns a new SID to any custom rule in an intrusion policy that you import. For more information, see Importing and Exporting Configurations.

To write a custom standard text rule using the rule editor:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 In the Message field, enter the message you want displayed with the event.

For details on event messages, see Defining the Event Message.

Tip You must specify a rule message. Also, the message cannot consist of white space only, one or more quotation marks only, one or more apostrophes only, or any combination of just white space, quotation marks, or apostrophes.

Step 4 From the Classification list, select a classification to describe the type of event.

For details on available classifications, see Defining the Intrusion Event Classification.

Step 5 From the Action list, select the type of rule you would like to create. You can use one of the following:

- Select alert to create a rule that generates an event when traffic triggers the rule.

- Select pass to create a rule that ignores traffic that triggers the rule.

Step 6 From the Protocol list, select the traffic protocol (tcp, udp, icmp, or ip) of packets you want the rule to inspect.

For more information about selecting a protocol type, see Specifying Protocols.

Step 7 In the Source IPs field, enter the originating IP address or address block for traffic that should trigger the rule. In the Destination IPs field, enter the destination IP address or address block for traffic that should trigger the rule.

For more detailed information about the IP address syntax that the rule editor accepts, see Specifying IP Addresses In Intrusion Rules.

Step 8 In the Source Port field, enter the originating port numbers for traffic that should trigger the rule. In the Destination Port field, enter the receiving port numbers for traffic that should trigger the rule.

Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip.

For more detailed information about the port syntax that the rule editor accepts, see Defining Ports in Intrusion Rules.

Step 9 From the Direction list, select the operator that indicates which direction of traffic you want to trigger the rule. You can use one of the following:

- Directional to match traffic that moves from the source IP address to the destination IP address

- Bidirectional to match traffic that moves in either direction

Step 10 From the Detection Options list, select the keyword that you want to use.

Step 11 Click Add Option.

Step 12 Enter any arguments that you want to specify for the keyword you added. For more information about rule keywords and how to use them, see Understanding Keywords and Arguments in Rules.

When adding keywords and arguments, you can also perform the following:

- To reorder keywords after you add them, click the up or down arrow next to the keyword you want to move.

- To delete a keyword, click the X next to that keyword.

Repeat steps 10 through 12 for each keyword option you want to add.

Step 13 Click Save As New to save the rule.

The system assigns the rule the next available Snort ID (SID) number in the rule number sequence for local rules and saves it in the local rule category.

The system does not begin evaluating traffic against new or changed rules until you enable them within the appropriate intrusion policy, and then apply the intrusion policy as part of an access control policy. See Applying an Access Control Policy for more information.

Modifying Existing Rules

License: Protection

You can modify custom standard text rules. You can also modify a standard text rule or shared object rule provided by Cisco and create one or more new instances of the rule by saving it.

Creating a rule or modifying a Cisco rule copies the new rule or revision to the local rule category and assigns the rule the next available Snort ID (SID) greater than 100000.

You can only modify header information for a shared object rule. You cannot modify the rule keywords used in a shared object rule or their arguments. Modifying header information for a shared object rule and saving your changes creates a new instance of the rule with a generator ID (GID) of 3 and the next available SID for a custom rule. The Rule Editor links the new instance of the shared object rule to the reserved soid keyword, which maps the rule you create to the rule created by the VRT. You can delete instances of a shared object rule that you create, but you cannot delete shared object rules provided by Cisco. See Understanding Rule Headers and Deleting Custom Rules for more information.

Note Do not modify the protocol for a shared object rule; doing so would render the rule ineffective.

To modify a rule:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Locate the rule or rules you want to modify. You have the following options:

- To locate rules by browsing rule categories, navigate through the folders to the rule you want and click the edit icon (

) next to the rule.

- To locate rules by searching for them, enter the search criteria (most simply, the SID) for the rule or rules you want and click Search . Click a rule returned by the search as appropriate. See Searching for Rules for more information.

- To locate a rule or rules by filtering the rules displayed on the page, enter a rule filter in the text box indicated by the filter icon (

) at the upper left of the rule list. Navigate to the rule you want and click the edit icon ( ) next to the rule. See Filtering Rules on the Rule Editor Page for more information.

The rule editor opens, displaying the rule you selected.

Note that if you select a shared object rule, the rule editor displays only the rule header information. A shared object rule can be identified on the Rule Editor page by a listing that begins with the number 3 (the GID), for example, 3:1000004.

Step 3 Make any modifications to the rule (see Writing New Rules for more information about rule options) and click Save As New.

The rule is saved to the local rule category.

Tip If you want to use the local modification of the rule instead of the system rule, deactivate the system rule by using the procedures at Setting Rule States and activate the local rule.

Step 4 Activate the intrusion policy by applying it as part of an access control policy as described in Applying an Access Control Policy to apply your changes.

Adding Comments to Rules

License: Protection

You can add comments to any intrusion rule. This allows you to provide additional context and information about the rule and the exploit or policy violation it identifies.

To add a comment to a rule:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Locate the rule you want to annotate. You have the following options:

- To locate a rule by browsing rule categories, navigate through the folders to the rule you want and click the edit icon (

) next to the rule.

- To locate a rule by searching for it, enter the search criteria (most simply, the SID) for the rule you want and click Search . Click the rule returned by the search as appropriate. See Searching for Rules for more information.

- To locate a rule by filtering the rules displayed on the page, enter a rule filter in the text box, which is indicated by the filter icon (

), at the upper left of the rule list. Navigate to the rule you want and click the edit icon ( ) next to the rule. See Filtering Rules on the Rule Editor Page for more information.

The rule editor appears.

Step 3 Click Rule Comment.

The Rule Comment page appears.

Step 4 Enter your comment in the text box and click Add Comment.

The comment is saved in the comment text box.

Tip You can also add and view rule comments in an intrusion event’s packet view. For more information, see Viewing Event Information.

Deleting Custom Rules

License: Protection

You can delete custom rules that are not currently enabled in an intrusion policy. You cannot delete either standard text rules or shared object rules rules provided by Cisco.

The system stores deleted rules in the deleted category, and you can use a deleted rule as the basis for a new rule. See Modifying Existing Rules for information on editing rules.

The Rules page in an intrusion policy does not display the deleted category, so you cannot enable deleted custom rules.

Note that you can also delete all local rules on the Rule Updates page. See, for example, Using One-Time Rule Updates.

See the following sections for more information:

- For information on creating custom rules, see Writing New Rules.

- For information on importing local rules, see Importing Rule Updates and Local Rule Files.

- For information on setting rule states, see Setting Rule States.

To delete custom rules:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 You have two choices:

- Click Delete Local Rules , then click OK .

All rules not currently enabled in an intrusion policy whose changes you have saved are deleted from the local rule category and moved to the deleted category.

- Navigate through the folders to the local rule category; click on the local rule category to expand it, then click the delete icon (

) next to a rule you want to delete.

The rule is deleted from the local rule category and moved to the deleted category.

Note that custom standard text rules have a generator ID (GID) of 1 (for example, 1:1000012) and custom shared object rules have a GID of 3 (for example, 3:1000005).

Tip The system also stores shared object rules that you save with modified header information in the local rule category and lists them with a GID of 3. You can delete your modified version of a shared object rule, but you cannot delete the original shared object rule.

Searching for Rules

License: Protection

The FireSIGHT System provides thousands of standard text rules, and the Cisco Vulnerability Research Team continues to add rules as new vulnerabilities and exploits are discovered. You can easily search for specific rules so that you can activate, deactivate, or edit them.

Table 36-62 Rule Search Criteria

Option

Description

Signature ID

To search for a single rule based on Snort ID (also called the Signature ID), enter a Snort ID number. To search for multiple rules, enter a comma-separated list of Snort ID numbers. This field has an 80-character limit.

Generator ID

To search for standard text rules, select 1. To search for shared object rules, select 3.

Message

To search for a rule with a specific message, enter a single word from the rule message in the Message field. For example, to search for DNS exploits, you would enter DNS, or to search for buffer overflow exploits, enter overflow.

Protocol

To search rules that evaluate traffic of a specific protocol, select the protocol. If you do not select a protocol, search results contain rules for all protocols.

Source Port

To search for rules that inspect packets originating from a specified port, enter a source port number or a port-related variable.

Destination Port

To search for rules that inspect packets destined for a specific port, enter a destination port number or a port-related variable.

Source IP

To search for rules that inspect packets originating from a specified IP address, enter a source IP address or an IP address-related variable.

Destination IP

To search for rules that inspect packets destined for a specified IP address, enter a destination IP address or an IP address-related variable.

Keyword

To search for specific keywords, you can use the keyword search options. You select a keyword and a keyword value for which to search. You can also precede the keyword value with an exclamation point (!) to match any value other than the specified value.

Category

To search for rules in a specific category, select the category from the Category list.

Classification

To search for rules that have a specific classification, select the classification name from the Classification list.

Rule State

To search for rules within a specific policy and a specific rule state, select the policy from the first Rule State list, and choose a state from the second list to search for rules set to Generate Events, Drop and Generate Events, or Disabled.

To search for specific rules:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Click Search on the toolbar.

The Search page appears.

Step 3 Add search criteria using any of the fields described in the Rule Search Criteria table.

Note You must specify at least one search criterion to search for rules.

Step 4 Perform the following steps to search for rules that contain specific keywords:

- From the drop-down list in the Keyword section, select the keyword for which to search.

For a list of each available keyword, see Understanding Keywords and Arguments in Rules.

- In the Keyword field, enter the arguments for which you want to search.

Step 5 Click Search.

The page reloads, showing a list of the rules that match your search criteria.

Step 6 To view or edit a rule (or a copy of the rule, if it is a system rule), click the hyperlinked rule message. See Modifying Existing Rules for detailed information about editing rules.

Filtering Rules on the Rule Editor Page

License: Protection

You can filter the rules on the Rule Editor page to display a subset of rules. This can be useful, for example, when you want to modify a rule or change its state but have difficulty finding it among the thousands of rules available.

When you enter a filter, the page displays any folder that includes at least one matching rule, or a message when no rule matches. Your filter can include special keywords and their arguments, character strings, and literal character strings in quotes, with spaces separating multiple filter conditions. A filter cannot include regular expressions, wild card characters, or any special operator such as a negation character (!), a greater than symbol (>), less than symbol (<), and so on.

All keywords, keyword arguments, and character strings are case-insensitive. Except for the gid and sid keywords, all arguments and strings are treated as partial strings. Arguments for gid and sid return only exact matches.

Optionally, you can expand a folder on the original, unfiltered page and the folder remains expanded when the subsequent filter returns matches in that folder. This can be useful when the rule you want to find is in a folder that contains a large number of rules.

You cannot constrain a filter with a subsequent filter. Any filter you enter searches the entire rules database and returns all matching rules. When you enter a filter while the page still displays the result of a previous filter, the page clears and returns the result of the new filter instead.

You can use the same features with rules in a filtered or unfiltered list. For example, you can edit rules in a filtered or unfiltered list on the Rule Editor page. You can also use any of the options in the context menu for the page.

See the following sections for more information:

- Using Keywords in a Rule Filter

- Using Character Strings in a Rule Filter

- Combining Keywords and Character Strings in a Rule Filter

- Filtering Rules

Using Keywords in a Rule Filter

License: Protection

Each rule filter can include one or more keywords in the format:

keyword:argument

where keyword is one of the keywords in the Rule Filter Keywords table and argument is a single, case-insensitive, alphanumeric string to search for in the specific field or fields relevant to the keyword.

Arguments for all keywords except gid and sid are treated as partial strings. For example, the argument 123 returns "12345", "41235", "45123", and so on. The arguments for gid and sid return only exact matches; for example, sid:3080 returns only SID 3080.

Tip You can search for a partial SID by filtering with one or more character strings. See Using Character Strings in a Rule Filter for more information.

Table 36-63 Rule Filter Keywords

Keyword

Description

Example

arachnids

Returns one or more rules based on all or part of the Arachnids ID in a rule reference. See Defining the Event Reference for more information.

arachnids:181

bugtraq

Returns one or more rules based on all or part of the Bugtraq ID in a rule reference. See Defining the Event Reference for more information.

bugtraq:2120

cve

Returns one or more rules based on all or part of the CVE number in a rule reference. See Defining the Event Reference for more information.

cve:2003-0109

gid

The argument 1 returns standard text rules. The argument 3 returns shared object rules. See Reading Preprocessor Generator IDs and Table 32-1 for more information.

gid:3

mcafee

Returns one or more rules based on all or part of the McAfee ID in a rule reference. See Defining the Event Reference for more information.

mcafee:10566

msg

Returns one or more rules based on all or part of the rule Message field, also known as the event message. See Defining the Event Message for more information.

msg:chat

nessus

Returns one or more rules based on all or part of the Nessus ID in a rule reference. See Defining the Event Reference for more information.

nessus:10737

ref

Returns one or more rules based on all or part of a single alphanumeric string in a rule reference or in the rule Message field. See Defining the Event Reference and Defining the Event Message for more information.

ref:MS03-039

sid

Returns the rule with the exact Signature ID. See Reading Preprocessor Generator IDs for more information.

sid:235

url

Returns one or more rules based on all or part of the URL in a rule reference. See Defining the Event Reference for more information.

url:faqs.org

Using Character Strings in a Rule Filter

License: Protection

Each rule filter can include one or more alphanumeric character strings. Character strings search the rule Message field, Signature ID, and Generator ID. For example, the string 123 returns the strings "Lotus123", "123mania", and so on in the rule message, and also returns SID 6123, SID 12375, and so on. For information on the rule Message field, see Defining the Event Message. For information on rule SIDs and GIDs, see Reading Preprocessor Generator IDs.

All character strings are case-insensitive and are treated as partial strings. For example, any of the strings ADMIN, admin, or Admin return "admin", "CFADMIN", "Administrator" and so on.

You can enclose character strings in quotes to return exact matches. For example, the literal string "overflow attempt" in quotes returns only that exact string, whereas a filter comprised of the two strings overflow and attempt without quotes returns "overflow attempt", "overflow multipacket attempt", "overflow with evasion attempt", and so on.

Combining Keywords and Character Strings in a Rule Filter

License: Protection

You can narrow filter results by entering any combination of keywords, character strings, or both, separated by spaces. The result includes any rule that matches all the filter conditions.

You can enter multiple filter conditions in any order. For example, each of the following filters returns the same rules:

- url:at login attempt cve:200

- login attempt cve:200 url:at

- login cve:200 attempt url:at

Filtering Rules

License: Protection

You can filter the rules on the Rule Editor page to display a subset of rules so you can more easily find specific rules. You can then use any of the page features, including selecting any of the features available in the context menu.

To filter for specific rules:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Rule filtering can be particularly useful on the Rule Editor page when you want to locate a rule to edit it. See Modifying Existing Rules for more information.

Step 2 Optionally, select a different grouping method from the Group Rules By list.

Tip Filtering may take significantly longer when the combined total of rules in all sub-groups is large because rules appear in multiple categories, even when the total number of unique rules is much smaller.

Step 3 Optionally, click the folder next to any group that you want to expand.

The folder expands to show the rules in that group. Note that some rule groups have sub-groups that you can also expand.

).

) that is inside the text box at the upper left of the rule list.

Step 5 Type your filter constraints and press Enter.

Your filter can include keywords and arguments, character strings with or without quotes, and spaces separating multiple conditions. See Filtering Rules on the Rule Editor Page for more information.

The page refreshes to display any group that contains at least one matching rule.

Step 6 Optionally, open any folder not already opened to display matching rules. You have the following filtering choices:

- To enter a new filter, position your cursor inside the filter text box and click to activate it; type your filter and press Enter.

- To clear the current filtered list and return to the original, unfiltered page, click the filter clearing icon (

).

Step 7 Optionally, make any changes to the rule that you would normally make on the page. See Modifying Existing Rules.

To put any changes you make into effect, apply the intrusion policy part of an access control policy as described in Applying an Access Control Policy.

Blocking Malware and Prohibited Files

Malicious software, or malware, can enter your organization’s network via multiple routes. To help you identify and mitigate the effects of malware, the FireSIGHT System’s file control, network file trajectory, and advanced malware protection components can detect, track, store, analyze, and optionally block the transmission of malware and other types of files in network traffic. The system can also analyze and act upon nested files inside archive files (such as the archive file formats .zip or .rar).

You configure the system to perform malware protection and file control as part of your overall access control configuration. File policies that you create and associate with access control rules handle network traffic that matches the rules. You can download files detected in that traffic, then submit them to Cisco’s malware awareness network (called the Collective Security Intelligence Cloud) for dynamic analysis of the file’s signatures to determine whether they contain malware.

The Context Explorer and the dashboard provide you with different types of high-level views of the files (including malware files) detected in your organization’s network traffic. To further target your analysis, you can use a malware file’s network file trajectory page to track the spread of an individual threat across hosts over time, allowing you to concentrate outbreak control and prevention efforts where most useful.

Although you can create file policies with any license, certain aspects of malware protection and file control require that you enable specific licensed capabilities on target devices, as described in the following table.

Table 37-1 License and Appliance Requirements for Intrusion and File Inspection

Feature

Description

Add this license...

To one of these Defense Centers...

And enable it on one of these devices...

intrusion prevention

detect and optionally block intrusions and exploits

Protection

Any

Any

file control

detect and optionally block the transmission of file types

Protection

Any

Any

advanced malware protection (AMP)

detect, store, track, and optionally block the transmission of malware

submit captured files to the Cisco cloud to analyze for malware

Malware

Any except DC500

Any except Series 2 or X-Series

If your organization has a FireAMP subscription, the Defense Center can also receive endpoint-based malware detection data from the public Cisco cloud. The Defense Center presents this data alongside any network-based file and malware data generated by the system. Importing FireAMP data does not require a license in addition to your FireAMP subscription. For more information, see Working with Cloud Connections for FireAMP.

For file and malware cloud-based features, you can use a FireAMP Private Cloud instead of the standard cloud connection if your organization requires additional security or wants to limit outside connections. All file and malware cloud lookups, as well as collection and relaying of event data from FireAMP endpoints, are handled through the private cloud; when the private cloud contacts the public Cisco cloud, it does so through an anonymized proxy connection that does not transmit your endpoint event data.

For more information, see:

- Understanding Malware Protection and File Control

- Understanding and Creating File Policies

- Working with Cloud Connections for FireAMP

For more information on evaluating event data related to malware protection and file control, see Analyzing Malware and File Activity.

Understanding Malware Protection and File Control

License: Protection, Malware, or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The system can detect and optionally block malware in many types of files, including PDFs, Microsoft Office documents, and others. Managed devices monitor specific application protocol-based network traffic for transmissions of those file types. When a device detects an eligible file, it can send the file’s SHA-256 hash value to the Defense Center, which then performs a malware cloud lookup using that information. Based on these results, the Cisco cloud returns a file disposition to the Defense Center.

When the system detects a file in network traffic, the file storage feature allows a device to store an eligible file to the hard drive or malware storage pack. For executable files with an Unknown disposition, the device can submit the file for dynamic analysis, regardless of whether the device stores the file. The cloud returns to the Defense Center:

- a threat score that describes the likelihood a file contains malware, and

- a dynamic analysis summary report that details why the cloud assigned the threat score.

If the file is an eligible executable file, the device can also perform a Spero analysis of the file structure and submit the resulting Spero signature to the cloud. Using this signature to supplement dynamic analysis, the cloud determines whether the file is malware.

If a file has a disposition in the cloud that you know to be incorrect, you can add the file’s SHA-256 value to a file list:

- To treat a file as if the cloud assigned a clean disposition, add the file to the clean list .

- To treat a file as if the cloud assigned a malware disposition, add the file to the custom detection list.

If the system detects a file’s SHA-256 value on a file list, it takes the appropriate action without performing a malware lookup or checking the file disposition. Note that you must configure a rule in the file policy with either a Malware Cloud Lookup or Block Malware action and a matching file type to calculate a file’s SHA value. You can enable use of the clean list or custom detection list on a per-file-policy basis. For more information on managing file lists, see Working with File Lists.

The system can inspect and block nested files inside archive files (such as .zip or .rar archive files) in much the same way as it analyzes and acts upon regular, uncompressed files. Note, however, that if your system blocks any nested file, it blocks the entire archive file that contains it. The system can inspect up to 3 levels of nested files beneath the outermost archive file (which is level 0). You can configure your file policy to block archive files that exceed a specified level of nesting (up to a maximum of 3 levels).

You can also configure your file policy to block archive files whose contents are encrypted or otherwise unable to be inspected. For more information on archive file inspection, see Configuring Archive File Inspection Options.

To inspect or block files, you must enable a Protection license on the managed devices where you apply policies. To store files, perform malware cloud lookups on and optionally block malware files, submit files to the cloud for dynamic analysis, or add files to a file list, you must also enable a Malware license for those devices.

Understanding File Dispositions

The system determines file dispositions based on the disposition returned by the Cisco cloud. A file can have one of the following file dispositions returned by the Cisco cloud, as a result of addition to a file list, or due to threat score:

- Malware indicates that the cloud categorized the file as malware, or that the file’s threat score exceeded the malware threshold defined in the file policy.

- Clean indicates that the cloud categorized the file as clean, or that a user added the file to the clean list.

- Unknown indicates that a malware cloud lookup occurred before the cloud assigned a disposition. The cloud has not categorized the file.

- Custom Detection indicates that a user added the file to the custom detection list.

- Unavailable indicates that the Defense Center could not perform a malware cloud lookup. You may see a small percentage of events with this disposition; this is expected behavior.

Tip If you see several Unavailable malware events in quick succession, check your cloud connection and port configuration. For more information, see Security, Internet Access, and Communication Ports.

Table 37-2 Archive File Disposition by Contents

Archive File Disposition

Number of Unknown Files

Number of Clean Files

Number of Malware Files

Unknown

1 or more

Any

0

Clean

0

1 or more

0

Malware

Any

Any

1 or more

Based on the file disposition, the Defense Center instructs the managed device either to block the file or to allow its upload or download. Note that if any nested file inside an archive file is blocked, the system blocks the entire archive file. To improve performance, if the system already knows the disposition for a file based on its SHA-256 value, the Defense Center uses the cached disposition rather than querying the Cisco cloud.

Note that file dispositions can change. For example, the cloud can determine that a file that was previously thought to be clean is now identified as malware, or the reverse—that a malware-identified file is actually clean. When the disposition changes for a file for which you performed a malware lookup in the last week, the cloud notifies the Defense Center so the system can take appropriate action the next time it detects that file being transmitted. A changed file disposition is called a retrospective disposition.

File dispositions returned from a malware cloud lookup, and any associated threat scores, have a time-to-live (TTL) value. After a file disposition has been held for the duration specified in the TTL value without update, the system purges the cached information. Dispositions and associated threat scores have the following TTL values:

- Clean — 4 hours

- Unknown — 1 hour

- Malware — 1 hour

If a malware cloud lookup against the cache identifies a cached disposition that timed out, the system performs a fresh lookup to determine a file disposition.

Understanding File Control

If your organization wants to block not only the transmission of malware files, but all files of a specific type (regardless of whether the files contain malware), the file control feature allows you to cast a wider net. As with malware protection, managed devices monitor network traffic for transmissions of specific file types, then either block or allow the file.

File control is supported for all file types where the system can detect malware, plus many additional file types. These file types are grouped into basic categories, including multimedia (swf, mp3), executables (exe, torrent), and PDFs. Note that file control, unlike malware protection, does not require queries of the Cisco cloud.

Using Captured Files, File Events, and Malware Events for Analysis

The system generates malware and file events when files are transferred or blocked. It also collects information on any files captured by a managed device. You can view these events and information using the Defense Center‘s web interface. Additionally, the Context Explorer and the dashboard provide you with different types of high-level views of the files (including malware files) detected by your organization.

To further target your analysis, the network file trajectory feature allows you to track individual files’ paths of transmission. A file’s trajectory page displays summary information about the file, a graphical map of the file’s transmission from host to host (including blocked transmissions), and a list of the malware or file events associated with the detection or blocking of those files.

Note that because you cannot use a Malware license with a DC500, nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture or block individual files, submit files for dynamic analysis, or view file trajectories for files for which you conduct a malware cloud lookup.

For more information, see the following sections:

- Configuring Malware Protection and File Control

- Logging Events Based on Malware Protection and File Control

- Integrating FireAMP with the FireSIGHT System

- Network-Based AMP vs Endpoint-Based FireAMP

- Working with Network File Trajectory

Configuring Malware Protection and File Control

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

You configure malware protection and file control as part of your overall access control configuration by associating file policies with access control rules. This association ensures that before the system passes a file in traffic that matches an access control rule’s conditions, it first inspects the file.

A file policy, like its parent access control policy, contains rules that determine how the system handles files that match the conditions of each rule. You can configure separate file rules to take different actions for different file types, application protocols, or directions of transfer.

When a file matches a rule, the rule can:

- allow or block files based on simple file type matching

- block files based on malware file disposition

- capture files and store them to the device

- submit captured files for dynamic analysis

In addition, the file policy can:

- automatically treat a file as if it is clean or malware based on entries in the clean list or custom detection list

- treat a file as if it is malware if the file’s threat score exceeds a configurable threshold

- inspect the contents of archive files (such as .zip or .rar )

- block archive files whose contents are encrypted, nested beyond a specified maximum archive depth, or otherwise not inspectable

As a simple example, you could implement a file policy that blocks your users from downloading executable files. As another example, you could examine downloaded PDFs for malware and block any instances you find. For detailed information on file policies and associating them with access control rules, see Understanding and Creating File Policies and Tuning Intrusion Prevention Performance.

Because you cannot use a Malware license with a DC500, you cannot use that appliance to apply file policies that perform network-based malware protection or inspect the contents of archive files. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy to those appliances that performs network-based malware protection or inspects the contents of archive files.

Logging Events Based on Malware Protection and File Control

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Defense Center logs records of the system’s file inspection and handling as captured files, file events, and malware events:

- Captured files represent files that the system captured.

- File events represent files that the system detected, and optionally blocked, in network traffic.

- Malware events represent malware files detected, and optionally blocked, in network traffic by the system.

- Retrospective malware events represent files whose malware file dispositions have changed.

When the system generates a malware event based on detection or blocking of malware in network traffic, it also generates a file event, because to detect malware in a file the system must first detect the file itself. Note that endpoint-based malware events generated by FireAMP Connectors (see Integrating FireAMP with the FireSIGHT System) do not have corresponding file events. Similarly, when the system captures a file in network traffic, it also generates a file event because the system first detected the file.

You can use the Defense Center to view, manipulate, and analyze captured files, file events, and malware events, then communicate your analysis to others. The Context Explorer, dashboards, event viewer, network file trajectory map, and reporting features can give you a deeper understanding of the files and malware detected, captured, and blocked. You can also use events to trigger correlation policy violations, or alert you via email, SMTP, or syslog. For detailed information on file and malware events, see Working with File Events and Working with Malware Events.

Because you cannot use a Malware license with a DC500, nor can you enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to generate or analyze captured files, file events, and malware events associated with malware cloud lookups or with the contents of archive files.

Integrating FireAMP with the FireSIGHT System

License: Any

FireAMP is Cisco’s enterprise-class advanced malware analysis and protection solution that discovers, understands, and blocks advanced malware outbreaks, advanced persistent threats, and targeted attacks.

If your organization has a FireAMP subscription, individual users install FireAMP Connectors on endpoints: computers and mobile devices. A FireAMP Connector is a lightweight agent that, among other capabilities, can inspect files upon upload, download, execution, open, copy, move, and so on. These connectors communicate with the Cisco cloud to determine if inspected files contain malware.

When a file is positively identified as malware, the cloud sends the threat identification to the Defense Center. The cloud can also send other kinds of information to the Defense Center, including data on scans, quarantines, blocked executions, and cloud recalls. The Defense Center logs this information as malware events.

With a FireAMP deployment, you can not only configure Defense Center-initiated remediations and alerts based on malware events, but you can also use the FireAMP portal (http://amp.sourcefire.com/) to help you mitigate the effect of malware. The portal provides a robust, flexible web interface where you control all aspects of your FireAMP deployment and manage all phases of an outbreak. You can:

- configure custom malware detection policies and profiles for your entire organization, as well as perform flash and full scans on all your users’ files

- perform malware analysis, including view heat maps, detailed file information, network file trajectory, and threat root causes

- configure multiple aspects of outbreak control, including automatic quarantines, application blocking to stop non-quarantined executables from running, and exclusion lists

- create custom protections, block execution of certain applications based on group policy, and create custom whitelists

For more information, see the following sections:

- Network-Based AMP vs Endpoint-Based FireAMP compares the malware protection strategies available in the Cisco family of products.

- Working with Cloud Connections for FireAMP explains how to establish communications between the Defense Center and the Cisco cloud, either directly or via a FireAMP Private Cloud connection.

Tip For detailed information on FireAMP, refer to the online help on the FireAMP portal.

Network-Based AMP vs Endpoint-Based FireAMP

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The following diagram shows how you can use the Defense Center to work with data from both a network-based advanced malware protection strategy and an endpoint-based FireAMP strategy.

Note that because FireAMP malware detection is performed at the endpoint at download or execution time, while managed devices detect malware in network traffic, the information in the two types of malware events is different. For example, endpoint-based malware events contain information on file path, invoking client application, and so on, while malware detections in network traffic contain port, application protocol, and originating IP address information about the connection used to transmit the file.

As another example, for network-based malware events, user information represents the user most recently logged into the host where the malware was destined, as determined by network discovery. On the other hand, FireAMP-reported users represent the user currently logged into the endpoint where the malware was detected, as determined by the local connector.

Note The IP addresses reported in endpoint-based malware events may not be in your network map—and may not even be in your monitored network. Depending on your deployment, network architecture, level of compliance, and other factors, the endpoints where connectors are installed may not be the same hosts as those monitored by your managed devices.

Note that because you cannot use a Malware license with a DC500, nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture or block individual files, submit files for dynamic analysis, inspect the contents of archive files, or view trajectories of files for which you conduct a malware cloud lookup.

The following table summarizes the differences between the two strategies.

Table 37-3 Network vs Endpoint-Based Malware Protection Strategies

Feature

Network-Based

Endpoint-Based (FireAMP)

file type detection and blocking method (file control)

in network traffic, using access control and file policies

not supported

malware detection and blocking method

in network traffic, using access control and file policies

on individual endpoints, using an installed connector that communicates with the Cisco cloud

network traffic inspected

traffic passing through a managed device

none; connectors installed on endpoints directly inspect files

malware detection robustness

limited file types

all file types

malware analysis choices

Defense Center-based, plus analysis in the cloud

Defense Center-based, plus additional options on the FireAMP portal

malware mitigation

malware blocking in network traffic, Defense Center-initiated remediations

FireAMP-based quarantine and outbreak control options, Defense Center-initiated remediations

events generated

file events, captured files, malware events, and retrospective malware events

malware events

information in malware events

basic malware event information, plus connection data (IP address, port, and application protocol)

in-depth malware event information; no connection data

network file trajectory

Defense Center-based

Defense Center-based, plus additional options on the FireAMP portal

required licenses or subscriptions

Protection license to perform file control; Malware license to perform malware protection

FireAMP subscription (not license-based)

Understanding and Creating File Policies

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The policy has two access control rules, both of which use the Allow action and are associated with file policies. The policy’s default action is also to allow traffic, but without file policy inspection. In this scenario, traffic is handled as follows:

- Traffic that matches Rule 1 is inspected by File Policy A .

- Traffic that does not match Rule 1 is evaluated against Rule 2 . Traffic that matches Rule 2 is inspected by File Policy B .

- Traffic that does not match either rule is allowed; you cannot associate a file policy with the default action.

A file policy, like its parent access control policy, contains rules that determine how the system handles files that match the conditions of each rule. You can configure separate file rules to take different actions for different file types, application protocols, or directions of transfer.

Once a file matches a rule, the rule can:

- allow or block files based on simple file type matching

- block files based on Malware file disposition

- store captured files to the device

- submit captured files for dynamic analysis

In addition, the file policy can:

- automatically treat a file as if it is clean or malware based on entries in the clean list or custom detection list

- treat a file as if it is malware if the file’s threat score exceeds a configurable threshold

- inspect the contents of archive files (such as .zip or .rar )

- block archive files whose contents are encrypted, nested beyond a specified maximum archive depth, or otherwise not inspectable

You can associate a single file policy with an access control rule whose action is Allow, Interactive Block, or Interactive Block with reset. The system then uses that file policy to inspect network traffic that meets the conditions of the access control rule. By associating different file policies with different access control rules, you have granular control over how you identify and block files transmitted on your network. Note, however, that you cannot use a file policy to inspect traffic handled by the access control default action. For detailed information, see Inspecting Allowed Traffic For Intrusions and Malware.

File Rules

Table 37-4 File Rule Components

File Rule Component

Description

application protocol

The system can detect and inspect files transmitted via FTP, HTTP, SMTP, IMAP, POP3, and NetBIOS-ssn (SMB). To improve performance, you can restrict file detection to only one of those application protocols on a per-file rule basis.

direction of transfer

You can inspect incoming FTP, HTTP, IMAP, POP3, and NetBIOS-ssn (SMB) traffic for downloaded files; you can inspect outgoing FTP, HTTP, SMTP, and NetBIOS-ssn (SMB) traffic for uploaded files.

file categories and types

The system can detect various types of files. These file types are grouped into basic categories, including multimedia (swf, mp3), executables (exe, torrent), and PDFs. You can configure file rules that detect individual file types, or on entire categories of file types.

For example, you could block all multimedia files, or just ShockWave Flash (swf) files. Or, you could configure the system to alert you when a user downloads a BitTorrent (torrent) file.

Caution Adding or removing a file type or file category restarts the Snort process when you apply your changes, temporarily interrupting traffic. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Caution Frequently triggered file rules can affect system performance. For example, detecting multimedia files in HTTP traffic (YouTube, for example, transmits significant Flash content) could generate an overwhelming number of events.

file rule action

A file rule’s action determines how the system handles traffic that matches the conditions of the rule.

Note File rules are evaluated in rule-action, not numerical, order. For more information, see the next section, File Rule Actions and Evaluation Order.

File Rule Actions and Evaluation Order

Each file rule has an associated action that determines how the system handles traffic that matches the conditions of the rule. You can set separate rules within a file policy to take different actions for different file types, application protocols, or directions of transfer. The rule actions are as follows, in rule-action order:

- Block Files rules allow you to block specific file types.

- Block Malware rules allow you to calculate the SHA-256 hash value of specific file types, then use a cloud lookup process to first determine if files traversing your network contain malware, then block files that represent threats.

- Malware Cloud Lookup rules allow you to log the malware disposition of files traversing your network based on a cloud lookup, while still allowing their transmission.

- Detect Files rules allow you to log the detection of specific file types to the database, while still allowing their transmission.

Caution Changing a file rule action to or from Detect Files or Block Malware, or enabling or disabling Store FIles, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic.

For each file rule action, you can configure options to reset the connection when a file transfer is blocked, store captured files to the managed device, and submit captured files to the cloud for dynamic and Spero analysis. The following table details the options available to each file action.

Table 37-5 File Rule Actions

Action

Resets Connection?

Stores Files?

Dynamic Analysis?

Spero Analysis for MSEXE?

Block Files

yes (recommended)

yes, you can store all matching file types

no

no

Block Malware

yes (recommended)

yes, you can store file types matching the file dispositions you select

yes, you can submit executable files with unknown file dispositions

yes, you can submit executable files

Detect Files

no

yes, you can store all matching file types

no

no

Malware Cloud Lookup

no

yes, you can store file types matching the file dispositions you select

yes, you can submit executable files with unknown file dispositions

yes, you can submit executable files

File and Malware Detection, Capture, and Blocking Notes and Limitations

Note the following details and limitations on file and malware detection, capture, and blocking behavior:

- If an end-of-file marker is not detected for a file, regardless of transfer protocol, the file will not be blocked by a Block Malware rule or the custom detection list. The system waits to block the file until the entire file has been received, as indicated by the end-of-file marker, and blocks the file after the marker is detected.

- If the end-of-file marker for an FTP file transfer is transmitted separately from the final data segment, the marker will be blocked and the FTP client will indicate that the file transfer failed, but the file will actually completely transfer to disk.

- FTP transfers commands and data over different channels. In a passive or inline tap mode deployment, the traffic from an FTP data session and its control session may not be load-balanced to the same Snort.

- If a file matches a rule with an application protocol condition, file event generation occurs after the system successfully identifies a file’s application protocol. Unidentified files do not generate file events.

- For an access control policy using a file policy with Block Malware rules for FTP, if you set the default action to an intrusion policy with Drop when Inline disabled, the system generates events for detected files or malware matching the rules, but does not drop the files. To block FTP fire transfers and use an intrusion policy as the default action for the access control policy where you select the file policy, you must select an intrusion policy with Drop when Inline enabled.

- File rules with Block Files and Block Malware actions block automatic resumption of file download via HTTP by blocking new sessions with the same file, URL, server, and client application detected for 24 hours after the initial file transfer attempt occurs.

- In rare cases, if traffic from an HTTP upload session is out of order, the system cannot reassemble the traffic correctly and therefore will not block it or generate a file event.

- If you transfer a file over NetBIOS-ssn (such as an SMB file transfer) that is blocked with a Block Files rule, you may see a file on the destination host. However, the file is unusable because it is blocked after the download starts, resulting in an incomplete file transfer.

- If you create file rules to detect or block files transferred over NetBIOS-ssn (such as an SMB file transfer), the system does not inspect files transferred in an established TCP or SMB session started before you apply an access control policy invoking the file policy so those files will not be detected or blocked.

- A rule configured to block files in a passive deployment does not block matching files. Because the connection continues to transmit the file, if you configure the rule to log the beginning of the connection, you may see multiple events logged for this connection.

- If the total number of bytes for all file names for files in a POP3, POP, SMTP, or IMAP session exceeds 1024, file events from the session may not reflect the correct file names for files that were detected after the file name buffer filled.

- When transmitting text-based files over SMTP, some mail clients convert newlines to the CRLF newline character standard. Since Mac-based hosts use the carriage return (CR) character and Unix/Linux-based hosts use the line feed (LF) character, newline conversion by the mail client can modify the size of the file. Note that some mail clients default to newline conversion when processing an unrecognizable file type.

- Cisco recommends that you enable Reset Connection for the Block Files and Block Malware actions to prevent blocked application sessions from remaining open until the TCP connection resets. If you do not reset connections, the client session will remain open until the TCP connection resets itself.

- If a file rule is configured with a Malware Cloud Lookup or Block Malware action and the Defense Center cannot establish connectivity with the cloud, the system cannot perform any configured rule action options until cloud connectivity is restored.

- If you are monitoring high volumes of traffic, do not store all captured files, or submit all captured files for dynamic analysis. Doing so can negatively impact system performance.

Note Until a file is detected and blocked in a session, packets from the session may be subject to intrusion inspection.

File Rule Evaluation Example

Table 37-6 File Rule Evaluation Order Example

App. Protocol

Direction

Action

Action Options

Result

SMTP

Upload

Block Files

Reset Connection

Blocks users from emailing PDF files and resets the connection.

FTP

Download

Block Malware

Store Files with Unknown Disposition, Reset Connection

Blocks the download of malware PDF files via file transfer, stores files with an Unknown file disposition to the device, and resets the connection.

POP3

IMAP

Download

Malware Cloud Lookup

Store Files with Unknown Disposition, Dynamic Analysis

Inspects PDF files received via email for malware, and stores files with an Unknown file disposition to the device. Submits the files to the Cisco cloud for dynamic analysis.

Any

Any

Detect Files

none

Detects and logs, but allows the traffic, when users view PDF files on the web (that is, via HTTP).

) to designate conflicting file rules. For details, hover your pointer over a warning icon.

Note that you cannot perform malware analysis on all file types detected by the system. After you select values from the Application Protocol, Direction of Transfer, and Action drop-down lists, the system constrains the list of file types.

Note that because you cannot use a Malware license with a DC500, you cannot create file rules that use the Block Malware or Malware Cloud Lookup action or use that appliance to apply file policies that contain rules with those actions. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy containing rules with those actions to those appliances.

Logging Captured Files, File Events, Malware Events and Alerts

When you associate a file policy with an access control rule, the system automatically enables file and malware event logging for matching traffic. If the file policy is configured to capture and store files, the system also automatically enables captured file logging when a file is captured. When the system inspects a file, it can generate the following types of events:

- file events , which represent detected or blocked files, and detected malware files

- malware events , which represent detected malware files

- retrospective malware events , which are generated when the Malware file disposition for a previously detected file changes

When a file policy generates a file or malware event, or captures a file, the system automatically logs the end of the associated connection to the Defense Center database, regardless of the logging configuration of the invoking access control rule.

Note File events generated by inspecting NetBIOS-ssn (SMB) traffic do not immediately generate connection events because the client and server establish a persistent connection. The system generates connection events after the client or server ends the session.

For each of these connection events:

- The Files field contains an icon (

) that indicates the number of files (including malware files) detected in the connection; click the icon to see a list of those files and, for malware files, their file dispositions.

- The Reason field indicates the reason the connection event was logged, which depends on the file rule action:

- File Monitor for Detect Files and Malware Cloud Lookup file rules and for files on the clean list

- File Block for Block Files or Block Malware file rules

- File Custom Detection if the system encountered a file on the custom detection list

- File Resume Allow where file transmission was originally blocked by a Block Files or Block Malware file rule. After a new access control policy was applied that allowed the file, the HTTP session automatically resumed.

- File Resume Block where file transmission was originally allowed by a Detect Files or Malware Cloud Lookup file rule. After a new access control policy was applied that blocked the file, the HTTP session automatically stopped.

- For connections where a file or malware was blocked, the Action is Block.

As with any kind of event generated by the FireSIGHT System, you can view, manipulate, and analyze file and malware events using the Defense Center’s web interface. You can also use malware events to trigger correlation policy violations, or alert you via email, SMTP, or syslog.

Note The Defense Center can also receive malware events using your organization’s FireAMP subscription. Because these malware events are generated on endpoints at download or execution time, their information is different from that in network-based malware events.

For more information on connection, file, and malware events, as well as additional details on how they are logged, see:

- Logging Connections in Network Traffic

- Working with File Events

- Working with Malware Events

- Understanding Connection and Security Intelligence Data

Internet Access and High Availability

The system uses port 443 to perform malware cloud lookups for network-based AMP. You must open that port outbound on the Defense Center.

Although they share file policies and related configurations, Defense Centers in a high availability pair share neither cloud connections nor captured files, file events, and malware events. To ensure continuity of operations, and to ensure that detected files’ malware dispositions are the same on both Defense Centers, both primary and secondary Defense Centers must have access to the cloud.

To submit files to the cloud for dynamic analysis, you must also open port 443 outbound on the device.

Note Note that the FireAMP Private Cloud requires the same open ports and has the same high availability limitations as the public Cisco cloud connection.

Managing File Policies

You create, edit, delete, and compare file policies on the File Policies page (Policies > Files), which displays a list of existing file policies along with their last-modified dates.

) for a file policy displays a dialog box that tells you which access control policies use the file policy, then redirects you to the Access Control Policy page. This is because you cannot apply a file policy independently, as a file policy is considered part of its parent access control policies. To use a new file policy, or to apply changes made to an existing file policy, you must apply or reapply the parent access control policies.

Note the following:

- The system checks the cloud for updates to the list of file types eligible for dynamic analysis (no more than once a day). If the list of eligible file types changes, this constitutes a change in the file policy; any access control policy using the file policy is marked out-of-date if applied to any devices. You must reapply the parent access control policy to apply the updated file policy to the device.

- You cannot delete a file policy used in a saved or applied access control policy.

For more information on managing file policies, see the following sections:

- Creating a File Policy

- Working with File Rules

- Comparing Two File Policies

Creating a File Policy

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

After you create a file policy and populate it with rules, you can use it in an access control policy.

Note that because you cannot use a Malware license with a DC500, you cannot create file rules that use the Block Malware or Malware Cloud Lookup action or use that appliance to apply file policies that contain rules with those actions. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy containing rules with those actions to those appliances.

To create a file policy:

Access: Admin/Access Admin

Step 1 Select Policies > Files.

The File Policies page appears.

Step 2 Click New File Policy.

The New File Policy dialog box appears.

For a new policy, the web interface indicates that the policy is not in use. If you are editing an in-use file policy, the web interface tells you how many access control policies use the file policy. In either case, you can click the text to jump to the Access Control Policies page; see Getting Started with Access Control Policies.

Step 3 Enter a Name and optional Description for your new policy, then click Save.

The File Policy Rules tab appears.

Step 4 Add one or more rules to the file policy.

File rules give you granular control over which file types you want to log, block, or scan for malware. For information on adding file rules, see Working with File Rules.

Because you cannot use a Malware license with a DC500, you cannot create file rules that use the Block Malware or Malware Cloud Lookup action or use that appliance to apply file policies that contain rules with those actions. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy containing rules with those actions to those appliances.

Step 5 Configure the advanced options. See Configuring Advanced File Policy General Options and Configuring Archive File Inspection Options for more information.

Step 6 Click Save.

To use your new policy, you must add the file policy to an access control rule, then apply the access control policy. If you are editing an existing file policy, you must reapply any access control policies that use the file policy.

Working with File Rules

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

To be effective, a file policy must contain one or more rules. You create, edit, and delete rules on the File Policy Rules page, which appears when you create a new file policy or edit an existing policy. The page lists all the rules in the policy, along with each rule’s basic characteristics.

The page also notifies you of how many access control policies use this file policy. You can click the notification to display a list of the parent policies and, optionally, continue to the Access Control Policies page.

Caution Adding or removing a file type or file category, changing a file rule action to or from Detect Files or Block Malware, or enabling or disabling Store FIles, restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To create a file rule:

Access: Admin/Access Admin

Step 1 Select Policies > Files.

The File Policies page appears.

Step 2 You have the following options:

- To add rules to a new policy, click New File Policy to create a new policy; see Creating a File Policy.

- To add rules to an existing policy, click the edit icon (

) next to the policy.

Step 3 On the File Policy Rules page that appears, click Add File Rule.

The Add File Rule dialog box appears.

Step 4 Select an Application Protocol.

Any, the default, detects files in HTTP, SMTP, IMAP, POP3, FTP, and NetBIOS-ssn (SMB) traffic.

Step 5 Select a Direction of Transfer.

You can inspect the following types of incoming traffic for downloaded files:

- HTTP

- IMAP

- POP3

- FTP

- NetBIOS-ssn (SMB)

You can inspect the following types of outgoing traffic for uploaded files:

- HTTP

- FTP

- SMTP

- NetBIOS-ssn (SMB)

Use Any to detect files over multiple application protocols, regardless of whether users are sending or receiving.

Step 6 Select a file rule Action. See the File Rule Actions table for more information.

When you select either Block Files or Block Malware, Reset Connection is enabled by default. To not reset the connection where a blocked file transfer occurs, clear the option.

Note Cisco recommends that you leave Reset Connection enabled to prevent blocked application sessions from remaining open until the TCP connection resets.

For detailed information on file rule actions, see File Rule Actions and Evaluation Order.

Note that because you cannot use a Malware license with a DC500, you cannot create file rules that use the Block Malware or Malware Cloud Lookup action or use that appliance to apply file policies that contain rules with those actions. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy containing rules with those actions to those appliances.

Step 7 Select one or more File Types. Use the Shift and Ctrl keys to select multiple file types. You can filter the list of file types in the following ways:

- Select one or more File Type Categories .

- Search for a file type by its name or description. For example, type Windows in the Search name and description field to display a list of Microsoft Windows-specific files.

Tip Hover your pointer over a file type to view its description.

The file types that you can use in a file rule vary depending on your selections for Application Protocol, Direction of Transfer, and Action.

For example, selecting Download as the Direction of Transfer removes GIF, PNG, JPEG, TIFF, and ICO from the Graphics category to prevent an excess of file events.

Step 8 Add the selected file types to the Selected Files Categories and Types list:

- Click Add to add selected file types to the rule.

- Drag and drop one or more file types into the Selected Files Categories and Types list.

- With a category selected, click All types in selected Categories , then either click Add or drag and drop that selection to the Selected Files Categories and Types list.

Step 9 Click Save.

The file rule is added to the policy. If you are editing an existing file policy, you must reapply any access control policies that use the file policy for your changes to take effect.

Configuring Advanced File Policy General Options

License: Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

In a file policy, you can set the following advanced options in the General section. For information on advanced Archive File Inspection options, see Configuring Archive File Inspection Options.

Table 37-7 Advanced File Policy General Options

Field

Description

Default Value

Enable Custom Detection List

Select this to block files on the custom detection list when detected.

enabled

Enable Clean List

Select this to allow files on the clean list when detected.

enabled

Mark files as malware based on dynamic analysis threat score

Select a threshold value to automatically treat files with that threat score or higher as if they are malware. Select Disabled to disable this.

Note that as you select lower threshold values, you increase the number of files treated as malware. Depending on the action selected in your file policy, this can result in an increase of blocked files.

Very High

(76 and above)

Note that because you cannot use a Malware license with a DC500, you cannot use or modify these settings. Similarly, because you cannot enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot apply a file policy with these settings enabled.

To configure advanced file policy general options:

Access: Admin/Access Admin

Step 1 Select Policies > Files.

The File Policies page appears.

) next to the policy you want to edit.

The File Policy Rule page appears.

Step 3 Select the Advanced tab.

The Advanced tab appears.

Step 4 In the General section, modify the options as described in the Advanced File Policy General Options table.

Step 5 Click Save.

You must reapply any access control policies that use the file policy you edited.

Configuring Archive File Inspection Options

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

Archive files (such as .zip or .rar) often appear in monitored traffic. Some are just a convenient way to compress and transfer legitimate information; others may try to conceal malware or other undesirable files. You can configure your file policy to inspect the contents of archive files, allowing you to analyze and, optionally, block archive files according to your organization’s needs. All features applicable to uncompressed files (such as dynamic analysis and file storage) are available for nested files inside archive files. You can view the contents of an archive file from the event viewer or file trajectory viewer using the context menu; for more information, see the following section, Viewing the Contents of Archived Files.

Note If traffic that contains an archive file is blacklisted or whitelisted by Security Intelligence, or if the top-level archive file’s SHA-256 value is on the custom detection list, the system does not inspect the contents of the archive file. If a nested file is blacklisted, the entire archive is blocked; however, if a nested file is whitelisted, the archive is not automatically passed (depending on any other nested files and characteristics). For more information, see Working with the Global Whitelist and Blacklist.

Some archive files contain additional archive files (and so on). The level at which a file is nested is its archive file depth. Note that the top-level archive file is not considered in the depth count; depth begins at 1 with the first nested file. Although the system can only inspect up to 3 levels of nested archive files, you can configure your file policy to block archive files that exceed that depth (or a lower maximum depth that you specify). If you want to restrict nested archives further, you have the option to configure a lower maximum file depth of 2 or 1. If you choose not to block files that exceed the maximum archive file depth of 3, when archive files that contain some extractable contents and some contents nested at a depth of 3 or greater appear in monitored traffic, the system examines and reports data only for the files it was able to inspect.

Archive files receive file dispositions based on the dispositions of the files they contain. All archives that contain identified malware files receive a disposition of Malware. Archives without identified malware files receive a disposition of Unknown if they contain any unknown files, and a disposition of Clean if they contain only clean files. For more information about file dispositions, see Understanding File Dispositions.

Table 37-8 Archive File Inspection Options

Field

Description

Default Value

Inspect Archives

Select this to inspect the contents of archive files. If this option is unselected, the options below are grayed out and unavailable.

Caution Enabling or disabling archive file inspection restarts the Snort process when you apply your changes, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

Disabled

Block Encrypted Archives

Select this to block archive files that have encrypted contents.

Disabled

Block Uninspectable Archives

Select this to block archive files with contents that the system is unable to inspect for reasons other than encryption (this usually applies to files corrupted in some way, or those that exceed your specified maximum archive depth).

Enabled

Max Archive Depth

Specify the maximum depth of nested archive files. Archive files that exceed this depth are blocked. The value must be 1, 2, or 3. The top-level archive file is not considered in this count; depth begins at 1 with the first nested file.

2

To configure archive file inspection options:

Access: Admin/Access Admin

Step 1 Select Policies > Files.

The File Policies page appears.

) next to the policy you want to edit.

The File Policy Rule page appears.

Step 3 Select the Advanced tab.

The Advanced tab appears.

Step 4 In the Archive File Inspection section, modify the options as described in the Archive File Inspection Options.

Step 5 Click Save.

You must reapply any access control policies that use the file policy you edited.

Viewing the Contents of Archived Files

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

If your file policy is configured to inspect archive file contents, you can use the event viewer context menu and the network file trajectory viewer to view information about the files inside an archive when the archive file appears in a file event, malware event, or as a captured file.

For more information, see:

- Using the Context Menu

- Viewing File Events

- Viewing Malware Events

- Viewing Captured Files

- Reviewing Network File Trajectory

. In each case, the window that appears is the same. The following graphic is an example of an Archive Contents window.

All file contents of the archive are listed in table form, with a short summary of their relevant information: name, SHA-256 hash value, type, category, and archive depth. A network file trajectory icon appears by each file, which you can click to view further information about that specific file with the Network Trajectory feature.

To view the contents of an archived file from the event viewer:

Access: Admin/Access Admin

Step 1 Navigate to your chosen event viewer. You have three options:

- For malware events, select Analysis > Files > Malware Events .

- For file events, select Analysis > Files> File Events .

- For captured files, select Analysis > Files > Captured Files .

The first page of your default events workflow appears.

Step 2 Right-click the table row in which the archive file you want to examine appears.

The context menu appears.

Step 3 From the context menu, click View Archive Contents.

The Archive Contents window appears.

To view the contents of an archived file from the file trajectory viewer:

Access: Admin/Access Admin

Step 1 Select Analysis > Files > Network File Trajectory.

The Network File Trajectory List page appears.

) for the archive file you want to examine.

The file trajectory page for that file appears.

).

The Archive Contents window appears.

Comparing Two File Policies

License: Protection

To review policy changes for compliance with your organization’s standards or to optimize system performance, you can examine the differences between any two file policies, or two revisions of the same policy.

The file policy comparison view displays two file policies or revisions in a side-by-side format, with the time of last modification and the last user to modify displayed next to each policy name. Differences between the two policies are highlighted:

- Blue indicates that the highlighted setting is different in the two policies, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy but not the other.

, which is a PDF version of the comparison view.

To compare two file policies:

Access: Admin/Access Admin

Step 1 Select Policies > Files.

The File Policies page appears.

Step 2 Click Compare Policies.

The Select Comparison dialog box appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select either Running Configuration or Other Policy . The practical difference between the two options is that if you select Running Configuration , the system limits one of your comparison choices to the set of currently applied file policies.

- To compare revisions of the same policy, select Other Revision .

The dialog box refreshes, displaying your comparison options.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare: Policy A or Target/Running Configuration A , and Policy B .

- If you are comparing revisions of the same policy, select the Policy you want to use, then select the two revisions: Revision A and Revision B . Revisions are listed by date and user name.

Step 5 Click OK.

The comparison view appears.

Step 6 Optionally, click Comparison Report to generate the access control policy comparison report.

The comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Working with Cloud Connections for FireAMP

License: Any

FireAMP is Cisco’s enterprise-class advanced malware analysis and protection solution. If your organization has a FireAMP subscription, individual users install FireAMP Connectors on their computers and mobile devices. These lightweight agents communicate with the Cisco cloud, which in turn communicates with the Defense Center. After you configure the Defense Center to connect to the cloud, you can receive records of scans, malware detections, and quarantines. The records are stored in the Defense Center database as malware events. For more information, see Understanding Malware Protection and File Control.

If your organization’s security policy does not allow for the use of a traditional cloud server connection, you can acquire and configure Cisco’s private, on-premises cloud solution, the FireAMP Private Cloud, which is a virtual machine that acts as a compressed, local version of the public Cisco cloud. In this case, data and actions that usually involve a cloud connection (such as events from FireAMP connectors, file disposition lookups, retrospective events, and so on) are instead handled by a local connection to your private cloud. When connections to the external cloud are necessary (such as for file disposition lookups), the private cloud acts as an anonymized proxy between your Defense Center and the public Cisco cloud. With a private cloud, no endpoint event data is shared over an external connection. For more information on configuring a private cloud, see Working with the FireAMP Private Cloud.

Note The private cloud does not support dynamic analysis.

Hosts where FireAMP Connectors are installed can also generate indications of compromise (IOC) tags when endpoint-based malware detection activity detected on that host suggests that the host’s security may be compromised. To view endpoint IOC information for a host from a Defense Center, that host must appear in the Defense Center’s network map. Cisco occasionally develops new IOC types for endpoint-based malware events, which your system automatically downloads from the Cisco cloud. For more information on indications of compromise, see Understanding Indications of Compromise and Endpoint-Based Malware Event IOC Types.

Each Defense Center in your deployment can connect to the Cisco cloud. By default, the cloud sends malware events for all groups within your organization, but you can restrict by group when you configure the connection.

Internet Access and High Availability

The system uses port 443/HTTPS to connect to the Cisco cloud (public or private) to receive endpoint-based malware events. You must open that port, both inbound and outbound, on the Defense Center. Additionally, the Defense Center must have direct access to the Internet. The default health policy includes the FireAMP Status Monitor, which warns you if the Defense Center cannot connect to the cloud after an initial successful connection, or if the connection is deregistered using the FireAMP portal.

Cloud connections to receive endpoint-based malware events are not shared between members of a high availability pair. To ensure continuity of operations, connect both the primary and secondary Defense Centers to the cloud.

Managing Cloud Connections

Use the Defense Center’s AMP Management page (AMP > AMP Management) to view and create connections to the Cisco cloud or a private cloud, as well as disable and delete those connections.

) indicates that the cloud denied the connection or the connection failed for another reason.

Tip Click any cloud name to open the FireAMP portal in a new browser window.

For more information, see:

- Creating a Cisco Cloud Connection

- Deleting or Disabling a Cloud Connection

- Working with the FireAMP Private Cloud

Creating a Cisco Cloud Connection

License: Any

Creating a connection between the Defense Center and the Cisco cloud is a two-step process. First, configure the Defense Center to connect to the cloud. Then, log into the FireAMP portal to authorize the connection. If you do not have a FireAMP subscription, you cannot complete the registration process.

By default, there is a connection to the public US Cloud that is enabled for network-based AMP. This connection is used for file lookups in file policies.

To re-register a Defense Center that was restored to factory defaults or reverted while registered to the cloud, you must connect to FireAMP and remove the Defense Center before re-registering it.

To create a Cisco cloud connection for FireAMP:

Access: Admin

Step 1 Select AMP > AMP Management.

The AMP Management page appears.

Step 2 Click Create FireAMP Connection.

The Create FireAMP Connection dialog box appears.

Step 3 From the Cloud Name drop-down box, select the cloud you want to use:

- For the European Union cloud, select EU Cloud .

- For the United States of America cloud, select US Cloud .

- For a private cloud, select Private Cloud , then follow the additional steps under Working with the FireAMP Private Cloud.

Step 4 Click Register.

Step 5 Confirm that you want to continue to the FireAMP portal, then log into the portal.

The Applications page on the portal appears. Use this page to authorize the Cisco cloud to send malware events to the Defense Center.

Step 6 Optionally, select specific groups within your organization for which you want to receive malware events.

Select groups only if you want to restrict the events you receive. By default, the Defense Center receives malware events for all groups.

Tip To manage groups, select Management > Groups on the FireAMP portal. For detailed information, refer to the online help on the portal.

Step 7 Click Allow.

You are returned to the FireAMP Management page on the Defense Center. Your connection is enabled and the Defense Center begins receiving malware events from the cloud.

Clicking Deny also returns you to the Defense Center, where the cloud connection is marked as denied. Similarly, if you navigate away from the Applications page on the FireAMP portal, and neither deny nor allow the connection, the connection is marked as pending on the Defense Center’s web interface. The health monitor does not alert in either of these situations. If you want to connect to the cloud later, you must delete the failed or pending connection, then recreate it.

Incomplete registration of an endpoint-based FireAMP connection does not disable the network-based AMP connection.

Deleting or Disabling a Cloud Connection

License: Any

Delete a Cisco cloud connection or private cloud connection if you no longer want to receive malware events from the cloud. You cannot delete the cloud connection that is enabled for network-based AMP.

To temporarily stop malware events from being sent for a particular connection, you can disable the connection rather than deleting it. In this situation, the cloud stores the events until you re-enable the connection; the cloud then sends the stored events.

Caution In rare cases — for example, with a very high event rate or a long-term disabled connection — the cloud may not be able to store all events generated while the connection is disabled.

Note that deregistering a connection using the FireAMP portal (instead of the Defense Center’s web interface) stops events from being sent, but does not remove the connection from the Defense Center. Deregistered connections show a failed state on the FireAMP Management page and you must delete them.

To enable or disable a cloud connection using the Defense Center:

Access: Admin

Step 1 On the AMP Management page, next to the connection you want to delete, click the slider, then confirm that you want to either enable or disable the connection.

When you enable a connection, the cloud begins sending events to the Defense Center, including any events that occurred while the connection was disabled. The cloud does not send events for disabled connections.

To delete a cloud connection using the Defense Center:

Access: Admin

), then confirm you want to remove the connection.

The connection is removed and the cloud stops sending events to the Defense Center.

Working with the FireAMP Private Cloud

License: Any

Your organization may have privacy or security concerns that make frequent connections between your monitored network and an external cloud server difficult or impossible. In this case, you can acquire and configure the FireAMP Private Cloud, which is a proprietary Cisco virtual machine that acts as a secure mediator between your network and the Cisco FireAMP cloud. Instead of identifiable connections from many appliances, all necessary connections to the public, external Cisco cloud are funneled through the private cloud, which acts as an anonymized proxy to ensure the security and privacy of your monitored network. Each private cloud can support as many as 10,000 separate connectors. You can configure multiple private clouds on your network to meet your organization’s needs.

The FireAMP Private Cloud handles the cloud-based actions of file disposition lookup, endpoint-based FireAMP event retrieval, and retrospective malware event generation. The private cloud, acting in place of the public cloud, collects malware events from FireAMP Connector endpoints and transmits them to the Defense Center. Only queries to the public Cisco cloud (to determine file dispositions, SHA-256 values, and so on) leave your network, through the anonymized, proxied private cloud connection. Endpoint event data never leaves your network.

For more information on cloud-based file and malware features, see:

- Understanding Malware Protection and File Control

- Integrating FireAMP with the FireSIGHT System

- Working with Dynamic Analysis

- Endpoint-Based (FireAMP) Malware Events

- Retrospective Malware Events

In this and other documentation related to the private cloud’s supported features, all references to the “cloud” or the “Cisco cloud” apply to connections through a private cloud as well, unless otherwise noted. The private cloud requires the same open ports and has the same high availability limitations as a standard cloud connection.

Note The FireAMP Private Cloud supports only malware- and file-related cloud-based features. It does not support other FireSIGHT System features that use cloud connections, such as URL filtering or Security Intelligence. The private cloud also does not support the dynamic analysis feature, although you can use the private cloud to retrieve threat scores for files that Cisco has already dynamically analyzed.

To create a connection between a Defense Center and a FireAMP Private Cloud, you must first configure your FireAMP Private Cloud according to the procedures in the FireAMP Private Cloud Administration Portal User Guide, available on the Support Site. During this configuration, make sure to note the private cloud host name that appears in the FireAMP Console field; you must have this host name to connect the private cloud to your Defense Center. Note that successfully configuring a private cloud automatically disables any public cloud connections you may have configured.

To create a connection between your Defense Center and a FireAMP Private Cloud:

Access: Admin

Step 1 Select AMP > AMP Management.

The AMP Management page appears.

Step 2 Click Create FireAMP Connection.

The Create FireAMP Connection dialog box appears.

Step 3 From the Cloud Name drop-down list, select Private Cloud.

Additional fields appear in the dialog box.

Step 4 In the Name field, type a name for your private cloud connection. This name appears in the FireAMP Cloud event field when you view malware events.

Step 5 In the Host field, type the host name of your private cloud, as displayed in the FireAMP Console field when you configured your FireAMP Private Cloud virtual machine.

Step 6 In the Certificate Upload Path field, browse to the location of a valid TLS or SSL encryption certificate information for your private cloud. For more information, see the FireAMP Private Cloud Administration Portal User Guide.

Step 7 If you have more than one private cloud configured for your monitored network and want to determine which private cloud handles network-based malware lookups, select or clear the Use For NetworkAMP check box. When only one private cloud is configured, the box is checked by default and cannot be cleared.

Step 8 If you have a proxy connection configured on your Defense Center and want to use that proxy connection for the private cloud, select the Use Proxy for Connection check box. If this option is not selected, the private cloud does not use your configured proxy for its communications.

Step 9 Click Register.

A dialog box appears to remind you that creating a private cloud configuration disables all public cloud connections you may have configured.

Step 10 Click Yes.

Confirm that you want to continue to the FireAMP portal, then log into the portal.

Step 11 The system processes your private cloud information and redirects you to the FireAMP site to complete configuration. For further instructions, please refer to the FireAMP Private Cloud Administration Portal User Guide.

Logging Connections in Network Traffic

As managed devices monitor traffic generated by the hosts on your network, they can generate logs of the connections they detect. Various settings in access control and SSL policies give you granular control over which connections you log, when you log them, and where you store the data. An access control rule’s specific logging configuration also determines whether you log file and malware events associated with the connection.

In most cases, you can log a connection at its beginning or its end, or both. When you log a connection, the system generates a connection event. You can also log a special kind of connection event, called a Security Intelligence event, whenever a connection is blacklisted (blocked) by the reputation-based Security Intelligence feature.

Connection events contain data about the detected sessions. The information available for any individual connection event depends on several factors, but in general includes:

- basic connection properties: timestamp, source and destination IP address, ingress and egress zones, the device that handled the connection, and so on

- additional connection properties discovered or inferred by the system: applications, requested URLs, or users associated with the connection, and so on

- metadata about why the connection was logged: which access control rule (or other configuration) in which policy handled the traffic, whether the connection was allowed or blocked, details about encrypted and decrypted connections, and so on

You should log connections according to the security and compliance needs of your organization. You can log any connection except those that are fast-pathed at the device level before they reach access control.

Saving connection events to the Defense Center database allows you to take advantage of many reporting, analysis, and data correlation features of the FireSIGHT System; see Working with Connection & Security Intelligence Data. Or, you can send connection data to an external system log (syslog) or SNMP trap server.

To supplement the connection data gathered by your managed devices, you can use records generated by NetFlow-enabled devices to generate connection events. This is especially useful if you have NetFlow-enabled devices deployed on networks that your FireSIGHT System managed devices cannot monitor.

Note Because NetFlow data collection is not linked to access control, you do not have granular control over which NetFlow connections you want to log. FireSIGHT System managed devices detect records exported by NetFlow-enabled devices, generate unidirectional end-of-connection events based on the data in those records, and finally send those events to the Defense Center to be logged in the database. NetFlow records cannot generate Security Intelligence events, nor be logged to an external server. For more information, see Understanding NetFlow.

For more information on logging connection data, see:

- Deciding Which Connections To Log

- Logging Security Intelligence (Blacklisting) Decisions

- Logging Encrypted Connections

- Logging Connections Based on Access Control Handling

- Logging URLs Detected in Connections

Deciding Which Connections To Log

License: Any

Using various settings in access control and SSL policies, you can log any non-fast-pathed connection that your devices monitor. In most cases, you can log a connection at its beginning or its end, or both. However, because blocked traffic is immediately denied without further inspection, in most cases you can log only beginning-of-connection events for blocked or blacklisted traffic; there is no unique end of connection to log.

When you log a connection event, you can save it to the Defense Center database for further analysis using the FireSIGHT System. Or, you can send connection data to an external syslog or SNMP trap server.

Tip To perform detailed analysis of connection data using the FireSIGHT System, Cisco recommends you log the ends of critical connections to the Defense Center database.

For more information, see:

- Logging Critical Connections

- Logging the Beginning or End of Connections

- Logging Connections to the Defense Center or External Server

- Understanding How Access Control and SSL Rule Actions Affect Logging

- License and Model Requirements for Connection Logging

Logging Critical Connections

License: Any

You should log connections according to the security and compliance needs of your organization. If your goal is to limit the number of events you generate and improve performance, only enable logging for the connections critical to your analysis. However, if you want a broad view of your network traffic for profiling purposes, you can enable logging for additional connections. Various settings in access control and SSL policies give you granular control over which connections you log, when you log them, and where you store the data.

Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for a Block rule, consider whether the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.

In addition to the logging that you configure, the system automatically logs most connections where the system detects a prohibited file, malware, or intrusion attempt. Unless you disable connection event storage entirely using the system policy, regardless of your other logging configurations, the system saves these end-of-connection events to the Defense Center database for further analysis. All connection events reflect why they were automatically logged using the Action and Reason fields; see Action and Reason.

Security Intelligence Blacklisting Decisions (Optional)

You can log a connection whenever it is blacklisted (blocked) by the reputation-based Security Intelligence feature. Optionally, and recommended in passive deployments, you can use a monitor-only setting for Security Intelligence filtering. This allows the system to further analyze connections that would have been blacklisted, but still log the match to the blacklist. Security Intelligence monitoring also allows you to create traffic profiles using Security Intelligence information.

When you enable Security Intelligence logging, blacklist matches generate Security Intelligence events as well as connection events. A Security Intelligence event is a special kind of connection event that you can view and analyze separately, and that is also stored and pruned separately. For more information, see Logging Security Intelligence (Blacklisting) Decisions.

Encrypted Connections (Optional)

You can log a connection when the system blocks an encrypted session according to the settings in an SSL policy. You can also force the system to log connections that it passes for further evaluation by access control rules, regardless of whether you decrypt the traffic, and regardless of how the system later handles or inspects the traffic. You configure this logging on a per-SSL rule basis so that you only log critical connections. For more information, see Logging Encrypted Connections.

Access Control Handling (Optional)

You can log a connection when it is handled by an access control rule or the access control default action. You configure this logging on a per-access control rule basis so that you only log critical connections. For more information, see Logging Connections Based on Access Control Handling.

Connections Associated with Intrusions (Automatic)

When an intrusion policy invoked by an access control rule (see Tuning Traffic Flow Using Access Control Rules) detects an intrusion and generates an intrusion event, the system automatically logs the end of the connection where the intrusion occurred to the Defense Center database, regardless of the logging configuration of the rule.

However, when an intrusion policy associated with the access control default action (see Setting Default Handling and Inspection for Network Traffic) generates an intrusion event, the system does not automatically log the end of the associated connection. Instead, you must explicitly enable default action connection logging. This is useful for intrusion prevention-only deployments where you do not want to log any connection data.

For connections where an intrusion was blocked, the action for the connection in the connection log is Block, with a reason of Intrusion Block, even though to perform intrusion inspection you must use an Allow rule.

Tip To disable this connection logging on Series 3 or virtual devices, use the CLI; see log-ips-connections.

Connections Associated with File and Malware Events (Automatic)

When a file policy invoked by an access control rule detects a prohibited file (including malware) and generates a file or malware event, the system automatically logs the end of the connection where the file was detected to the Defense Center database, regardless of the logging configuration of the access control rule. You cannot disable this logging.

Note File events generated by inspecting NetBIOS-ssn (SMB) traffic do not immediately generate connection events because the client and server establish a persistent connection. The system generates connection events after the client or server ends the session.

For connections where a file was blocked, the action for the connection in the connection log is Block even though to perform file and malware inspection you must use an Allow rule. The connection’s reason is either File Monitor (a file type or malware was detected), or Malware Block or File Block (a file was blocked).

Logging the Beginning or End of Connections

License: Any

When the system detects a connection, in most cases you can log it at its beginning or its end.

However, because blocked traffic is immediately denied without further inspection, in most cases you can log only beginning-of-connection events for blocked or blacklisted traffic; there is no unique end of connection to log. An exception occurs when you block encrypted traffic. When you enable connection logging in an SSL policy, the system logs end-of-connection rather than beginning-of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in the session, and thus cannot immediately block encrypted sessions.

Note For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session.

To optimize performance, log either the beginning or the end of any connection, but not both. You can trigger correlation rules based on either beginning or end-of-connection events. Note that monitoring a connection for any reason forces end-of-connection logging; see Understanding Logging for Monitored Connections.

The following table details the differences between beginning and end-of-connection events, including the advantages to logging each.

Beginning-of-Connection Events

End-of-Connection Events

Can be generated...

when the system detects the beginning of a connection (or, after the first few packets if event generation depends on application or URL identification)

when the system:

- detects the close of a connection

- does not detect the end of a connection after a period of time

- can no longer track the session due to memory constraints

Can be logged for...

all connections evaluated by Security Intelligence or access control rules, though you may not be able to configure end-of-connection logging in all places

all connections, though you may not be able to configure end-of-connection logging in all places

Contain...

only information that can be determined in the first packet (or the first few packets, if event generation depends on application or URL identification)

all information in the beginning-of-connection event, plus information determined by examining traffic over the duration of the session, for example, the total amount of data transmitted or the timestamp of the last packet in the connection

Are useful...

if you want to log:

- blocked connections, including Security Intelligence blacklisting decisions

- only the beginning of a connection because the end-of-connection information does not matter to you

if you want to:

- log encrypted connections handled by an SSL policy

- perform any kind of detailed analysis on, or trigger correlation rules using, information collected over the duration of the session

- view connection summaries (aggregated connection data) in custom workflows, view connection data in graphical format, or create and use traffic profiles

Logging Connections to the Defense Center or External Server

License: Any

You can log connection events to the Defense Center database, as well as to an external syslog or SNMP trap server. Before you can log connection data to an external server, you must configure a connection to that server called an alert response; see Working with Alert Responses.

Logging to the Defense Center database allows you to take advantage of many reporting, analysis, and data correlation features of the FireSIGHT System. For example:

- Dashboards and the Context Explorer provide you with graphical, at-a-glance views of the connections logged by the system; see Using Dashboards and Using the Context Explorer.

- Event views present detailed information on the connections logged by the system, which you can display in a graphical or tabular format or summarize in a report; see Working with Connection & Security Intelligence Data.

- Traffic profiling uses connection data to create a profile of your normal network traffic that you can then use as a baseline against which to detect and track anomalous behavior; see Creating Traffic Profiles.

- Correlation policies allow you to generate events and trigger responses (such as alerts or external remediations) to specific types of connections or traffic profile changes; see Creating Rules for Correlation Policies.

Note To use these features, you must log connections (and in most cases, the end of those connections rather than the beginning) to the Defense Center database. This is why the system automatically logs critical connections—those associated with logged intrusions, prohibited files, and malware.

The number of connection and Security Intelligence events a Defense Center can store depends on its model. For a list of those limits, and for information on disabling connection event storage, see Configuring Database Event Limits.

Understanding How Access Control and SSL Rule Actions Affect Logging

License: feature dependent

Every access control and SSL rule has an action that determines not only how the system inspects and handles the traffic that matches the rule, but also when and how you can log details about matching traffic.

Note Logging connections allowed by the access control and SSL policy default actions is handled slightly differently; see Logging Connections Handled by the Access Control Default Action and Setting Default Logging for Encrypted and Undecryptable Connections.

For more information, see:

- Using Rule Actions to Determine Traffic Handling and Inspection

- Using Rule Actions to Determine Encrypted Traffic Handling and Inspection

- Understanding Logging for Monitored Connections

- Understanding Logging for Trusted Connections

- Understanding Logging for Blocked and Interactively Blocked Connections

- Understanding Logging for Allowed Connections

- Disabling File and Malware Event Logging for Allowed Connections

Understanding Logging for Monitored Connections

License: feature dependent

The system always logs the ends of the following connections to the Defense Center database, regardless of the logging configuration of the rule or default action that later handles the connection:

- connections matching a Security Intelligence blacklist set to monitor

- connections matching an SSL Monitor rule

- connections matching an access control Monitor rule

In other words, if a packet matches a Monitor rule or Security Intelligence monitored blacklist, the connection is always logged, even if the packet matches no other rules and you do not enable logging on the default action. Whenever the system logs a connection event as the result of Security Intelligence filtering, it also logs a matching Security Intelligence event, which is a special kind of connection event that you can view and analyze separately; see Logging Security Intelligence (Blacklisting) Decisions.

Because monitored traffic is always later handled by another rule or by the default action, the action associated with a connection logged due to a monitor rule is never Monitor. Rather, it reflects the action of the rule or default action that later handles the connection; see Action.

The system does not generate a separate event each time a single connection matches an SSL or access control Monitor rule. Because a single connection can match multiple Monitor rules, each connection event logged to the Defense Center database can include and display information on the first eight Monitor access control rules that the connection matches, as well as the first matching Monitor SSL rule.

Similarly, if you send connection events to an external syslog or SNMP trap server, the system does not send a separate alert each time a single connection matches a Monitor rule. Rather, the alert that the system sends at the end of the connection contains information on the Monitor rules the connection matched.

Tip Even though the rule action in the connection log can never be Monitor, you can still trigger correlation policy violations on connections that match Monitor rules. For more information, see Specifying Correlation Rule Trigger Criteria.

Understanding Logging for Trusted Connections

License: feature dependent

A trusted connection is one that is handled by a Trust access control rule or the default action in an access control policy. You can log the beginnings and ends of these connections, however, keep in mind that trusted connections, regardless of whether they are encrypted, are not inspected for discovery data, intrusions, or prohibited files and malware. Therefore, connection events for trusted connections contain limited information.

Note that the system logs TCP connections handled by a Trust access control rule differently depending on the device that detected the connection:

- For Series 3 devices, TCP connections detected by a Trust rule on the first packet generate different events depending on the presence of a preceding enabled Monitor rule. If the Monitor rule is active, the system evaluates the packet and generates both a beginning and end-of-connection event. If no Monitor rule is active, the system only generates an end-of-connection event.

- For all other models, TCP connections detected by a Trust rule on the first packet only generate an end-of-connection event. The system generates the event one hour after the final session packet.

Understanding Logging for Blocked and Interactively Blocked Connections

License: feature dependent

When you log a blocked connection, how the system logs it depends on why the connection was blocked; this is important to keep in mind when configuring correlation rules based on connection logs:

- For SSL rules and SSL policy default actions that block encrypted traffic, the system logs end -of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in the session.

- For access control rules and access control policy default actions that block decrypted or unencrypted traffic (including interactive blocking rules), the system logs beginning -of-connection events. Matching traffic is denied without further inspection.

Connection events for sessions blocked by an access control or SSL rule have an action of Block or Block with reset. Blocked encrypted connections have a reason of SSL Block.

Interactive blocking access control rules, which cause the system to display a warning page when a user browses to a prohibited website, allow you to configure end-of-connection logging. This is because if the user clicks through the warning page, the connection is considered a new, allowed connection which the system can monitor and log; see Understanding Logging for Allowed Connections.

Therefore, for packets that match an Interactive Block or Interactive Block with reset rule, the system can generate the following connection events:

- a beginning-of-connection event when a user’s request is initially blocked and the warning page is displayed; this event has an associated action of Interactive Block or Interactive Block with reset

- multiple beginning- or end-of-connection events if the user clicks through the warning page and loads the originally requested page; these events have an associated action of Allow and a reason of User Bypass

Note that only devices deployed inline can block traffic. Because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.

Caution Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for an Block rule, consider whether the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.

Understanding Logging for Allowed Connections

License: feature dependent

Decrypt SSL rules, Do not decrypt SSL rules, and Allow access control rules permit matching traffic to pass to the next phase of inspection and traffic handling.

Regardless of whether you decrypt encrypted traffic using an SSL rule, the traffic continues to be evaluated by access control rules. If you enable logging for this SSL rule, the system logs the end of matching connections, regardless of the logging configuration of the access control rules or default action that later handles them.

When you allow traffic with an access control rule, you can use an associated intrusion or file policy (or both) to further inspect traffic and block intrusions, prohibited files, and malware before the traffic can reach its final destination. Note, however, that by default file and intrusion inspection is disabled for encrypted payloads.

Connections for traffic matching an Allow access control rule are logged as follows:

- When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion event, the system automatically logs the end of the connection where the intrusion occurred to the Defense Center database, regardless of the logging configuration of the rule.

- When a file policy invoked by an access control rule detects a prohibited file (including malware) and generates a file or malware event, the system automatically logs the end of the connection where the file was detected to the Defense Center database, regardless of the logging configuration of the access control rule.

- Optionally, you can enable beginning- and end-of-connection logging for any allowed traffic, including traffic that the system deems safe or that you do not inspect with an intrusion or file policy.

For all of the resulting connection events, the Action and Reason fields reflect why the events were logged; see Action and Reason. Note that:

- An action of Allow represents explicitly allowed and user-bypassed interactively blocked connections that reached their final destination.

- An action of Block represents a connection that was at first allowed by an access control rule, but where an intrusion, prohibited file, or malware was detected.

Disabling File and Malware Event Logging for Allowed Connections

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

When you allow unencrypted or decrypted traffic with an access control rule, you can use an associated file policy to inspect transmitted files, and block prohibited files and malware before it can reach its destination; see Tuning Intrusion Prevention Performance. Note that because you cannot use a Malware license with a DC500, nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances for malware protection.

When the system detects a prohibited file, it automatically logs one of the following types of event to the Defense Center database:

- file events , which represent detected or blocked files, including malware files

- malware events , which represent detected or blocked malware files only

- retrospective malware events , which are generated when the malware disposition for a previously detected file changes

If you do not want to log file or malware events, you can disable this logging on a per-access-control-rule basis by clearing the Log Files check box on the Logging tab of the access control rule editor. For information on disabling file and malware event storage entirely, see Configuring Database Event Limits.

Note Cisco recommends you leave file and malware event logging enabled.

Regardless of whether you save file and malware events, when network traffic violates a file policy, the system automatically logs the end of the associated connection to the Defense Center database, regardless of the logging configuration of the invoking access control rule; see Connections Associated with File and Malware Events (Automatic).

License and Model Requirements for Connection Logging

License: feature dependent

Because you configure connection logging in access control and SSL policies, you can log any connection that those policies can successfully handle.

Although you can create access control and SSL policies regardless of the licenses on your Defense Center, certain aspects of access control require that you enable specific licensed capabilities on target devices before you can apply the policy. Additionally, some features are only available on certain models.

Note that with a FireSIGHT license, which is included with your Defense Center, you can add host, user, and application data to the network map based on the information in connection logs, as well as view indications of compromise (IOC) information associated with connection events. Except on the DC500, you can also view geolocation data (source or destination country or continent) associated with connections.

The following table explains the licenses you must have to successfully configure access control, and therefore to log connections handled by an access control policy.

Table 38-2 License and Model Requirements for Connection Logging in Access Control Policies

To log connections...

License

Supported Defense Centers

Supported Devices

for traffic handled using, network, VLAN, port, or literal URL criteria

Any

Any

Any, except:

- Series 2 devices cannot perform URL filtering

- ASA FirePOWER devices cannot perform VLAN filtering

for traffic handled using geolocation data

FireSIGHT

Any except DC500

Any except Series 2 or X-Series

associated with:

- IP addresses with a poor reputation (Security Intelligence filtering)

- intrusions or prohibited files in unencrypted or decrypted traffic

Protection

Any

Any, except Series 2 devices cannot perform Security Intelligence filtering

associated with malware detected in unencrypted or decrypted traffic

Malware

Any except DC500

Any except Series 2 or X-Series

for traffic handled by user control or application control

Control

Any, except the DC500 cannot perform user control

Any except Series 2 or X-Series

for traffic that the system filters using URL category and reputation data, and to display URL category and URL reputation information for URLs requested by monitored hosts

URL Filtering

Any except DC500

Any except Series 2

The following table explains the licenses you must have to successfully configure SSL inspection, and therefore to log connections handled by an SSL policy. Keep in mind that even if an encrypted connection is not logged (or even examined) by an SSL policy, it still may be logged for other reasons.

Table 38-3 License and Model Requirements for Connection Logging in SSL Policies

To log connections...

License

Supported Defense Centers

Supported Devices

for encrypted traffic handled using zone, network, VLAN, port, or SSL-related criteria

Any

Any

Series 3

for encrypted traffic handled using geolocation data

FireSIGHT

Any except DC500

Series 3

for encrypted traffic handled using application or user criteria

Control

Any, except the DC500 cannot perform user control

Series 3

for encrypted traffic that the system filters using URL category and reputation data

URL Filtering

Any except DC500

Series 3

Logging Security Intelligence (Blacklisting) Decisions

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

As a first line of defense against malicious Internet content, the FireSIGHT System includes the Security Intelligence feature, which allows you to immediately blacklist (block) connections based on the latest reputation intelligence, removing the need for a more resource-intensive, in-depth analysis. This traffic filtering takes place before any other policy-based inspection, analysis, or traffic handling, although it does occur after hardware-level handling, such as fast-pathing.

Optionally, and recommended in passive deployments, you can use a monitor-only setting for Security Intelligence filtering. This allows the system to further analyze connections that would have been blacklisted, but still log the match to the blacklist.

Note If you want to create traffic profiles based on Security Intelligence information, or trigger correlation rules using Security Intelligence information in end-of-connection events, you must log this information to the Defense Center database. First, enable Security Intelligence logging. Then, build a blacklist using monitor-only Security Intelligence objects. For more information, see Blacklisting Using Security Intelligence IP Address Reputation.

Enabling Security Intelligence logging logs all blocked and monitored connections handled by an access control policy’s target devices. However, the system does not log whitelist matches; logging of whitelisted connections depends on their eventual disposition.

When the system logs a connection event as the result of Security Intelligence filtering, it also logs a matching Security Intelligence event, which is a special kind of connection event that you can view and analyze separately. Both types of events use the Action and Reason fields to reflect the blacklist match. Additionally, so that you can identify the blacklisted IP address in the connection, host icons next to blacklisted and monitored IP addresses look slightly different in the event viewer.

Logging Blocked Blacklisted Connections

For a blocked connection, the system logs beginning-of-connection Security Intelligence and connection events. Because blacklisted traffic is immediately denied without further inspection, there is no unique end of connection to log. For these events, the action is Block and the reason is IP Block.

IP Block connection events have a threshold of 15 seconds per unique initiator-responder pair. That is, once the system generates an event when it blocks a connection, it does not generate another connection event for additional blocked connections between those two hosts for the next 15 seconds, regardless of port or protocol.

Logging Monitored Blacklisted Connections

For connections monitored—rather than blocked—by Security Intelligence, the system logs end-of-connection Security Intelligence and connection events to the Defense Center database. This logging occurs regardless of how the connection is later handled by an SSL policy, access control rule, or the access control default action.

For these connection events, the action depends on the connection’s eventual disposition. The Reason field contains IP Monitor, as well as any other reason why the connection may have been logged.

Note that the system may also generate beginning-of-connection events for monitored connections, depending on the logging settings in the access control rule or default action that later handles the connection.

To log blacklisted connections:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select the Security Intelligence tab.

Security Intelligence settings for the access control policy appear.

).

The Blacklist Options pop-up window appears.

Step 5 Select the Log Connections check box.

Step 6 Specify where to send connection and Security Intelligence events. You have the following choices:

- To send events to the Defense Center, select Defense Center .

- To send events to an external syslog server, select Syslog , then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (

); see Creating a Syslog Alert Response.

- To send connection events to an SNMP trap server, select SNMP Trap , then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (

); see Creating an SNMP Alert Response.

You must send events to the Defense Center if you want to set blacklisted objects to monitor-only, or perform any other Defense Center-based analysis on connection events generated by Security Intelligence filtering. For more information, see Logging Connections to the Defense Center or External Server.

Step 7 Click OK to set your logging options.

The Security Intelligence tab appears again.

Step 8 Click Save.

Logging Encrypted Connections

License: SSL

Supported Devices: Series 3

As part of access control, the SSL inspection feature allows you to use an SSL policy to decrypt encrypted traffic for further evaluation by access control rules. You can force the system to log these decrypted connections, regardless of how the system later handles or inspects the traffic. You can also log connections when you block encrypted traffic, or when you allow it to pass to access control rules without decryption.

Connection logs for encrypted sessions contain details about the encryption, such as the certificate used to encrypt that session. You configure connection logging for encrypted sessions in the SSL policy on a per-SSL rule basis so that you only log critical connections.

For more information, see the following sections:

- Logging Decryptable Connections with SSL Rules

- Setting Default Logging for Encrypted and Undecryptable Connections

Logging Decryptable Connections with SSL Rules

License: SSL

Supported Devices: Series 3

Within an SSL policy, SSL rules provide a granular method of handling encrypted traffic across multiple managed devices. So that you can log only critical connections, you enable connection logging on a per-SSL-rule basis—if you enable connection logging for a rule, the system logs all connections handled by that rule.

For encrypted connections inspected by an SSL policy, you can log connection events to the Defense Center database, or to an external syslog or SNMP trap server. You can log only end-of-connection events, however:

- for blocked connections (Block, Block with reset), the system immediately ends the session and generates an event

- for monitored connections (Monitor) and connections that you pass to access control rules (Decrypt, Do not decrypt), the system generates an event when the session ends, regardless of the logging configuration of the access control rule or default action that later handles it

For more information, see Understanding How Access Control and SSL Rule Actions Affect Logging.

To log decryptable connections:

Access: Admin/Access Admin/Network Admin/Security Approver

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy you want to edit.

The SSL policy editor appears, focused on the Rules tab.

) next to the rule where you want to configure logging.

The SSL rule editor appears.

Step 4 Select the Logging tab.

The Logging tab appears.

Step 5 Select Log at End of Connection.

Step 6 Specify where to send connection events. You have the following choices:

- To send connection events to the Defense Center, select Defense Center . When your rule action is Monitor , you must log connections to the Defense Center.

- To send events to an external syslog, select Syslog , then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (

); see Creating a Syslog Alert Response.

- To send events to an SNMP trap server, select SNMP Trap , then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (

); see Creating an SNMP Alert Response.

You must send events to the Defense Center if you want to perform Defense Center-based analysis on these connection events. For more information, see Logging Connections to the Defense Center or External Server.

Step 7 Click Add to save your changes.

You must apply the access control policy the SSL policy is associated with for your changes to take effect; see Applying an Access Control Policy.

Setting Default Logging for Encrypted and Undecryptable Connections

License: SSL

Supported Devices: Series 3

You can log connections for the traffic handled by the default action of your SSL policy. These logging settings also govern how the system logs undecryptable sessions.

The SSL policy default action determines how the system handles encrypted traffic that matches none of the SSL rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic). If your SSL policy does not contain any SSL rules, the default action determines how all encrypted sessions on your network are logged. For more information, see Setting Default Handling and Inspection for Encrypted Traffic.

You can configure the SSL policy default action to log connection events to the Defense Center database, or to an external syslog or SNMP trap server. You can log only end-of-connection events, however:

- for blocked connections (Block, Block with reset), the system immediately ends the sessions and generates an event

- for connections that you allow to pass unencrypted to access control rules (Do not decrypt), the system generates an event when the session ends

Note that even if you disable logging for the SSL policy default action, end-of-connection events may still be logged to the Defense Center database if the connection previously matched at least one SSL Monitor rule, or later matches an access control rule or the access control policy default action.

To set the default handling for encrypted and undecryptable traffic:

Access: Admin/Access Admin/Network Admin/Security Approver

Step 1 Select Policies > SSL.

The SSL Policy page appears.

) next to the SSL policy you want to edit.

The SSL policy editor appears, focused on the Rules tab.

drop-down list.

The Logging pop-up window appears.

Step 4 Select Log at End of Connection to enable logging connection events.

Step 5 Specify where to send connection events. You have the following choices:

- To send connection events to the Defense Center, select Defense Center .

- To send events to an external syslog server, select Syslog , then select a syslog alert response from the drop-down list. Optionally, you can configure a syslog alert response by clicking the add icon (

); see Creating a Syslog Alert Response.

- To send events to an SNMP trap server, select SNMP Trap , then select an SNMP alert response from the drop-down list. Optionally, you can configure an SNMP alert response by clicking the add icon (

); see Creating an SNMP Alert Response.

You must send events to the Defense Center if you want to perform Defense Center-based analysis on these connection events. However, note that traffic handled by the SSL policy default action is not further inspected for intrusions, malware, or discovery data. For more information, see Logging Connections to the Defense Center or External Server.

Step 6 Click OK to save your changes.

You must apply the access control policy the SSL policy is associated with for your changes to take effect; see Applying an Access Control Policy.

Logging Connections Based on Access Control Handling

License: Any

Within an access control policy, access control rules provide a granular method of handling network traffic across multiple managed devices. So that you can log only critical connections, you enable connection logging on a per-access-control-rule basis—if you enable connection logging for a rule, the system logs all connections handled by that rule.

You can also log connections for the traffic handled by the default action of your access control policy. The default action determines how the system handles traffic that matches none of the access control rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic).

Note that even if you disable logging for all access control rules and the default action, end-of-connection events may still be logged to the Defense Center database if the connection matches an access control rule and contains an intrusion attempt, prohibited file, or malware, or if it was decrypted by the system and you enabled logging for the connection in the SSL policy.

Depending on the rule or default policy action and the associated inspection options that you configure, your logging options differ. For more information, see:

- Logging Connections Matching an Access Control Rule

- Logging Connections Handled by the Access Control Default Action

Logging Connections Matching an Access Control Rule

License: Any

To log only critical connections, you enable connection logging on a per-access-control-rule basis. If you enable logging for a rule, the system logs all connections handled by that rule.

Depending on the rule action and intrusion and file inspection configuration of the rule, your logging options differ; see Understanding How Access Control and SSL Rule Actions Affect Logging. Also, note that even if you disable logging for an access control rule, end-of-connection events for connections matching that rule may still be logged to the Defense Center database if the connection:

- contains an intrusion attempt, prohibited file, or malware

- was inspected and logged by an SSL policy

- previously matched at least one access control Monitor rule

To configure an access control rule to log connection, file, and malware information:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to modify.

The access control policy editor appears, focused on the Rules tab.

) next to the rule where you want to configure logging.

The access control rule editor appears.

Step 4 Select the Logging tab.

The Logging tab appears.

Step 5 Specify whether you want to Log at Beginning of Connection or Log at End of Connection.

To optimize performance, log either the beginning or the end of any connection, but not both.

For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session. Because blocked traffic is immediately denied without further inspection, you can log only beginning-of-connection events for Block rules.

Also note that because the purpose of a Monitor rule is to log matching traffic, end-of-connection logging to the Defense Center database is auto-enabled and you cannot disable it. For more information, see Logging the Beginning or End of Connections.

Step 6 Use the Log Files check box to specify whether the system should log any file and malware events associated with the connection.

The system automatically enables this option when you associate a file policy with the rule to perform either file control or AMP. Cisco recommends you leave this option enabled; see Disabling File and Malware Event Logging for Allowed Connections.

Step 7 Specify where to send connection events. You have the following choices:

- To send connection events to the Defense Center, select Defense Center . You cannot disable this option for Monitor rules.

- To send events to an external syslog server, select Syslog , then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (

); see Creating a Syslog Alert Response.

- To send events to an SNMP trap server, select SNMP Trap , then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (

); see Creating an SNMP Alert Response.

You must send events to the database if you want to perform Defense Center-based analysis on connection events. For more information, see Logging Connections to the Defense Center or External Server.

Step 8 Click Save to save the rule.

Your rule is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Logging Connections Handled by the Access Control Default Action

License: Any

You can log connections for the traffic handled by the default action of your access control policy. The default action determines how the system handles traffic that matches none of the access control rules in the policy (except Monitor rules, which match and log—but do not handle or inspect—traffic); see Setting Default Handling and Inspection for Network Traffic.

Table 38-4 Access Control Default Action Logging Options

Default Action

Compare To

See...

Access Control: Block All Traffic

Block rules

Understanding Logging for Blocked and Interactively Blocked Connections

Access Control: Trust All Traffic

Trust rules

Understanding Logging for Trusted Connections

Intrusion Prevention

Allow rules with associated intrusion policies

Understanding Logging for Allowed Connections

Network Discovery Only

Allow rules without associated intrusion policies

However, there are some differences between logging connections handled by access control rules versus the default action:

- The default action has no file logging options. You cannot perform file control or AMP using the default action.

- When an intrusion policy associated with the access control default action generates an intrusion event, the system does not automatically log the end of the associated connection. This is useful for intrusion detection and prevention-only deployments, where you do not want to log any connection data.

An exception to this rule occurs if you enable beginning-of-connection logging for the default action. In that case, the system does log the end of the connection when an associated intrusion policy triggers, in addition to logging the beginning of the connection.

Note that even if you disable logging for the default action, end-of-connection events for connections matching that rule may still be logged to the Defense Center database if the connection previously matched at least one access control Monitor rule, or was inspected and logged by an SSL policy.

To log connections in traffic handled by the access control default action:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to modify.

The access control policy editor appears, focused on the Rules tab.

drop-down list.

The Logging pop-up window appears.

Step 4 Specify whether you want to Log at Beginning of Connection or Log at End of Connection.

To optimize performance, log either the beginning or the end of these connections, but not both. For a single non-blocked connection, the end-of-connection event contains all of the information in the beginning-of-connection event, as well as information gathered over the duration of the session. Because blocked traffic is immediately denied without further inspection, you can log only beginning-of-connection events for the Block All Traffic default action.

Step 5 Specify where to send connection events. You have the following choices:

- To send connection events to the Defense Center, select Defense Center . You cannot disable this option for Monitor rules.

- To send events to an external syslog server, select Syslog , then select a syslog alert response from the drop-down list. Optionally, you can add a syslog alert response by clicking the add icon (

); see Creating a Syslog Alert Response.

- To send events to an SNMP trap server, select SNMP Trap , then select an SNMP alert response from the drop-down list. Optionally, you can add an SNMP alert response by clicking the add icon (

); see Creating an SNMP Alert Response.

You must send events to the database if you want to perform Defense Center-based analysis on connection events. For more information, see Logging Connections to the Defense Center or External Server.

Step 6 Click Save to save the policy.

Your policy is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Logging URLs Detected in Connections

License: FireSIGHT

When you log an end-of-connection event to the Defense Center database for HTTP traffic, the system records the URL requested by the monitored host during the session.

By default, the system stores the first 1024 characters of the URL in the connection log. However, you can configure the system to store up to 4096 characters per URL to make sure you capture the full URLs requested by monitored hosts. Or, if you are uninterested in the individual URLs visited, you can disable URL storage entirely by storing zero characters. Depending on your network traffic, disabling or limiting the number of stored URL characters may improve system performance.

Note that disabling URL logging does not affect URL filtering. Access control rules properly filter traffic based on requested URLs, their categories, and reputations, even though the system does not record the individual URLs requested in the traffic handled by those rules. For more information, see Blocking URLs.

To customize the number of URL characters you store:

Access: Admin/Access Admin/Network Admin

Step 1 Select Policies > Access Control.

The Access Control Policy page appears.

) next to the access control policy you want to configure.

The access control policy editor appears.

Step 3 Select the Advanced tab.

Advanced settings for the access control policy appear.

) next to General Settings.

The General Settings pop-up window appears.

Step 5 Type the Maximum URL characters to store in connection events.

You can specify any number from zero to 4096. Storing zero characters disables URL storage without disabling URL filtering.

Step 6 Click OK.

Advanced settings for the access control policy appear.

Step 7 Click Save to save the policy.

Your policy is saved. You must apply the access control policy for your changes to take effect; see Applying an Access Control Policy.

Working with Connection & Security Intelligence Data

As managed devices monitor traffic generated by the hosts on your network, they can generate logs of the connections they detect. Various settings in access control and SSL policies give you granular control over which connections you log, when you log them, and where you store the data. In most cases, you can log a connection at its beginning or its end, or both.

When you log a connection, the system generates a connection event. You can also log a special kind of connection event, called a Security Intelligence event, whenever a connection is blacklisted (blocked) or monitored by the reputation-based Security Intelligence feature.

Connection logs, called connection events, contain data about the detected sessions. You should log connections according to the security and compliance needs of your organization; you can log any connection except those that are fast-pathed at the device level before they reach access control.

In addition to the logging that you configure, the system automatically logs most connections where the system detects a prohibited file, malware, or intrusion attempt. Unless you disable connection event storage entirely, the system saves these end-of-connection events to the Defense Center database for further analysis. For detailed information on configuring connection logging, see Logging Connections in Network Traffic.

Note Although you can log connections using any appliance and license, the information available for any individual connection or Security Intelligence event depends on several factors, including licenses. For more information, see License and Model Requirements for Connection Logging.

To supplement the connection data gathered by your managed devices, you can use records generated by NetFlow-enabled devices to generate connection events. This is especially useful if you have NetFlow-enabled devices deployed on networks that your FireSIGHT System managed devices cannot monitor.

Note Because NetFlow data collection is not linked to access control, you do not have granular control over which NetFlow connections you want to log. FireSIGHT System managed devices detect records exported by NetFlow-enabled devices, generate unidirectional end-of-connection events based on the data in those records, and finally send those events to the Defense Center to be logged in the database. NetFlow records cannot generate Security Intelligence events, nor be logged to an external server. For more information, see Understanding NetFlow.

For more information on working with connection and Security Intelligence events, see:

- Understanding Connection and Security Intelligence Data

- Viewing Connection and Security Intelligence Data

- Working with Connection Graphs

- Working with Connection and Security Intelligence Data Tables

- Searching for Connection and Security Intelligence Data

- Viewing the Connection Summary Page

Understanding Connection and Security Intelligence Data

License: Any

Connection logs, called connection events, contain data about the detected sessions. The information available for any individual connection event depends on several factors, but in general includes:

- basic connection properties: timestamp, source and destination IP address, ingress and egress zones, the device that handled the connection, and so on

- additional connection properties discovered or inferred by the system: applications, requested URLs, or users associated with the connection, and so on

- metadata about why the connection was logged: which access control rule (or other configuration) in which policy handled the traffic, whether the connection was allowed or blocked, details about encrypted and decrypted connections, and so on

Various settings in access control and SSL policies give you granular control over which connections you log, when you log them, and where you store the data. You can log any connection that your access control and SSL policies can successfully handle, which may require specific appliance models or licensed capabilities. You can enable connection logging in the following situations:

- when a connection is blacklisted (blocked) or monitored by the reputation-based Security Intelligence feature

- when an encrypted session is handled by an SSL policy

- when a connection is handled by an access control rule or the access control default action

In addition to the logging that you configure, the system automatically logs most connections where the system detects a prohibited file, malware, or intrusion attempt. Unless you disable connection event storage entirely using the system policy, regardless of your other logging configurations, the system saves these end-of-connection events to the Defense Center database for further analysis.

Also, when you enable Security Intelligence logging, blacklist matches automatically generate Security Intelligence events as well as connection events. A Security Intelligence event is a special kind of connection event that you can view and analyze separately, and that is also stored and pruned separately. For detailed information on configuring connection logging, including Security Intelligence blacklisting decisions, see Logging Connections in Network Traffic.

Tip General information about connection events also pertains to Security Intelligence events, unless otherwise noted. For more information on Security Intelligence, see Blacklisting Using Security Intelligence IP Address Reputation.

The following sections provide additional details on the kinds of information available about detected connections:

- Understanding Connection Summaries

- Understanding Connection and Security Intelligence Data Fields

- Information Available in Connection and Security Intelligence Events

Understanding Connection Summaries

License: Any

The FireSIGHT System aggregates connection data collected over five-minute intervals into connection summaries, which the system uses to generate connection graphs and traffic profiles. Optionally, you can create custom workflows based on connection summary data, which you use in the same way as you use workflows based on individual connection events.

Note that there are no connection summaries specifically for Security Intelligence events, although corresponding end-of-connection events can be aggregated into connection summary data.

To be aggregated, multiple connections must:

- represent the end of connections

- have the same source and destination IP addresses, and use the same port on the responder (destination) host

- use the same protocol (TCP or UDP)

- use the same application protocol

- either be detected by the same Cisco managed device, or be exported by the same NetFlow-enabled device

Each connection summary includes total traffic statistics, as well as the number of connections in the summary. Because NetFlow-enabled devices generate unidirectional connections, a summary’s connection count is incremented by two for every connection based on NetFlow data.

Note that connection summaries do not contain all of the information associated with the summaries’ aggregated connections. For example, because client information is not used to aggregate connections into connection summaries, summaries do not contain client information.

For more information, see the following sections:

- Long-Running Connections

- Combined Connection Summaries from External Responders

- Information Available in Connection and Security Intelligence Events

Long-Running Connections

License: Any

If a monitored session spans two or more five-minute intervals over which connection data is aggregated, the connection is considered a long-running connection. When calculating the number of connections in a connection summary, the system increments the count only for the five-minute interval in which a long-running connection was initiated.

Also, when calculating the number of packets and bytes transmitted by the initiator and responder in a long-running connection, the system does not report the number of packets and bytes that were actually transmitted during each five-minute interval. Instead, the system assumes a constant rate of transmission and calculates estimated figures based on the total number of packets and bytes transmitted, the length of the connection, and what portion of the connection occurred during each five-minute interval.

Combined Connection Summaries from External Responders

License: Any

To reduce the space required to store connection data and speed up the rendering of connection graphs, the system combines connection summaries when:

- one of the hosts involved in the connection is not on your monitored network

- other than the IP address of the external host, the connections in the summaries meet the aggregation criteria listed in Understanding Connection Summaries: protocol, application protocol, detecting device, and so on

When viewing connection summaries in the event viewer and when working with connection graphs, the system displays external instead of an IP address for the non-monitored hosts.

As a consequence of this aggregation, if you attempt to drill down to the table view of connection data (that is, access data on individual connections) from a connection summary or graph that involves an external responder, the table view contains no information.

Understanding Connection and Security Intelligence Data Fields

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Each connection table view or connection graph contains information about the connections or connection summaries you are viewing, including timestamps, IP addresses, geolocation information, applications, and so on. Security Intelligence event views contain the same general information as connection event views, but list only connections with assigned Security Intelligence Category values.

Note The information available for any individual connection or Security Intelligence event depends on several factors, including licenses and appliance model. For more information, see License and Model Requirements for Connection Logging.

The following list details the connection data logged by the FireSIGHT System. For a discussion of the factors that determine the information logged in any individual connection or Security Intelligence event, see the next section: Information Available in Connection and Security Intelligence Events.

Access Control Policy

The access control policy that monitored the connection.

Access Control Rule

The access control rule or default action that handled the connection, as well as up to eight Monitor rules matched by that connection.

If the connection matched one Monitor rule, the Defense Center displays the name of the rule that handled the connection, followed by the Monitor rule name. If the connection matched more than one Monitor rule, the event viewer displays how many Monitor rules it matched, for example, Default Action + 2 Monitor Rules.

To display a pop-up window with a list of the first eight Monitor rules matched by the connection, click N Monitor Rules.

Action

The action associated with the access control rule or default action that logged the connection:

– Allow represents explicitly allowed and user-bypassed interactively blocked connections.

– Trust represents trusted connections. Note that the system logs TCP connections detected by a trust rule differently depending on the appliance.

On Series 2, virtual devices, and Cisco NGIPS for Blue Coat X-Series, TCP connections detected by a trust rule on the first packet only generate an end-of-connection event. The system generates the event one hour after the final session packet.

On Series 3 appliances, TCP connections detected by a trust rule on the first packet generate different events depending on the presence of a monitor rule. If the monitor rule is active, the system evaluates the packet and generates both a beginning and end-of-connection event. If no monitor rule is active, the system only generates an end-of-connection event.

– Block and Block with reset represent blocked connections. The system also associates the Block action with connections blacklisted by Security Intelligence, connections blocked by an SSL policy, connections where an exploit was detected by an intrusion policy, and connections where a file was blocked by a file policy.

– Interactive Block and Interactive Block with reset mark the beginning-of-connection event that you can log when the system initially blocks a user’s HTTP request using an Interactive Block rule. If the user clicks through the warning page that the system displays, any additional connection events you log for the session have an action of Allow.

– Default Action indicates the connection was handled by the default action.

– For Security Intelligence-monitored connections, the action is that of the first non-Monitor access control rule triggered by the connection, or the default action. Similarly, because traffic matching a Monitor rule is always handled by a subsequent rule or by the default action, the action associated with a connection logged due to a monitor rule is never Monitor.

Application Protocol

The application protocol, which represents communications between hosts, detected in the connection.

Application Risk

The risk associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated risk; this field displays the highest of those. For more information, see Table 45-2.

Business Relevance

The business relevance associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated business relevance; this field displays the lowest (least relevant) of those. For more information, see Table 45-2.

Category, Tag (Application Protocol, Client, Web Application)

Criteria that characterize the application to help you understand the application's function. For more information, see Table 45-2.

Client and Client Version

The client application and version of that client detected in the connection.

If the system cannot identify the specific client used in the connection, this field displays client appended to the application protocol name to provide a generic name, for example, FTP client.

Connections

The number of connections in a connection summary. For long-running connections, that is, connections that span multiple connection summary intervals, only the first connection summary interval is incremented.

Count

The number of connections that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Note If you create a custom workflow and do not add the Count column to a drill-down page, each connection is listed individually and packets and bytes are not summed.

Device

The managed device that detected the connection or, for connections exported by NetFlow-enabled devices, the managed device that processed the NetFlow data.

Files

) in this field. The number on the icon indicates the number of files (including malware files) detected or blocked in that connection.

Click the icon to display a pop-up window with a list of the files detected in the connection, as well as their types and if applicable, their malware lookup dispositions.

Note that neither the DC500 Defense Center nor Series 2 devices support network-based malware file detection.

For more information, see Viewing Files Detected in a Connection.

First Packet or Last Packet

The date and time the first or last packet of the session was seen.

HTTP Referrer

The HTTP referrer, which represents the referrer of a requested URL for HTTP traffic detected in the connection (such as a website that provided a link to, or imported a link from, another URL).

Ingress Interface or Egress Interface

The ingress or egress interface associated with the connection. Note that, if your deployment includes an asynchronous routing configuration, the ingress and egress interface may belong to the same interface set.

Ingress Security Zone or Egress Security Zone

The ingress or egress security zone associated with the connection.

Initiator Bytes or Responder Bytes

The total number of bytes transmitted by the session initiator or the session responder.

Initiator Country or Responder Country

When a routable IP is detected, the country associated with the host IP address that initiated the session, or with the session responder. An icon of the country’s flag is displayed, as well as the country’s ISO 3166-1 alpha-3 country code. Hover your pointer over the flag icon to view the country’s full name.

Note that the DC500 Defense Center does not support this feature.

Initiator IP or Responder IP

The host IP address (and host name, if DNS resolution is enabled) that initiated, or responded to, the session responder. So that you can identify the blacklisted IP address in a blacklisted connection, host icons next to blacklisted IP addresses look slightly different.

Initiator Packets or Responder Packets

The total number of packets transmitted by the session initiator or the session responder.

Initiator User

The user logged into the session initiator.

Intrusion Events

) in this field.

Click the icon to display a pop-up window with a list of intrusion events associated with the connection, as well as their priority and impact. For more information, see Viewing Intrusion Events Associated with a Connection.

IOC

Whether or not the event triggered an indication of compromise (IOC) against a host involved in the connection. For more information on IOC, see Understanding Indications of Compromise.

NetBIOS Domain

The NetBIOS domain used in the session.

NetFlow Destination/Source Autonomous System

For connections exported by NetFlow-enabled devices, the border gateway protocol autonomous system number for the source or destination of traffic in the connection.

NetFlow Destination/Source Prefix

For connections exported by NetFlow-enabled devices, the source or destination IP address ANDed with the source or destination prefix mask.

NetFlow Destination/Source TOS

For connections exported by NetFlow-enabled devices, the setting for the type-of-service (TOS) byte when connection traffic entered or exited the NetFlow-enabled device.

NetFlow SNMP Input/Output

For connections exported by NetFlow-enabled devices, the interface index for the interface where connection traffic entered or exited the NetFlow-enabled device.

Network Analysis Policy

The network analysis policy (NAP), if any, associated with the generation of the event.

Reason

The reason or reasons the connection was logged, in the following situations:

– User Bypass indicates that the system initially blocked a user’s HTTP request, but the user chose to continue to the originally requested site by clicking through a warning page. A reason of User Bypass is always paired with an action of Allow.

– IP Block indicates that the system denied the connection without inspection, based on Security Intelligence data. A reason of IP Block is always paired with an action of Block.

– IP Monitor indicates that the system would have denied the connection based on Security Intelligence data, but you configured the system to monitor, rather than deny, the connection.

– File Monitor indicates that the system detected a particular type of file in the connection.

– File Block indicates the connection contained a file or malware file that the system prevented from being transmitted. A reason of File Block is always paired with an action of Block.

– File Custom Detection indicates the connection contained a file on the custom detection list that the system prevented from being transmitted.

– File Resume Allow indicates that file transmission was originally blocked by a Block Files or Block Malware file rule. After a new access control policy was applied that allowed the file, the HTTP session automatically resumed. Note that this reason only appears in inline deployments.

– File Resume Block indicates that file transmission was originally allowed by a Detect Files or Malware Cloud Lookup file rule. After a new access control policy was applied that blocked the file, the HTTP session automatically stopped. Note that this reason only appears in inline deployments.

– SSL Block indicates the system blocked an encrypted connection based on the SSL inspection configuration. A reason of SSL Block is always paired with an action of Block.

– Intrusion Block indicates the system blocked or would have blocked an exploit (intrusion policy violation) detected in the connection. A reason of Intrusion Block is paired with an action of Block for blocked exploits and Allow for would-have-blocked exploits.

– Intrusion Monitor indicates the system detected, but did not block, an exploit detected in the connection. This occurs when the state of the triggered intrusion rule is set to Generate Events.

Referenced Host

If the protocol in the connection is DNS, HTTP, or HTTPS, this field displays the host name that the respective protocol was using.

Security Context

The metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

Security Intelligence Category

The name of the blacklisted object that represents or contains the blacklisted IP address in the connection. The Security Intelligence category can be the name of a network object or group, the global blacklist, a custom Security Intelligence list or feed, or one of the categories in the Intelligence Feed. Note that this field is only populated if the Reason is IP Block or IP Monitor; entries in Security Intelligence event views always display a reason. For more information, see Blacklisting Using Security Intelligence IP Address Reputation.

Note also that neither the DC500 Defense Center nor Series 2 devices support this feature.

Source Device

The IP address of the NetFlow-enabled device that exported the data for the connection. If the connection was detected by a managed device, this field contains a value of FireSIGHT.

Source Port/ICMP Type or Destination Port/ICMP Code

The port, ICMP type, or ICMP code used by the session initiator or session responder.

SSL Status

The action associated with the SSL rule, default action, or undecryptable traffic action that logged the encrypted connection:

– Block and Block with reset represent blocked encrypted connections.

– Decrypt (Resign) represents an outgoing connection decrypted using a re-signed server certificate.

– Decrypt (Replace Key) represents an outgoing connection decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Known Key) represents an incoming connection decrypted using a known private key.

– Do not Decrypt represents a connection the system did not decrypt.

If the system fails to decrypt an encrypted connection, it displays the undecryptable traffic action taken, as well as the failure reason. For example, if the system detects traffic encrypted with an unknown cipher suite and allows it without further inspection, this field displays Do Not Decrypt (Unknown Cipher Suite).

) to view certificate details. For more information, see Viewing the Certificate Associated with an Encrypted Connection.

SSL Certificate Status

If encrypted traffic matches an SSL rule, this field displays the server certificate statuses. If undecryptable traffic matches an SSL rule, this displays Not Checked. For more information, see Controlling Encrypted Traffic by Certificate Status.

SSL Flow Error

The error name and hexadecimal code if an error occurred during the SSL session; Success if no error occurred.

SSL Version

The SSL or TLS protocol version used to encrypt the connection.

SSL Cipher Suite

The cipher suite used to encrypt the connection.

SSL Policy

The SSL policy that handled the connection.

SSL Rule

The SSL rule or default action that handled the connection, as well as the first Monitor rule matched by that connection. If the connection matched a Monitor rule, the Defense Center displays the name of the rule that handled the connection, followed by the Monitor rule name.

SSL Session ID

The hexadecimal Session ID negotiated between the client and server during the SSL handshake.

SSL Ticket ID

A hexadecimal hash value of the session ticket information sent during the SSL handshake.

SSL Flow Flags

The first ten debugging level flags for an encrypted connection. To view all flags, click the ellipsis (...).

SSL Flow Messages

The messages exchanged between client and server during the SSL handshake. See http://tools.ietf.org/html/rfc5246 for more information.

TCP Flags

The TCP flags detected in the connection.

Time

The ending time of the five-minute interval that the system used to aggregate connections in a connection summary.

URL, URL Category, and URL Reputation

The URL requested by the monitored host during the session and its associated category and reputation, if available.

If the system identifies or blocks an SSL application, the requested URL is in encrypted traffic, so the system identifies the traffic based on an SSL certificate. For SSL applications, therefore, this field indicates the common name contained in the certificate.

Note that neither the DC500 Defense Center nor Series 2 devices support URL category or reputation data.

User Agent

User agent application information extracted from HTTP traffic detected in the connection.

Web Application

The web application, which represents the content or requested URL for HTTP traffic detected in the connection.

If the web application does not match the URL for the event, the traffic is probably referred traffic, such as advertisement traffic. If the system detects referred traffic, it stores the referring application (if available) and lists that application as the web application.

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The information available for any individual connection, connection summary, or Security Intelligence event depends on several factors.

Appliance Model and License

You can log any connection that your access control and SSL policies can successfully handle. However, many features require that you enable specific licensed capabilities on target devices, and many features are only available on some models.

For example, SSL inspection requires a Series 3 device. Other appliance models cannot inspect encrypted traffic; logged connection events do not contain information about encrypted connections. As another example, you cannot view geolocation data in connection events using a DC500. For more information, see License and Model Requirements for Connection Logging.

Traffic Characteristics

The system only reports information present (and detectable) in network traffic. For example, there could be no user associated with an initiator host, or no referenced host detected in a connection where the protocol is not DNS, HTTP, or HTTPS.

Detection Method: FireSIGHT System vs NetFlow

With the exception of TCP flags and NetFlow autonomous system, prefix, and TOS data, the information available in NetFlow records is more limited than the information generated by monitoring network traffic using managed devices. For more information, see Differences Between NetFlow and FireSIGHT Data.

Logging Method: Beginning or End of Connection

When the system detects a connection, whether you can log it at its beginning or its end (or both).depends on how you configure the system to detect and handle it; see Logging the Beginning or End of Connections.

Beginning-of-connection events do not have information that must be determined by examining traffic over the duration of the session (for example, the total amount of data transmitted or the timestamp of the last packet in the connection). Beginning-of-connection events are also not guaranteed to have information about application or URL traffic in the session, and do not contain any details about the session’s encryption.

Inspection Method: Associated SSL, File, and Intrusion Policies

Only encrypted connections handled by an SSL policy have SSL-related information in the connection log. Only connections logged by access control rules with associated file policies contain file information. Similarly, you must associate intrusion policies with either access control rules or the default action to view intrusion information in the connection log.

Connection Event Type: Individual vs Summary

Connection summaries do not contain all of the information associated with their aggregated connections. For example, because client information is not used to aggregate connections into connection summaries, summaries do not contain client information.

Keep in mind that connection graphs are based on connection summary data, which use only end-of-connection logs. If you logged only beginning-of-connection data, connection graphs and connection summary event views contain no data.

Other Configurations

An advanced setting in the access control policy controls the number of characters the system stores in the connection log for each URL requested by monitored hosts in HTTP sessions. If you use this setting to disable URL logging, the system does not display individual URLs in the connection log, although you can still view category and reputation data, if it exists.

Also, not all connection events have a Reason, which is a field populated only in specific situations, such as when a user bypasses an Interactive Block configuration; see Reason.

The following table lists each connection event/Security Intelligence event field and whether the system displays information in that field, depending on the detection method, logging method, and connection event type. Note that, because Security Intelligence events are never aggregated, the Summary column refers only to connection event summaries.

Tip In the table views of both connection events and Security Intelligence events, several fields are hidden by default, including the Category and Tag fields for each type of application, NetFlow-related fields, SSL-related fields, and others. To show a hidden field in an event view, expand the search constraints, then click the field name under Disabled Columns.

Table 39-1 Connection and Security Intelligence Data Based on Logging and Detection Methods

Field

Detection Method:

Logging Method:

Connection Event:

FireSIGHT

NetFlow

Beginning

End

Single

Summary

Time

yes

yes

no

yes

no

yes

First Packet

yes

yes

yes

yes

yes

no

Last Packet

yes

yes

no

yes

yes

no

Action

yes

no

yes

yes

yes

no

Reason

yes

no

yes

yes

yes

no

Initiator IP

yes

yes

yes

yes

yes

yes

Initiator Country

yes

no

yes

yes

yes

yes

Initiator User

yes

yes

yes

yes

yes

yes

Responder IP

yes

yes

yes

yes

yes

yes

Responder Country

yes

no

yes

yes

yes

yes

Security Intelligence Category

yes

no

yes

yes

yes

no

Ingress Security Zone

yes

no

yes

yes

yes

yes

Egress Security Zone

yes

no

yes

yes

yes

yes

Source Port/ICMP Code

yes

yes

yes

yes

yes

no

Destination Port/ICMP Type

yes

yes

yes

yes

yes

yes

SSL Status

yes

no

no

yes

yes

no

SSL Certificate Status

yes

no

no

yes

yes

no

SSL Version

yes

no

no

yes

yes

no

SSL Policy

yes

no

no

yes

yes

no

SSL Rule

yes

no

no

yes

yes

no

SSL Cipher Suite

yes

no

no

yes

yes

no

SSL Flow Flags

yes

no

no

yes

yes

no

SSL Flow Messages

yes

no

no

yes

yes

no

Application Protocol

yes

yes

if available

yes

yes

yes

Client

yes

no

if available

yes

yes

no

Client Version

yes

no

if available

yes

yes

no

Web Application

yes

no

if available

yes

yes

no

Category, Tag (Application Protocol, Client, Web Application)

yes

no

if available

yes

yes

no

Application Risk

yes

no

if available

yes

yes

no

Business Relevance

yes

no

if available

yes

yes

no

URL

yes

no

if available

yes

yes

no

URL Category

yes

no

if available

yes

yes

no

URL Reputation

yes

no

if available

yes

yes

no

VLAN ID

yes

no

yes

yes

yes

no

Referenced Host

yes

no

no

yes

yes

no

User Agent

yes

no

no

yes

yes

no

HTTP Referrer

yes

no

no

yes

yes

no

IOC

yes

no

yes

yes

yes

no

Intrusion Events

yes

no

no

yes

yes

no

Files

yes

no

no

yes

yes

no

Intrusion Policy

yes

no

yes

yes

yes

no

Access Control Policy

yes

no

yes

yes

yes

no

Access Control Rule

yes

no

yes

yes

yes

no

Network Analysis Policy

yes

no

yes

yes

yes

no

Device

yes

yes

yes

yes

yes

yes

Ingress Interface

yes

no

yes

yes

yes

yes

Egress Interface

yes

no

yes

yes

yes

yes

Security Context (ASA only)

yes

no

yes

yes

yes

yes

TCP Flags

no

yes

no

yes

yes

no

NetFlow Destination/Source Autonomous System

no

yes

no

yes

yes

no

NetFlow Destination/Source Prefix

no

yes

no

yes

yes

no

NetFlow Destination/Source TOS

no

yes

no

yes

yes

no

NetFlow SNMP Input/Output

no

yes

no

yes

yes

no

Source Device

yes

yes

FireSIGHT

yes

yes

yes

NetBIOS Domain

yes

no

yes

yes

yes

no

Initiator Packets

yes

yes

not useful

yes

yes

yes

Responder Packets

yes

yes

not useful

yes

yes

yes

Initiator Bytes

yes

yes

not useful

yes

yes

yes

Responder Bytes

yes

yes

not useful

yes

yes

yes

Connections

yes

yes

no

yes

no

yes

Count

yes

yes

yes

yes

yes

no

Viewing Connection and Security Intelligence Data

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

To help you gain in-depth insight into connection data, the system can present connection data both graphically and in a tabular format. The page you see when you access connection data differs depending on the workflow you use. You can use one of the predefined workflows or create a custom workflow that displays only the information that matches your specific needs.

Security Intelligence events require a Protection license and appear in table form only. Security Intelligence data is not supported on Series 2 managed devices or on DC500 Defense Centers. You cannot create data graphs from Security Intelligence events, although their connection event counterparts are viewable in graph form. For interactive graphic views of Security Intelligence data, you can view the Security Intelligence section of the Context Explorer. See Understanding the Security Intelligence Section for more information.

Note The information available for any individual connection or Security Intelligence event depends on several factors, including licenses and appliance model. For more information, see License and Model Requirements for Connection Logging.

Each table view or graph contains information about the connections or connection summaries you are viewing, including timestamps, IP addresses, applications, and so on. The information available for any individual connection detected by the FireSIGHT System depends on several factors, including detection method and logging options. For more information, see Understanding Connection and Security Intelligence Data Fields and Information Available in Connection and Security Intelligence Events.

Tip The Connection Summary dashboard can provide you with an at-a-glance view of the connections logged by the system, and the Summary Dashboard displays Security Intelligence event data. For more information, see Using Dashboards.

To view connection or Security Intelligence data:

Access: Admin/Any Security Analyst

Step 1 You have two options:

- To view connection events, select Analysis > Connections > Events .

- To view Security Intelligence events, select Analysis > Connections > Security Intelligence Events .

The first page of the default connection or Security Intelligence workflow appears. For connection events, there are two possibilities:

- The workflow page displays a graph . See Working with Connection Graphs for information on the actions you can perform.

- The workflow page displays a table . See Working with Connection and Security Intelligence Data Tables for information on the actions you can perform.

For Security Intelligence events, the workflow page displays a table.

To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Working with Connection Graphs

License: Any

One of the ways the system can present connection data is graphically. There are three different types of connection graphs: line graphs, bar graphs, and pie charts. Bar graphs and line graphs can display multiple datasets; that is, they can display several values on the y-axis for each x-axis data point.

You can manipulate connection graphs in various ways, including:

- changing the type of data that the graph displays

- switching between graph types

- constraining the graph so it shows data for specific time ranges, hosts, applications, ports, and devices

Because traffic profiles are based on connection data (see Creating Traffic Profiles), you can view traffic profiles as line graphs. You can manipulate these graphs in the same way as you would any other connection graph, with some restrictions.

You cannot create data graphs from Security Intelligence events, although their connection event counterparts are viewable in graph form. For interactive graphic views of Security Intelligence data, you can view the Security Intelligence section of the Context Explorer. See Understanding the Security Intelligence Section for more information.

Note To view traffic profiles, you must have Administrator access. Compare this with other connection graphs, which you can view with any Security Analyst or Administrator access.

When you view a connection graph, as described in Viewing Connection and Security Intelligence Data, you can perform the basic actions described in the following table.

Access: Admin/Any Security Analyst

Table 39-2 Basic Connection Graph Functions

To...

You can...

learn more about the data that appears

find more information in Understanding Connection and Security Intelligence Data Fields.

modify the time and date range

find more information in Setting Event Time Constraints.

view a host’s profile

on a graph displaying connection data by initiator or responder, click either a bar on a bar graph or a wedge on a pie chart and select View Host Profile.

use a different workflow, including a custom workflow

click (switch workflow) by the workflow title.

navigate between pages in the current workflow

find more information in Using Workflow Pages.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

There are many other ways you can manipulate connection graphs as you perform in-depth analysis of connection data. For more information, see:

- Changing the Graph Type explains how to change between bar graphs and pie chart, and between standard line graphs and velocity graphs.

- Selecting Datasets explains how to display several values on the y-axis for each x-axis data point on line graphs and bar graphs.

- Viewing Information About Aggregated Connection Data explains how to get more information about the data points on a graph, or to display the host profile of a host whose statistics are being graphed.

- Manipulating a Connection Graph on a Workflow Page explains how to constrain the data that appears on a connection graph without advancing the workflow to the next page.

- Drilling Down Through Connection Data Graphs explains how to constrain the data that appears on a connection graph while advancing the workflow to the next page.

- Recentering and Zooming on Line Graphs explains how to recenter a line graph around any point in time.

- Selecting Data to Graph explains how to change the data displayed on a connection graph by changing its x- or y-axis.

- Detaching Connection Graphs explains how you can detach a connection graph into a new browser window and perform further analysis without affecting the default time range for the Defense Center.

- Exporting Connection Data explains how to export the connection data used to construct a graph as a CSV (comma-separated values) file.

Changing the Graph Type

License: Any

There are three different connection graphs: line graphs, bar graphs, and pie charts. Line graphs plot data over time. For example, the following line graph displays the total number of connections detected on a monitored network over a one-hour time span. Traffic profiles are always displayed as line graphs.

By default, line graphs appear in standard view. A standard line graph aggregates data over five minute intervals, plots the aggregated data points, and connects the points.

However, you can change a line graph from standard view to velocity view. A velocity line graph shows the rate of change between those data points. If you change the above graph to a velocity graph, the y-axis changes from indicating the number of connections to indicating the change in the number of connections over time.

Follow the directions in the following table to switch between standard and velocity line graphs, and to switch between bar graphs and pie charts.

Access: Admin/Any Security Analyst

Table 39-3 Changing Graph Types

To change...

You can...

a bar graph to a pie chart

click Switch to Pie.

Note that pie charts cannot display multiple datasets; see Selecting Datasets.

a pie chart to a bar graph

click Switch to Bar.

a line graph from a standard graph to a velocity graph

click Velocity and select Velocity.

a line graph from a velocity graph to a standard graph

click Velocity and select Standard.

Selecting Datasets

License: Any

Both bar graphs and line graphs can display multiple datasets; that is, they can display several values on the y-axis for each x-axis data point. For example, you could display the total number of unique initiators and the total number of unique Pie charts can only display one dataset.

Table 39-4 Dataset Options

If the y-axis displays...

You can select as datasets...

Connections

the default only, which is the number of connections detected on the monitored network (Connections)

This is the only option for traffic profile graphs.

KBytes

combinations of:

- the total kilobytes transmitted on the monitored network ( Total KBytes )

- the number of kilobytes transmitted from host IP addresses on the monitored network ( Initiator KBytes )

- the number of kilobytes received by host IP addresses on the monitored network ( Responder KBytes )

KBytes Per Second

the default only, which is the total kilobytes per second transmitted on the monitored network (Total KBytes Per Second)

Packets

combinations of:

- the total packets transmitted on the monitored network ( Total Packets )

- the number of packets transmitted from host IP addresses on the monitored network ( Initiator Packets )

- the number of packets received by host IP addresses on the monitored network ( Responder Packets )

Unique Hosts

combinations of:

- the number of unique session initiators on the monitored network ( Unique Initiators )

- the number of unique session responders on the monitored network ( Unique Responders )

Unique Application Protocols

the default only, which is the number of unique application protocols on the monitored network (Unique Application Protocols)

Unique Users

the default only, which is the number of unique users logged into session initiators on the monitored network (Unique Initiator Users)

To select the datasets displayed on a connection graph:

Access: Admin/Any Security Analyst

Step 1 Click Datasets and select the datasets you want to graph.

The datasets you can select are described in the Dataset Options table.

Viewing Information About Aggregated Connection Data

License: Any

Connection graphs are based on aggregated data over five-minute intervals, also called connection summaries. You can get more information about the specific connection summaries used to construct a connection graph. For example, on a graph of connections over time, you may want to know exactly how many connections were detected over a specific interval.

To get detailed information on aggregated connection data:

Access: Admin/Any Security Analyst

Step 1 Position your cursor over a point on a line graph a bar in a bar graph, or a wedge in a pie chart. A tooltip appears with detailed information about the data used to construct that portion of the graph.

Manipulating a Connection Graph on a Workflow Page

License: Any

When you open a connection data workflow, the data is initially constrained only by a time range. You can constrain connection graphs with additional criteria without advancing the workflow to the next page.

Tip Constraining connection data in this manner changes the x-axis (also called the independent variable when viewing a pie chart) of the graph. To change the independent variable without constraining the connection data, use the X-Axis and Y-Axis menus. For more information, see Selecting Data to Graph.

To constrain connection data:

Access: Admin/Any Security Analyst

Step 1 Click a point on a line graph, a bar on a bar graph, or a wedge on a pie chart.

Step 2 Select a View by... option.

You can constrain connection data based on any of the criteria listed in the X-Axis Functions table.

For example, consider a graph of connections over time. If you constrain a point on the graph by port, a bar graph appears, showing the 10 most active ports based on the number of detected connection events, but constrained by the ten-minute time span that is centered on the point you clicked.

If you further constrain the graph by clicking on one of the bars and selecting View by Initiator IP, a new bar graph appears, constrained by not only the same ten-minute time span as before, but also by the port represented by the bar you clicked.

Note Unless you are working with a detached graph, constraining connection data in this manner changes the time range. For more information on detached graphs, see Detaching Connection Graphs.

Drilling Down Through Connection Data Graphs

License: Any

When you open a connection data workflow, the data is initially constrained only by a time range. You can constrain connection graphs while advancing the workflow to the next page.

To drill down in a connection data workflow:

Access: Admin/Any Security Analyst

Step 1 Click a point on a line graph, a bar on a bar graph, or a wedge on a pie chart.

Step 2 Select Drill-down.

You drill down to the next workflow page, constraining using the item you clicked:

- Clicking a point on a line graph constrains the time range on the next page to a 10-minute span, centered on the point you clicked.

- Clicking a bar on a bar graph or a wedge on a pie chart constrains the next page based on the criterion represented by the bar or wedge. For example, clicking on a bar that represents port use drills down to the next page in the workflow, which is constrained by the port represented by the bar you clicked.

Recentering and Zooming on Line Graphs

License: Any

You can recenter line graphs around any point in time. You can recenter using either the default time range, or you can choose a different time range.

Note Unless you are working with a detached graph, recentering changes the default time range. For more information on detached graphs, see Detaching Connection Graphs.

To recenter using the default time range:

Access: Admin/Any Security Analyst

Step 1 Click the point on the line graph where you want to recenter the graph, and click recenter.

The graph is redrawn, centered on the point you clicked, with a time span that is the same length as your default time range.

To recenter using a different time range:

Access: Admin/Any Security Analyst

Step 1 Click the point where you want to recenter the graph and click Zoom.

Step 2 Select the time span for the new graph, which can be as short as one hour or as long as one week.

The graph is redrawn, centered on the point you clicked, with the time span you selected.

Selecting Data to Graph

License: Any

You can display different data on a connection graph by changing either the x-axis, the y-axis, or both.

Note that on a pie chart, changing the x-axis changes the independent variable and changing the y-axis changes the dependent variable. For example, consider a pie chart that graphs kilobytes per port. In this case, the x-axis is Responder Port and the y-axis is KBytes. This pie chart represents the total kilobytes of data transmitted over a monitored network during a certain interval. The wedges of the pie represent the percent of the data that was detected on each port. If you change the x-axis of the chart to Application Protocol, the pie chart still represents the total kilobytes of data transmitted, but the wedges of the pie represent the percentage of the data transmitted for each detected application protocol.

However, if you change the y-axis of the first pie chart to Packets, the pie chart represents the total number of packets transmitted over the monitored network during a certain interval, and the wedges of the pie represent the percentage of the total number of packets that was detected on each port.

Table 39-5 X-Axis Functions

To graph connection data...

You can...

by the 10 most active application protocols on the monitored network based on the number of detected connection events

click X-Axis and select Application Protocol.

by the 10 most active managed devices on the monitored network based on the number of detected connection events

click X-Axis and select Device.

by the 10 most active host IP addresses on the monitored network based on the number of connection events where that host IP address initiated the connection transaction

click X-Axis and select Initiator IP.

by the 10 most active users on the monitored network based on the number of connection events where the host where the user is logged in initiated the connection transaction

click X-Axis and select Initiator User.

by the 10 most active host IP addresses on the monitored network based on the number of connection events where that address was the responder in the connection transaction

click X-Axis and select Responder IP.

by the 10 most active ports on the monitored network based on the number of detected connection events where the host was the responder in the connection transaction

click X-Axis and select Responder Port.

by the 10 most active source devices, which include NetFlow-enabled devices that exported the connection data for the connections, plus a source device named FireSIGHT for all connections detected by Cisco managed devices

click X-Axis and select Source Device.

over time

click X-Axis and select Time.

Follow the directions in the following table to change the y-axis of a connection graph.

Table 39-6 Y-Axis Functions

To...

You can...

graph the number of connections on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select Connections.

graph the total kilobytes transmitted on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select KBytes.

graph the total kilobytes per second transmitted on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select KBytes Per Second.

graph the total number of packets transmitted on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select Packets.

graph the total number of unique hosts detected on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select Unique Hosts.

graph the total number of unique application protocols detected on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select Unique Application Protocols.

graph the total number of unique users detected on the monitored network by the criterion you chose for the x-axis

click Y-Axis and select Unique Users.

Detaching Connection Graphs

License: Any

If you want to perform further analysis on a connection graph, without affecting the default time range, you can detach the graph into a new browser window. You can perform all the same actions on detached connection graphs that you can on embedded connection graphs. You can also print a detached graph by clicking Print. Note that traffic profile graphs are, by default, detached graphs.

Tip If you are viewing a detached graph, click New Window to create another copy of the detached graph in a new browser window. You can then perform different analyses on each of the detached graphs.

To detach a graph:

Access: Admin/Any Security Analyst

Step 1 Click Detach.

Exporting Connection Data

License: Any

You can easily share connection data with others by exporting it as a CSV (comma-separated values) file.

Tip You can also save a connection graph as an image by right-clicking on the graph and following your browser’s prompts.

To export connection data:

Access: Admin/Any Security Analyst

Step 1 Click Export Data.

A pop-up window appears, displaying a table view of the data on your graph.

Step 2 Click Download CSV File and save the file.

Working with Connection and Security Intelligence Data Tables

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The FireSIGHT System’s event viewer allows you to view connection data in a table, as well as manipulate the event view depending on the information relevant to your analysis. Viewing Security Intelligence events allows you to focus on connections with an identified Security Intelligence reputation. (Security Intelligence requires a Protection license and is not supported on Series 2 managed devices or DC500 Defense Centers.) The page you see when you access connection data differs depending on the workflow, which is simply a series of pages you can use to evaluate events by moving from a broad to a more focused view.

Note The information available for any individual connection or Security Intelligence event depends on several factors, including licenses and appliance model. For more information, see License and Model Requirements for Connection Logging.

The system-provided Connection Events and Security Intelligence Events workflows provide summary views of basic connection and detected application information, which you can then use to drill down to the table view of events.You can also create a custom workflow that displays only the information that matches your specific needs.

Using the event viewer, you can:

- search for, sort, and constrain events, as well as change the time range for displayed events

- specify the columns that appear (table view only)

- view the host profile associated with an IP address, or the user details and host history associated with a user identity

- view files (including malware files) and intrusions detected in connections

- view geolocation information associated with an IP address

- view the full text of a URL in a connection event

- view information about the certificate used to encrypt a session

- view encrypted session details

- view events using different workflow pages within the same workflow

- view events using a different workflow altogether

- drill down page-to-page within a workflow, constraining on specific values

- bookmark the current page and constraints so you can return to the same data (assuming the data still exists) at a later time

- create a report template using the current constraints

- delete events from the database

- use the IP address context menu to whitelist, blacklist, or obtain additional information about a host or IP address associated with a connection

Note that when you constrain connection events on a drill-down page, the packets and bytes from identical events are summed. However, if you are using a custom workflow and did not add a Count column to a drill-down page, the events are listed individually and packets and bytes are not summed.

Note that the Connection Events table view displays 1 of Many instead of how many pages of events are available if your system generates more than 25 connection events.

The following sections contain information on viewing and analyzing connection and Security Intelligence event tables:

- Understanding and Using Workflows provides detailed instructions on using the event viewer.

- Using Geolocation provides information on how to view and interpret geolocation information associated with connection and Security Intelligence events.

- Configuring Event View Settings explains how to change the default workflow for viewing connection and Security Intelligence event data.

- Understanding Connection and Security Intelligence Data Fields and Information Available in Connection and Security Intelligence Events provide details on the data in connection and Security Intelligence events.

- Working with Events Associated with Monitor Rules explains how to constrain connection events using Monitor rule criteria.

- Viewing Files Detected in a Connection explains how to view the files, including malware files, detected or blocked in a connection.

- Viewing Intrusion Events Associated with a Connection explains how to view the intrusion events associated with a connection.

- Viewing the Certificate Associated with an Encrypted Connection explains how to view details about the certificate used to encrypt a connection.

Working with Events Associated with Monitor Rules

License: Any

When you view logged connections using the event viewer, the Defense Center displays the access control rule or default action that handled each connection, as well as up to eight Monitor rules matched by each of those connections.

If a connection matched one Monitor rule, the Defense Center displays the name of the rule that handled the connection, followed by the Monitor rule name. If the connection matched more than one Monitor rule, the event viewer displays how many Monitor rules it matched, for example, Default Action + 2 Monitor Rules.

You can constrain connection event views using matched Monitor rules, using either of the following:

- the access control rule or default action that handled the connection

- any individual Monitor rule matched by a connection

To constrain connection events using Monitor rule matching:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Connections > Events.

The first page of the default connection data workflow appears.

Step 2 Display the workflow you want to use for your analysis. Make sure the drill-down page or table view you are using shows the Access Control Rule field.

Step 3 How do you want to constrain the events?

- to constrain on the access control rule or default action that handled the connection, click the rule name or Default Action .

- to constrain on the only Monitor rule that matched a logged connection, click the Monitor rule name.

- to constrain on one of several Monitor rules that matched a logged connection, click an N Monitor Rules value. For example, click 2 Monitor Rules .

The Monitor Rules pop-up window for that connection event appears, listing the first eight Monitor rules matched by the connection. Click the Monitor rule name you want to use to constrain connection events.

Your events are constrained. If you were using a drill-down page, the event view advances to the next page in the workflow.

Viewing Files Detected in a Connection

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

If you associate a file policy with one or more access control rules, the system can detect files (including malware) in matching traffic. Using the event viewer, you can see the file events, if any, associated with the connections logged by those rules.

column. The number on the icon indicates the number of files (including malware files) detected or blocked in that connection. Clicking on the icon does not drill down to the next workflow page or constrain connection events. Instead, it displays a pop-up window with a list of the files detected in the connection as well as their types, and if applicable, their malware dispositions.

In the pop-up window, you can click:

- a file’s view icon (

) to view details in a table view of file events

- a malware file’s view icon (

) to view details in a table view of malware events

- a file’s trajectory icon (

) to track the file’s transmission through your network

- View File Events or View Malware Events to view details on all of the connection’s detected file or network-based malware events

Tip To quickly view file or malware events associated with one or more connections, select the connections using the check boxes in the event viewer, then select Malware Events or File Events from the Jump to drop-down list. You can view the connections used to transmit files in a similar way. For more information, see Navigating Between Workflows.

When you view associated events, the Defense Center uses your default workflow for that event type. For more information on file and malware events, see Working with File Events and Working with Malware Events. For more information on using the network file trajectory feature, see Working with Network File Trajectory.

Note that not all file and malware events are associated with connections, as follows:

- Endpoint-based malware events are not associated with connections. Those events are generated by FireAMP Connectors, instead of by the system inspecting network traffic.

- Many IMAP-capable email clients use a single IMAP session, which ends only when the user exits the application. Although long-running connections are logged by the system (see Long-Running Connections), files downloaded in the session are not associated with the connection until the session ends.

Note also that Series 2 and Cisco NGIPS for Blue Coat X-Series devices and the DC500 Defense Center do not support network-based advanced malware protection.

Viewing Intrusion Events Associated with a Connection

License: Protection

If you associate an intrusion policy with an access control rule or default action, the system can detect exploits in matching traffic. Using the event viewer, you can see the intrusion events, if any, associated with logged connections.

column. Clicking on the icon does not drill down to the next workflow page or constrain connection events. Instead, it displays a pop-up window with a list of the intrusion events associated with the connection, as well as their priority and impact.

to view details on all of the connection’s associated intrusion events.

Tip To quickly view intrusion events associated with one or more connections, select the connections using the check boxes in the event viewer, then select Intrusion Events from the Jump to drop-down list. You can view the connections associated with intrusion events in a similar way. For more information, see Navigating Between Workflows.

When you view associated events, the Defense Center uses your default intrusion events workflow. For more information on intrusion events, see Working with Intrusion Events.

Viewing the Certificate Associated with an Encrypted Connection

License: Any

If you configure SSL inspection, you can log encrypted connections. Using the event viewer, you can view details of the public key certificate used to encrypt a connection if the system acted on the traffic and the certificate is available.

column. Clicking on the icon displays a pop-up window with the certificate details described in the following table.

Table 39-7 Encrypted Connection Certificate Details

Attribute

Description

Subject/Issuer Common Name

The host and domain name of the certificate subject or certificate issuer.

Subject/Issuer Organization

The organization of the certificate subject or certificate issuer.

Subject/Issuer Organization Unit

The organizational unit of the certificate subject or certificate issuer.

Not Valid Before/After

The dates when the certificate is valid.

Serial Number

The serial number assigned by the issuing CA.

Certificate Fingerprint

The SHA hash value used to authenticate the certificate.

Public Key Fingerprint

The SHA hash value used to authenticate the public key contained within the certificate.

You can expand or collapse sections in the pop-up window by double-clicking the heading.

Note that if the system acted on the encrypted traffic but the certificate is unavailable, the lock icon is grayed out. For example, if the system blocked a connection because it contained an SSL handshake error and the system could not decrypt it, then the system would not have encryption certificate details, and the lock icon for that connection is grayed out.

Searching for Connection and Security Intelligence Data

License: Any

Using the Defense Center’s Search page, you can search for specific connection events, Security Intelligence events, or connection summaries; display the results in the event viewer; and save your search criteria to reuse later. Custom Analysis dashboard widgets, report templates, and custom user roles can also use saved searches.

Searches delivered with the system, labeled with (Cisco) in the Saved Searches list, serve as examples.

Because connection graphs are based on connection summaries, the same criteria that constrain connection summaries also constrain connection graphs. Fields marked with an asterisk (*) constrain connection graphs and connection summaries, as well as individual connection or Security Intelligence events.

If you search connection summaries using invalid search constraints and view your results using a connection summary page in a custom workflow, the invalid constraints are labeled as not applicable (N/A) and are marked with a strikethrough, as shown in the following graphic.

Also, keep in mind that your search results depend on the available data in the events you are searching. In other words, depending on the available data, your search constraints may not apply. See Information Available in Connection and Security Intelligence Events for information on when data is available for each connection data field.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for Connection and Security Intelligence Data

To supplement the general search syntax listed above, the following list describes some special search syntax for connection and Security Intelligence data.

A Monitor rule matched by the connection

Use the Access Control Rule criterion to search for connections that matched individual Monitor rules.

Because traffic matching a Monitor rule is always later handled by another rule or by the default action, you cannot search for a connection with an action of Monitor. Searching for the name of a Monitor rule returns all connections that matched that Monitor rule, regardless of the rule or default action that later handled the connection.

A Criterion with a numerical value (Bytes, Packets, Connections)

You can precede the number with greater than (>), greater than or equal to (>=), less than (<), less than or equal to (<=), or equal to (=).

Tip To view meaningful results for searches using the Connections criterion, you must use a custom workflow that has a connection summary page.

Files or Intrusion Events associated with the connection

You cannot use the connection/Security Intelligence events Search page to search for file, malware, and intrusion events associated with a connection. For information on viewing these associated events, see Viewing Files Detected in a Connection and Viewing Intrusion Events Associated with a Connection.

The Initiator User or URL for a connection

The system performs a partial match, that is, you can search for all or part of the field contents without using asterisks.

The total Traffic (in bytes) or transport Protocol used in the connection

To determine if there is a protocol or traffic constraint on a connection table view, expand the search constraints.

To search for a specific protocol, use the name or number protocol as listed in http://www.iana.org/assignments/protocol-numbers.

These columns do not appear in table views.

TCP Flags in a NetFlow connection

Type a list of comma-separated TCP flags to view all connections that have at least one of those flags (instead of all). You can also select the Only check box to search for connections that have any of the flags you specify as their only TCP flag.

SSL Encryption applied to the connection

Type yes or no to view SSL-encrypted or non-encrypted connections.

This column does not appear in Security Intelligence or connection events table views.

The SSL Status

Type one or more of the keywords listed for SSL Actual Action and SSL Failure Reason to view encrypted traffic to which the system applied an action or encountered a condition. This field may simultaneously contain one SSL Actual Action value and SSL Failure Reason value.

When decryption is successful, the Security Intelligence and connection event table views display the value for SSL Actual Action in the SSL Status column. When the system fails to decrypt traffic, the Security Intelligence and connection event table views display the values for both SSL Actual Action and SSL Failure Reason in the SSL Status column.

The SSL Actual Action taken

Type any of the following keywords to view encrypted traffic to which the system applied the action specified:

– Do Not Decrypt represents connections the system did not decrypt.

– Block and Block with Reset represent blocked encrypted connections.

– Decrypt (Known Key) represents incoming connections decrypted using a known private key.

– Decrypt (Replace Key) represents outgoing connections decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Resign) represents outgoing connections decrypted using a re-signed server certificate.

When decryption is successful, the Security Intelligence and connection event table views display this value in the SSL Status column. When the system fails to decrypt traffic, the Security Intelligence and connection event table views display this value with the SSL Failure Reason in the SSL Status column.

The SSL Expected Action

Type any of the following keywords to view encrypted traffic that the system was expected to process in the manner specified given the SSL rules in effect:

– Do Not Decrypt represents connections the system did not decrypt.

– Block and Block with Reset represent blocked encrypted connections.

– Decrypt (Known Key) represents incoming connections decrypted using a known private key.

– Decrypt (Replace Key) represents outgoing connections decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Resign) represents outgoing connections decrypted using a re-signed server certificate.

This column does not appear in Security Intelligence or connection events table views.

The SSL Failure Reason

Type any of the following keywords to view encrypted traffic that the system failed to decrypt for the reason specified:

– Unknown

– No Match

– Success

– Uncached Session

– Unknown Cipher Suite

– Unsupported Cipher Suite

– Unsupported SSL Version

– SSL Compression Used

– Session Undecryptable in Passive Mode

– Handshake Error

– Decryption Error

– Pending Server Name Category Lookup

– Pending Common Name Category Lookup

– Internal Error

– Network Parameters Unavailable

– Invalid Server Certificate Handle

– Server Certificate Fingerprint Unavailable

– Cannot Cache Subject DN

– Cannot Cache Issuer DN

– Unknown SSL Version

– External Certificate List Unavailable

– External Certificate Fingerprint Unavailable

– Internal Certificate List Invalid

– Internal Certificate List Unavailable

– Internal Certificate Unavailable

– Internal Certificate Fingerprint Unavailable

– Server Certificate Validation Unavailable

– Server Certificate Validation Failure

– Invalid Action

When the system fails to decrypt traffic, the Security Intelligence and connection event table views display this value with the SSL Actual Action in the SSL Status column.

The SSL Cipher Suite used

Type a macro value representing a cipher suite used to encrypt the connection. See www.iana.org/assignments/tls-parameters/tls-parameters.xhtml for cipher suite value designations.

The SSL Subject Country

Type a two-character ISO 3166-1 alpha-2 country code to view encrypted traffic associated with the encryption certificate subject country.

This column does not appear in Security Intelligence or connection events table views.

The SSL Issuer Country

Type a two-character ISO 3166-1 alpha-2 country code to view encrypted traffic associated with the encryption certificate subject country.

This column does not appear in Security Intelligence or connection events table views.

SSL Certificate Fingerprint

Type or paste the SHA hash value used to authenticate a certificate to view traffic associated with that certificate.

This column does not appear in Security Intelligence or connection events table views.

SSL Public Key Fingerprint

Type or paste the SHA hash value used to authenticate the public key contained within a certificate to view traffic associated with that certificate.

This column does not appear in Security Intelligence or connection events table views.

SSL Certificate Status

This applies only if you configured a Certificate Status rule condition. Type one or more of the keywords listed below to view encrypted traffic associated with server certificate statuses. Encrypted traffic may match multiple server certificate status values simultaneously.

– Not Checked

– Self Signed

– Valid

– Invalid Signature

– Invalid Issuer

– Expired

– Unknown

– Not Valid Yet

– Revoked

SSL Flow Messages

Type any of the following keywords to view encrypted traffic associated with the following messages exchanged between client and server during the SSL handshake:

– HELLO_REQUEST

– CLIENT_ALERT

– SERVER_ALERT

– CLIENT_HELLO

– SERVER_HELLO

– SERVER_CERTIFICATE

– SERVER_KEY_EXCHANGE

– CERTIFICATE_REQUEST

– SERVER_HELLO_DONE

– CLIENT_CERTIFICATE

– CLIENT_KEY_EXCHANGE

– CERTIFICATE_VERIFY

– CLIENT_CHANGE_CIPHER_SPEC

– CLIENT_FINISHED

– SERVER_CHANGE_CIPHER_SPEC

– SERVER_FINISHED

– NEW_SESSION_TICKET

– HANDSHAKE_OTHER

– APP_DATA_FROM_CLIENT

– APP_DATA_FROM_SERVER

SSL Version

Type any of the following keywords to view encrypted traffic associated with the specified SSL or TLS protocol version:

– Unknown

– SSLv2.0

– SSLv3.0

– TLSv1.0

– TLSv1.1

– TSLv1.2

SSL Serial Number

Type or paste the serial number assigned to the public key certificate by the issuing CA.

This column does not appear in Security Intelligence or connection events table views.

To search for connection or Security Intelligence data:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 You have the following options:

- Select Connection Events from the table drop-down list to search for connection data.

- Select Security Intelligence Events from the table drop-down list to search for Security Intelligence data.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields:

- See Understanding Connection and Security Intelligence Data Fields for information on the fields in the connection and Security Intelligence events tables.

- See Viewing the Certificate Associated with an Encrypted Connection for information on fields related to public key certificates.

- See Special Search Syntax for Connection and Security Intelligence Data for special search syntax for connection and Security Intelligence events.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in your default connection or Security Intelligence workflow, constrained by the current time range.

Viewing the Connection Summary Page

License: Any

The Connection Summary page provides graphs of the activity on your monitored network organized by different criteria. For example, the Connections over Time graph displays the total number of connections on your monitored network over the interval that you select.

Note The Connection Summary page is visible only to users who have custom roles that are restricted by searches on connection events and who have been granted explicit access to the Connection Summary page. For more information, see Understanding Restricted User Access Properties and Managing Custom User Roles.

Table 39-8 Connection Summary Page Actions

To...

You can...

modify the time and date range for the Connection Summary page

find more information in Setting Event Time Constraints.

manipulate connection graphs

find more information in Working with Connection Graphs.

detach a connection graph from the page

click View on the graph you want to detach. For more information on detached graphs, see Detaching Connection Graphs.

You can perform almost all the same actions on connection summary graphs that you can perform on connection graphs. However, because the graphs on the Connection Summary page are based on aggregated data, you cannot examine the individual connection events on which the graphs are based. In other words, you cannot drill down to a connection data table view from a connection summary graph.

To view the Connection Summary page:

Access: Custom

Step 1 Select Overview > Summary > Connection Summary.

The Connection Summary page appears for the current time range on your Defense Center.

Step 2 From the Select Device list, select the device whose summary you want to view, or select All to view a summary of all devices.

Analyzing Malware and File Activity

The Defense Center logs records of the system’s file inspection and handling as captured files, file events, and malware events:

- Captured files represent files that the system captured.

- File events represent files that the system detected, and optionally blocked, in network traffic.

- Malware events represent malware files detected, and optionally blocked, in network traffic by the system.

- Retrospective malware events represent files whose malware file dispositions have changed.

When the system generates a malware event based on detection or blocking of malware in network traffic, it also generates a file event, because to detect malware in a file, the system must first detect the file itself. Note that endpoint-based malware events generated by FireAMP Connectors (see Integrating FireAMP with the FireSIGHT System) do not have corresponding file events. Similarly, when the system captures a file in network traffic, it also generates a file event because the system first detected the file.

You can use the Defense Center to view, manipulate, and analyze captured files, file events, and malware events, then communicate your analysis to others. The Context Explorer, dashboards, event viewer, context menu, network file trajectory map, and reporting features can give you a deeper understanding of the files and malware detected, captured, and blocked. You can also use events to trigger correlation policy violations, or alert you via email, SMTP, or syslog.

Because you cannot use a Malware license with a DC500 or enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to generate or analyze captured files, file events, and malware events associated with malware cloud lookups or with the contents of archive files.

For more information, see:

- Working with File Storage

- Working with Dynamic Analysis

- Working with File Events

- Working with Malware Events

- Working with Captured Files

- Working with Network File Trajectory

For information on configuring your system to perform the malware protection and file control actions that produce the data discussed in this chapter, see Blocking Malware and Prohibited Files.

Working with File Storage

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

Based on your file policy configuration, you can use the file control feature to detect and block files. However, files originating from a suspicious host or network, or an excess of files sent to a monitored host on your network, may require further analysis. The file storage feature allows you to capture selected files detected in traffic, and automatically store them to a device’s hard drive or, if installed, the malware storage pack.

When a device detects a file in traffic, it can capture that file. This creates a copy the system can either store or submit for dynamic analysis. After your device captures the files, you have several options:

- Store captured files on the device’s hard drive for later analysis. See Understanding Captured File Storage for more information.

- Download the stored file to a local computer for further manual analysis or archival purposes. See Downloading Stored Files to Another Location for more information.

- Submit captured files to the Collective Security Intelligence Cloud for dynamic analysis. See Working with Dynamic Analysis for more information.

Note that once a device stores a file, it will not re-capture it if the file is detected in the future and the device still has that file stored.

Note A file detected for the first time ever is assigned a disposition after the Defense Center completes a cloud lookup. The system generates a file event, but cannot store a file unless the file is immediately assigned a disposition.

If a previously undetected file matches a file rule with a Block Malware action, the subsequent cloud lookup immediately returns a disposition, allowing the system to store the file and generate events.

If a previously undetected file matches a file rule with a Malware Cloud Lookup action, the system generates file events but requires additional time to perform a cloud lookup and return a disposition. Due to this delay, the system cannot store files matching a file rule with a Malware Cloud Lookup action until the second time they are seen on your network.

Whether the system captures or stores a file, you can:

- Review information about the captured file from the event viewer, including whether the file was stored or submitted for dynamic analysis, file disposition, and threat score, allowing you to quickly review possible malware threats detected on your network. See Working with Captured Files for more information.

- View the file’s trajectory to determine how it traversed your network and which hosts have a copy. See Analyzing Network File Trajectory for more information.

- Add the file to the clean list or custom detection list to always treat the file as if it had a clean or malware disposition on future detection. See Working with File Lists for more information.

You configure file rules in a file policy to capture and store files of a specific type, or with a particular file disposition, if available. After you associate the file policy with an access control policy and apply it to your devices, matching files in traffic are captured and stored. You can also limit the minimum and maximum file sizes to store. See Tuning File and Malware Inspection Performance and Storage and Working with File Rules for more information.

File storage requires sufficient disk space on the device. If the device’s primary hard drive does not have enough space, and you do not have a malware storage pack installed, you cannot store files on the device.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware storage pack. See the FireSIGHT System Malware Storage Pack Guide for more information.

Note that because you cannot use a Malware license with a DC500 or enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture or store files.

For more information, see:

- Understanding Captured File Storage

- Downloading Stored Files to Another Location

Understanding Captured File Storage

License: Malware

Supported Devices: 8000 Series

Based on your file policy configuration, your device may store a substantial amount of file data to the hard drive. You can install a malware storage pack in the device; the system stores files to the malware storage pack, allowing more room on the primary hard drive to store events and configuration files. The system periodically deletes older files.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco, and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware storage pack. See the FireSIGHT System Malware Storage Pack Guide for more information.

Without a malware storage pack installed, when you configure a device to store files, it allocates a set portion of the primary hard drive’s space solely to captured file storage. When you install a malware storage pack in a device and configure the device to store files, the device instead allocates the entire malware storage pack for storing captured files. The device cannot store any other information on the malware storage pack.

When the allocated space for captured file storage fills to capacity, the system deletes the oldest stored files until the allocated space reaches a system-defined threshold. Based on the number of files stored, you may see a substantial drop in disk usage after the system deletes files.

If a device has already stored files when you install a malware storage pack, the next time you restart the device, any captured files stored on the primary hard drive are moved to the malware storage pack. Any future files the device stores are stored to the malware storage pack. If the device’s primary hard drive does not have enough available space nor an installed malware storage pack, you cannot store files.

Note that you cannot include stored files in system backup files. For more information, see Creating Backup Files.

Downloading Stored Files to Another Location

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

Once a device stores a file, as long as the Defense Center can communicate with that device and it has not deleted the file, you can download the file. You can manually analyze the file, or download it to a local host for long-term storage and analysis. You can download a file from any associated file event, malware event, captured file view, or the file’s trajectory. For more information, see Using the Context Menu and Summary Information.

Because malware is harmful, by default, you must confirm every file download. However, you can disable the confirmation in the file download prompt. To re-enable the confirmation, see File Preferences.

Caution Cisco strongly recommends you do not download malware, as it can cause adverse consequences. Exercise caution when downloading any file, as it may contain malware. Ensure you have taken any necessary precautions to secure the download destination before downloading files.

Because files with a disposition of Unknown may contain malware, when you download a file, the system first archives the file in a .zip package. The .zip file name contains the file disposition and file type, if available, and SHA-256 value. You can password-protect the .zip file to prevent accidental unpacking. To edit or remove the default .zip file password, see File Preferences.

Working with Dynamic Analysis

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

To increase the accuracy of the cloud, and to provide additional malware analysis and threat identification, you can submit eligible captured files to the Cisco cloud for dynamic analysis. The cloud runs the file in a test environment and, based on the results, returns a threat score and dynamic analysis summary report to the Defense Center. You can also submit eligible files to the cloud for Spero analysis, which examines the file’s structure to supplement the malware identification.

Submitting a file to the cloud for dynamic analysis depends on the type of file captured, as well as the allowable minimum and maximum file sizes configured in the access control policy. You can submit:

- a file automatically for dynamic analysis if a file rule performs a malware cloud lookup on an executable file and the file disposition is Unknown

- up to twenty-five files at once manually for dynamic analysis if stored and a supported file type, such as PDFs, Microsoft Office documents, and others

Once submitted, the files are queued for analysis in the cloud. You can view captured files and a file’s trajectory to determine whether a file has been submitted for dynamic analysis. Note that each time a file is submitted for dynamic analysis, the cloud analyzes the file, even if the first analysis generated results.

For more information, see Working with File Rules and Submitting Files for Dynamic Analysis.

Note The system checks the cloud for updates to the list of file types eligible for dynamic analysis and the minimum and maximum file sizes you can submit (no more than once a day).

The cloud performs dynamic analysis by running the file in a sandbox environment. It returns:

- a threat score, which details the likelihood a file contains malware.

- a dynamic analysis summary report, which details why the cloud assigned the threat score.

Based on the file policy configuration, you can automatically block files whose threat score falls above a defined threshold. You can also review the dynamic analysis summary report to better identify malware and fine-tune your detection capabilities.

To supplement dynamic analysis, if a file rule performs a malware cloud lookup on an executable file, you can automatically submit the file for Spero analysis. The cloud examines the executable file’s structure, including metadata and header information, and can identify files as malware. See Understanding Malware Protection and File Control for more information.

Note that because you cannot use a Malware license with a DC500 or enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to submit files for dynamic analysis or Spero analysis.

Note You can configure your managed devices to submit files to the Cisco cloud via HTTP proxy. To configure physical appliances, see Configuring Management Interfaces for more information. To configure virtual appliances, see http-proxy. Cisco NGIPS for Blue Coat X-Series does not support proxy settings.

For more information, see:

- Understanding Spero Analysis

- Submitting Files for Dynamic Analysis

- Reviewing the Threat Score and Dynamic Analysis Summary

Understanding Spero Analysis

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

Spero analysis supplements analysis of SHA-256 hashes, allowing for more complete identification of malware in executable files. Spero analysis involves the device examining file structural characteristics such as metadata and header information. After generating a Spero signature based on this information, the device submits it to the Spero heuristic engine in the Cisco cloud. Based on the Spero signature, the Spero engine returns whether the file is malware. If so, and the file currently has an unknown file disposition, the system assigns a Malware file disposition. For more information on file dispositions, see Understanding Malware Protection and File Control.

Note that you can only submit executable files for Spero analysis upon detection; you cannot manually submit them later. You can submit the file for Spero analysis without also submitting it for dynamic analysis. For more information, see Working with File Rules.

Submitting Files for Dynamic Analysis

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

From the event viewer context menu or network file trajectory, you can manually submit a file for dynamic analysis. In addition to executable files, you can also submit file types not eligible for automatic submission, such as PDFs, Microsoft Office documents, and others. See Using the Context Menu and Summary Information for more information.

To analyze multiple files after an incident, regardless of file disposition, you can manually submit up to 25 files (of specific types) at a time from the captured file view. This allows you to more quickly analyze a broad range of files and pinpoint the exact causes of the incident. For more information, see Working with Captured Files and Selecting Rows on a Workflow Page.

Reviewing the Threat Score and Dynamic Analysis Summary

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

After you submit a file for dynamic analysis, the Cisco cloud analyzes a file’s signatures and returns both a threat score and a dynamic analysis summary. These can help you more closely analyze potential malware threats and fine tune your detection strategy.

Threat Scores

Table 40-1 Threat Score Ratings

Threat Score

Icon

Rating

Low

1-25

Medium

26-50

High

51-75

Very High

76-100

The Defense Center caches a file’s threat score locally for the same amount of time as the file’s disposition. If the system later detects these files, it displays the cached threat scores to the user instead of again querying the Cisco cloud. Based on your file policy configuration, you can automatically assign a malware file disposition to any file with a threat score that exceeds the defined malware threshold threat score. For more information, see Creating a File Policy.

Dynamic Analysis Summary

If a dynamic analysis summary is available, you can click the threat score icon to view it. The dynamic analysis summary describes the various component ratings that comprise the overall threat score assigned by the Vulnerability Research Team (VRT) file analysis, as well as other processes started when the cloud attempted to run the file.

If multiple reports exist, this summary is based on the most recent report matching the exact threat score. If none match the exact threat score, then the report with the highest threat score is displayed. If more than one report exists, you can select a threat score to view each separate report.

The summary lists each component threat comprising the threat score. Each component threat is expandable to list the VRT’s findings, as well as any processes related to this component threat.

The process tree shows the processes that started when the cloud attempted to run the file. This can help identify whether a file that contains malware is attempting to access processes and system resources beyond what is expected (for example, running a Word document opens Microsoft Word, then starts Explorer, then starts Java).

Each listed process contains a process identifier and md5 checksum you can use to verify the actual process. The process tree displays processes started as a result of parent processes as child nodes.

From the dynamic analysis summary, you can click View Full Report to view the VRT’s Analysis report, detailing the VRT’s full analysis, including general file information, a more in-depth review of all detected processes, a breakdown of the file analysis, and other relevant information.

Working with File Events

License: Protection

The system logs the file events generated when a managed device detects or blocks a file in network traffic, according to the rules in currently applied file policies. Note that when the system generates a file event, the system also logs the end of the associated connection to the Defense Center database, regardless of the logging configuration of the invoking access control rule. For more information, see Understanding and Creating File Policies.

Note Files detected in network traffic and identified as malware by the FireSIGHT System generate both a file event and a malware event. This is because to detect malware in a file, the system must first detect the file itself. Endpoint-based malware events do not have corresponding file events. For more information, see Working with Malware Events and Working with Captured Files.

You can use the Defense Center’s event viewer to view, search, and delete file events. Additionally, the Files Dashboard provides an at-a-glance view of detailed information about the files (including malware files) detected on your network, using charts and graphs. Network file trajectory offers a more in-depth view of individual files, providing summary information about the file and how it has moved through the network over time. Using file identification data, you can trigger correlation rules and create reports, the latter using either the predefined Files Report template or a custom report template.

For more information, see:

- Viewing File Events

- Understanding the File Events Table

- Using Geolocation

- Searching for File Events

Viewing File Events

License: Protection

The FireSIGHT System’s event viewer allows you to view file events in a table, as well as manipulate the event view depending on the information relevant to your analysis. Note that the information available for any individual file event depends on several factors, including licenses. For more information, see Service Subscriptions.

The page you see when you access file events differs depending on the workflow, which is simply a series of pages you can use to evaluate events by moving from a broad to a more focused view. The system is delivered with the following predefined workflows for file events:

- File Summary , the default, provides a quick breakdown of the different file event categories and types, along with any associated malware file dispositions.

- Hosts Receiving Files and Hosts Sending Files provide a list of hosts that have received or sent files, grouped by the associated malware dispositions for those files.

Note File dispositions appear only for files for which the system performed a malware cloud lookup; see File Rule Actions and Evaluation Order.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on specifying a different default workflow, including a custom workflow, see Configuring Event View Settings.

The FireSIGHT System supports the display and input of file names that use Unicode (UTF-8) characters in all areas of the web interface, including the event viewer, event search, dashboard, Context Explorer, and so on. Note, however, that reports you generate in PDF format do not support Unicode; Unicode file names appear in the PDF report in transliterated form. For more information, see Generating and Viewing Reports. Note also that the SMB protocol converts Unicode file names to printable characters; files you detect over SMB that have Unicode file names appear with periods (.) in place of any unprintable characters.

Using the event viewer, you can:

- search for, sort, and constrain events, as well as change the time range for displayed events

- specify the columns that appear (table view only)

- view the host profile associated with an IP address, or the user details and host history associated with a user identity

- view the connections where specific files were detected

- view events using different workflow pages within the same workflow

- view events using a different workflow altogether

- drill down page-to-page within a workflow, constraining on specific values

- bookmark the current page and constraints so you can return to the same data (assuming the data still exists) at a later time

- view the sending and receiving countries and continents for routable IP addresses associated with a file

- view a file’s trajectory

- add a file to a file list, download a file, submit a file for dynamic analysis, or view the full text of a file’s SHA-256 value

- view a file’s Dynamic Analysis Summary report, if available

- view nested files inside an archive file

- create a report template using the current constraints

- delete events from the database

- use the IP address context menu to whitelist, blacklist, or obtain additional available information about a host or IP address associated with a file event

For detailed information on using the event viewer, including creating custom workflows, see Understanding and Using Workflows.

To quickly view the connections where specific files were detected, select the files using the check boxes in the event viewer, then select Connections Events from the Jump to drop-down list. For more information, see Navigating Between Workflows.

To view file events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Files > File Events.

The first page of your default file events workflow appears. For information on the columns that appear, see Understanding the File Events Table.

Understanding the File Events Table

License: Protection

The Defense Center logs a file event when a managed device detects or blocks a file being transmitted in monitored network traffic, according to the settings in an applied file policy.

.

Keep in mind that the information available for any individual file event depends on several factors, including licenses. For example, although you can perform file control with only a Protection license, a Malware license allows you to perform advanced malware protection for certain file types and track files transferred on your network.

The following table describes the file event fields.

Table 40-2 File Event Fields

Field

Description

Time

The date and time the event was generated.

Action

The action associated with the file policy rule that detected the file, and any associated file action options.

Sending IP

The IP address of the host sending the detected file.

Sending Country

The country of the host sending the detected file.

Note that the DC500 Defense Center does not support this feature.

Receiving IP

The IP address of the host receiving the detected file.

Receiving Country

The country of the host receiving the detected file.

Note that the DC500 Defense Center does not support this feature.

Sending Port

The source port used by the traffic where the file was detected.

Receiving Port

The destination port used by the traffic where the file was detected.

SSL Status

The action associated with the SSL rule, default action, or undecryptable traffic action that logged the encrypted connection:

- Block and Block with reset represent blocked encrypted connections.

- Decrypt (Resign) represents an outgoing connection decrypted using a re-signed server certificate.

- Decrypt (Replace Key) represents an outgoing connection decrypted using a self-signed server certificate with a substituted public key.

- Decrypt (Known Key) represents an incoming connection decrypted using a known private key.

- Default Action indicates the connection was handled by the default action.

- Do not Decrypt represents a connection the system did not decrypt.

If the system fails to decrypt an encrypted connection, it displays the undecryptable traffic action taken, as well as the failure reason. For example, if the system detects traffic encrypted with an unknown cipher suite and allowed it without further inspection, this field displays Do Not Decrypt (Unknown Cipher Suite).
) to view certificate details. For more information, see Viewing the Certificate Associated with an Encrypted Connection.

User

The user logged into the host (Receiving IP) where the file was destined.

Note that because the user is associated with the destination host, users are not associated with file events where the user uploaded a file.

File Name

The name of the file.

Disposition

One of the following file dispositions:

- Malware indicates that the cloud categorized the file as malware, or that the file’s threat score exceeded the malware threshold defined in the file policy.

- Clean indicates that the cloud categorized the file as clean, or that a user added the file to the clean list.

- Unknown indicates that a malware cloud lookup occurred before the cloud assigned a disposition. The file is uncategorized.

- Custom Detection indicates that a user added the file to the custom detection list.

- Unavailable indicates that the Defense Center could not perform a malware cloud lookup. You may see a small percentage of events with this disposition; this is expected behavior.

- N/A indicates a Detect Files or Block Files rule handled the file and the Defense Center did not perform a malware cloud lookup.

SHA256

The SHA-256 hash value of the file, as well as a network file trajectory icon representing the most recently detected file event and file disposition, if this file was detected as the result of:

- a Detect Files file rule with Store Files enabled

- a Block Files file rule with Store Files enabled

- a Malware Cloud Lookup file rule

- a Block Malware file rule

To view the network file trajectory, click the trajectory icon. For more information, see Analyzing Network File Trajectory.

Threat Score

The threat score most recently associated with this file:

- Low (

)

- Medium (

)

- High (

)

- Very High (

)

To view the Dynamic Analysis Summary report, click the threat score icon.

Type

The type of file, for example, HTML or MSEXE.

Category

The general categories of file type, for example: Office Documents, Archive, Multimedia, Executables, PDF files, Encoded, Graphics, or System Files.

Size (KB)

The size of the file, in kilobytes. Note that if the system determines the file type of a file before the file is fully received, the file size may not be calculated and this field is blank.

URI

The originating URI of the file, for example, the URL where a user downloaded it.

Archive Name

Name of the archive file (if any) with which the file is associated, for example, archive.zip. To view the contents of an archive file, right-click on the archive file’s event viewer row to open the context menu, then click View Archive Contents. For more information, see Viewing the Contents of Archived Files.

Archive SHA256

The SHA-256 hash value of the archive file (if any) with which the file is associated.

Archive Depth

The level (if any) at which the file was nested in an archive file, for example, 1 or 3.

Application Protocol

The application protocol used by the traffic in which a managed device detected the file.

Application Protocol, Client, or Web Application Category or Tag

Criteria that characterize the application to help you understand the application's function; see Table 45-2.

Client

The client application used in the connection to transmit a file.

Web Application

For files transmitted using HTTP, the web application (content or requested URL) detected in the connection and used to transmit the file.

Application Risk

The risk associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated risk; this field displays the highest of those. For more information, see Table 45-2.

Business Relevance

The business relevance associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated business relevance; this field displays the lowest (least relevant) of those. For more information, see Table 45-2.

Message

For files where a malware disposition has changed, that is, for files associated with retrospective malware events, information about when and how the disposition changed.

File Policy

The file policy that detected the file.

Device

The name of the device that detected the file.

Security Context

The metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

Count

The number of events that match the information in each row. This field appears after you apply a constraint that creates two or more identical rows.

Searching for File Events

License: Protection

Using the Defense Center’s Search page, you can search for specific file events, display the results in the event viewer, and save your search criteria to reuse later. Custom Analysis dashboard widgets, report templates, and custom user roles can also use saved searches.

Keep in mind that your search results depend on the available data in the events you are searching. In other words, depending on the available data, your search constraints may not apply. For example, the Disposition and SHA256 fields are populated only for files for which the Defense Center performed a malware cloud lookup.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for File Events

To supplement the general search syntax listed above, the following list describes some special search syntax for file events.

Sending/Receiving Continent

The system returns all events where either the Sending Continent or the Receiving Continent matches the continent you specify.

Sending/Receiving Country

The System returns all events where either the Sending Country or the Receiving Country matches the country you specify.

Sending/Receiving IP

The system returns all events where either the Sending IP or the Receiving IP matches the IP address you specify.

URI or Message

The system performs a partial match, that is, you can search for all or part of the field contents without using asterisks.

File Storage

Type one or more of the following:

– Stored returns all events where the associated file is currently stored.

– Stored in connection returns all events where the system captured and stored the associated file, regardless of whether the associated file is currently stored.

– Failed returns all events where the system failed to store the associated file.

The SSL Actual Action taken

Type any of the following keywords to view file events for encrypted traffic to which the system applied the action specified:

– Do Not Decrypt represents connections the system did not decrypt.

– Block and Block with Reset represent blocked encrypted connections.

– Decrypt (Known Key) represents incoming connections decrypted using a known private key.

– Decrypt (Replace Key) represents outgoing connections decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Resign) represents outgoing connections decrypted using a re-signed server certificate.

This column does not appear in the file events table view.

The SSL Failure Reason

Type any of the following keywords to view file events for encrypted traffic that the system failed to decrypt for the reason specified:

– Unknown

– No Match

– Success

– Uncached Session

– Unknown Cipher Suite

– Unsupported Cipher Suite

– Unsupported SSL Version

– SSL Compression Used

– Session Undecryptable in Passive Mode

– Handshake Error

– Decryption Error

– Pending Server Name Category Lookup

– Pending Common Name Category Lookup

– Internal Error

– Network Parameters Unavailable

– Invalid Server Certificate Handle

– Server Certificate Fingerprint Unavailable

– Cannot Cache Subject DN

– Cannot Cache Issuer DN

– Unknown SSL Version

– External Certificate List Unavailable

– External Certificate Fingerprint Unavailable

– Internal Certificate List Invalid

– Internal Certificate List Unavailable

– Internal Certificate Unavailable

– Internal Certificate Fingerprint Unavailable

– Server Certificate Validation Unavailable

– Server Certificate Validation Failure

– Invalid Action

This column does not appear in the file events table view.

The SSL Subject Country

Type a two-character ISO 3166-1 alpha-2 country code to view file events for encrypted traffic associated with the country of a certificate subject.

This column does not appear in the file events table view.

The SSL Issuer Country

Type a two-character ISO 3166-1 alpha-2 country code to view file events for encrypted traffic associated with the country of a certificate issuer.

This column does not appear in the file events table view.

SSL Certificate Fingerprint

Type or paste the SHA hash value used to authenticate a certificate to view file events for traffic associated with that certificate.

This column does not appear in the file events table view.

SSL Public Key Fingerprint

Type or paste the SHA hash value used to authenticate the public key contained within a certificate to view file events for traffic associated with that certificate.

This column does not appear in the file events table view.

To search for file events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select File Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields as described in the following sections:

- See the File Event Fields table for information on the fields in the file events table.

- See Special Search Syntax for File Events for special search syntax for file events.

- See Viewing the Certificate Associated with an Encrypted Connection for fields related to public key certificates.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in your default file events workflow, constrained by the current time range.

Working with Malware Events

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The system logs malware events to the Defense Center database when:

- a managed device detects a file in network traffic that is then identified as malware by a malware cloud lookup

- a managed device detects a file on the custom detection list in network traffic

- the system learns that a file’s malware disposition has changed; these are called retrospective malware events

- a FireAMP Connector installed on an endpoint in your organization detects a threat and communicates that threat to the Cisco cloud

Because FireAMP malware detection is performed at the endpoint at download or execution time, while managed devices detect files in network traffic, the information in these malware events is different. Retrospective malware events also contain slightly different data than other network-based malware events, or endpoint-based malware events.

The following sections briefly describe the different kinds of malware events. For information on the overall malware detection process, see Understanding Malware Protection and File Control.

Endpoint-Based (FireAMP) Malware Events

If your organization has a FireAMP subscription, individual users install FireAMP Connectors on their computers and mobile devices. These lightweight agents communicate with the Cisco cloud, which in turn communicates with your Defense Center; see Working with Cloud Connections for FireAMP. The cloud can send notification of threats, as well other kinds of information including data on scans, quarantines, blocked executions, and cloud recalls. The Defense Center logs this information to its database as malware events.

Note The IP addresses reported in endpoint-based malware events may not be in your network map—and may not even be in your monitored network at all. Depending on your deployment, level of compliance, and other factors, endpoints in your organization where FireAMP Connectors are installed may not be the same hosts as those monitored by your managed devices.

Malware Events Based on Network Traffic

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

With a Malware license, your managed devices can detect malware in network traffic as part of your overall access control configuration; see Understanding and Creating File Policies.

The following scenarios can lead to generating malware events:

- If a managed device detects one of a set of specific file types, the Defense Center performs a malware cloud lookup, which returns a file disposition to the Defense Center of Malware , Clean , or Unknown .

- If the Defense Center cannot establish a connection with the cloud, or the cloud is otherwise unavailable, the file disposition is Unavailable . You may see a small percentage of events with this disposition; this is expected behavior.

- If the threat score associated with a file exceeds the malware threshold threat score defined in the file policy that detected the file, the Defense Center assigns a file disposition of Malware to the file.

- If the managed device detects a file whose SHA-256 value is stored on the custom detection list, the Defense Center assigns a file disposition of Custom Detection to the file.

- If the managed device detects a file on the clean list, the Defense Center assigns a file disposition of Clean to the file.

The Defense Center logs records of files’ detection and dispositions, along with other contextual data, as malware events.

Note Files detected in network traffic and identified as malware by the FireSIGHT System generate both a file event and a malware event. This occurs because to detect malware in a file, the system must first detect the file itself. For more information, see Working with File Events and Working with Captured Files.

Retrospective Malware Events

Supported Devices: Series 3, virtual

Supported Defense Centers: Any except DC500

For malware files detected in network traffic, file dispositions can change. For example, the Cisco cloud can determine that a file that was previously thought to be clean is now identified as malware, or the reverse — that a malware-identified file is actually clean.

The cloud notifies the Defense Center if the file disposition changes for a file for which you performed a malware lookup in the last week. Then, two things happen:

- The Defense Center generates a new retrospective malware event.

This new retrospective malware event represents a disposition change for all files detected in the last week that have the same SHA-256 hash value. For that reason, these events contain limited information: the date and time the Defense Center was notified of the disposition change, the new disposition, the SHA-256 hash value of the file, and the threat name. They do not contain IP addresses or other contextual information.

- The Defense Center changes the file disposition for previously detected files with the retrospective event’s associated SHA-256 hash value.

If a file’s disposition changes to Malware, the Defense Center logs a new malware event to its database. Except for the new disposition, the information in this new malware event is identical to that in the file event generated when the file was initially detected.

If a file’s disposition changes to Clean, the Defense Center does not remove the malware event from the malware table. Instead, the event simply reflects the change in disposition. This means that files with clean dispositions can appear in the malware table, but only if they were originally thought to be malware. Files that were never identified as malware appear only in the files table.

In either case, the malware event’s Message indicates how and when the disposition changed, for example:

Retrospective Event, Mon Oct 1 20:44:00 2012 (UTC), Old Disp: Unknown, New Disp: Malware

Using Malware Events

You can use the Defense Center’s event viewer to view, search, and delete malware events. Additionally, the Files Dashboard and Context Explorer provide an at-a-glance view of detailed information about the files (including malware files) detected on your network, using charts and graphs. Network file trajectory offers a more in-depth view of individual malware files, providing summary information about the file and how it has moved through the network over time. Using malware detection data, you can trigger correlation rules and create reports, the latter using either the predefined Malware Report template or a custom report template.

For more information, see:

- Viewing Malware Events

- Understanding the Malware Events Table

- Searching for Malware Events

Viewing Malware Events

License: Malware or Any

The FireSIGHT System’s event viewer allows you to view malware events in a table, as well as manipulate the event view depending on the information relevant to your analysis. Note that the information available for any individual malware event depends on several factors, including licenses. For more information, see Service Subscriptions.

The page you see when you access malware events differs depending on the workflow, which is simply a series of pages you can use to evaluate events by moving from a broad to a more focused view. The system is delivered with the following predefined workflows for malware events:

- Malware Summary , the default, provides a list of detected malware, grouped by individual threat.

- Malware Event Summary provides a quick breakdown of the different malware event types and subtypes.

- Hosts Receiving Malware and Hosts Sending Malware provide a list of hosts that have received or sent malware, grouped by the associated malware dispositions for those files. Note that dispositions appear only for files detected as the result of Malware Cloud Lookup or Block Malware file rules.

- Applications Introducing Malware provides a list of the client applications that accessed or executed the malware detected on endpoints in your organization. From this list, you can drill down into the individual malware files accessed by each parent client.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on specifying a different default workflow, including a custom workflow, see Configuring Event View Settings.

The FireSIGHT System supports the display and input of Unicode (UTF-8) file names in all areas of the web interface, including the event viewer, event search, dashboard, Context Explorer, and so on. Note, however, that reports you generate in PDF format do not support Unicode; Unicode file names appear in the PDF report in transliterated form. For more information, see Generating and Viewing Reports.

Using the event viewer, you can:

- search for, sort, and constrain events, as well as change the time range for displayed events

- specify the columns that appear (table view only)

- view the host profile associated with an IP address, or the user details and host history associated with a user identity

- view the connections where specific malware was detected (for network-based malware events only)

- view events using different workflow pages within the same workflow

- view events using a different workflow altogether

- drill down page-to-page within a workflow, constraining on specific values

- bookmark the current page and constraints so you can return to the same data (assuming the data still exists) at a later time

- view geolocation information for routable IP addresses associated with a file

- view a file’s trajectory

- view nested files inside an archive file

- create a report template using the current constraints

- delete events from the database

- add a file to a file list, download a file, submit a file for dynamic analysis, or view the full text of a file’s SHA-256 value

- view a file’s Dynamic Analysis Summary report, if available

- use the IP address context menu to whitelist, blacklist, or obtain additional available information about a host or IP address associated with a malware event

Note that Series 2 devices, Cisco NGIPS for Blue Coat X-Series, and the DC500 Defense Center do not support network-based malware protection or archive file inspection, which can affect the data displayed. For example, a Series 3 Defense Center managing only Series 2 devices can display only endpoint-based malware events.

For detailed information on using the event viewer, including creating custom workflows, see Understanding and Using Workflows.

To view malware events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Files > Malware Events.

The first page of your default malware events workflow appears. For information on the columns that appear, see Understanding the Malware Events Table.

Understanding the Malware Events Table

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The system logs malware events to the Defense Center database when a FireAMP Connector installed on an endpoint in your organization detects a threat, or a managed device detects a file in network traffic that is then identified as malware by a malware cloud lookup. The system also logs retrospective malware events when it learns that a file’s malware disposition has changed. Note that Series 2 devices, Cisco NGIPS for Blue Coat X-Series, and the DC500 Defense Center do not support network-based malware protection, which can affect the data displayed. For example, a Series 3 Defense Center managing only Series 2 devices can display only endpoint-based malware events. For more information, see Understanding Malware Protection and File Control and Working with Malware Events.

.

Keep in mind that not every field is populated for every event; the different types of malware event can contain different information. For example, because FireAMP malware detection is performed at the endpoint at download or execution time, endpoint-based malware events contain information on file path, invoking client application, and so on. In contrast, because managed devices detect malware files in network traffic, their associated malware events contain port, application protocol, and originating IP address information about the connection used to transmit the file.

The following table lists each malware event field, and indicates whether the system displays information in that field, depending on the malware event type. Note that the DC500 Defense Center does not support sending or receiving continent or country geolocation information.

Table 40-3 Malware Event Fields

Field

Description

Network

Endpoint

Retrospective

from Cloud

Time

The date and time the event was generated.

yes

yes

yes

Action

The file rule action associated with the rule action for the rule the file matched, and any associated file rule action options.

yes

no

yes

Sending IP

The IP address of the host sending detected malware.

yes

no

no

Sending Continent

The continent of the host sending detected malware.

yes

no

yes

Sending Country

The country of the host sending detected malware.

yes

no

no

Receiving IP

For network-based malware events, the IP address of the host receiving detected malware.

For endpoint-based malware events, the IP address of the endpoint where the FireAMP Connector is installed and where the malware event occurred.

yes

yes

no

Receiving Continent

The continent of the host receiving detected malware.

yes

no

yes

Receiving Country

The country of the host receiving detected malware.

yes

no

no

Sending Port

The source port used by the traffic in which a managed device detected malware.

yes

no

no

Receiving Port

The destination port used by the traffic in which a managed device detected malware.

yes

no

no

SSL Status

The action associated with the SSL rule, default action, or undecryptable traffic action that logged the encrypted connection:

- Block and Block with reset represent blocked encrypted connections.

- Decrypt (Resign) represents an outgoing connection decrypted using a re-signed server certificate.

- Decrypt (Replace Key) represents an outgoing connection decrypted using a self-signed server certificate with a substituted public key.

- Decrypt (Known Key) represents an incoming connection decrypted using a known private key.

- Do not Decrypt represents a connection the system did not decrypt.

If the system fails to decrypt an encrypted connection, it displays the undecryptable traffic action taken, as well as the failure reason. For example, if the system detects traffic encrypted with an unknown cipher suite and allowed it without further inspection, this field displays Do Not Decrypt (Unknown Cipher Suite).
) to view certificate details. For more information, see Viewing the Certificate Associated with an Encrypted Connection.

yes

no

no

User

The user of the host (Receiving IP) where the malware event occurred.

For network-based malware events, this user is determined by network discovery. Because the user is associated with the destination host, users are not associated with malware events where the user uploaded a malware file.

For endpoint-based malware events, FireAMP Connectors determine user names. FireAMP users cannot be tied to user discovery or control. They do not appear in the Users table, nor can you view details for these users.

yes

yes

no

Event Type

The type of malware event. For a full list of event types, see Malware Event Types.

yes

yes

yes

Event Subtype

The FireAMP action that led to malware detection, for example, Create, Execute, Move, or Scan.

no

yes

no

Threat Name

The name of the detected malware.

yes

yes

yes

File Name

The name of the malware file.

yes

yes

no

File Disposition

One of the following file dispositions:

- Malware indicates that the cloud categorized the file as malware, or that the file’s threat score exceeded the malware threshold defined in the file policy.

- Clean indicates that the cloud categorized the file as clean, or that a user added the file to the clean list.

- Unknown indicates that a malware cloud lookup occurred before the cloud assigned a disposition. The file is uncategorized.

- Custom Detection indicates that a user added the file to the custom detection list.

- Unavailable indicates that the Defense Center could not perform a malware cloud lookup. You may see a small percentage of events with this disposition; this is expected behavior.

Note that clean files appear in the malware table only if they were changed to clean; see Retrospective Malware Events.

yes

no

yes

File SHA256

The SHA-256 hash value of the file, as well as a network file trajectory icon representing the most recently detected file event and file disposition.

To view the network file trajectory, click the trajectory icon. For more information, see Analyzing Network File Trajectory.

yes

yes

yes

Threat Score

The threat score most recently associated with this file:

- Low (

)

- Medium (

)

- High (

)

- Very High (

)

To view the Dynamic Analysis Summary report, click the threat score icon.

yes

no

no

File Path

The file path of the malware file, not including the file name.

no

yes

no

File Type

The file type of the malware file, for example, HTML or MSEXE.

yes

yes

no

File Type Category

The general categories of file type, for example: Office Documents, Archive, Multimedia, Executables, PDF files, Encoded, Graphics, or System Files.

yes

yes

no

File Timestamp

The time and date the malware file was created.

no

yes

no

File Size (KB)

The size of the malware file, in kilobytes.

yes

yes

no

File URI

The originating URI of the malware file, for example, the URL where a user downloaded it.

yes

no

no

Archive Name

Name of the archive file (if any) with which the malware file is associated, for example, archive.zip.

yes

yes

no

Archive SHA256

The SHA-256 hash value of the archive file (if any) with which the malware file is associated. To view the contents of an archive file, right-click on that archive file’s event viewer row to open the context menu, then click View Archive Contents. For more information, see Viewing the Contents of Archived Files.

yes

yes

no

Archive Depth

The level (if any) at which the file was nested in an archive file, for example, 1 or 3.

yes

yes

no

Application File Name

The client application accessing the malware file when detection occurred. These applications are not tied to network discovery or application control.

no

yes

no

Application File SHA256

The SHA-256 hash value of the parent file accessing the FireAMP-detected or quarantined file when detection occurred.

no

yes

no

Application Protocol

The application protocol used by the traffic in which a managed device detected a malware file.

yes

no

no

Application Protocol, Client, or Web Application Category or Tag

Criteria that characterize the application to help you understand the application's function; see Table 45-2..

yes

no

yes

Client

The client application that runs on one host and relies on a server to send a file.

yes

no

yes

Web Application

The application that represents the content or requested URL for HTTP traffic detected in the connection.

yes

no

yes

IOC

Whether the malware event triggered an indication of compromise (IOC) against a host involved in the connection. When endpoint-based malware detection triggers an IOC rule, a full malware event is generated, with the type FireAMP IOC. For more information on IOC, see Understanding Indications of Compromise.

yes

yes

yes

Application Risk

The risk associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated risk; this field displays the highest of those. For more information, see Table 45-2.

yes

no

yes

Business Relevance

The business relevance associated with the application traffic detected in the connection: Very High, High, Medium, Low, or Very Low. Each type of application detected in the connection has an associated business relevance; this field displays the lowest (least relevant) of those. For more information, see Table 45-2.

yes

no

yes

Detector

The FireAMP detector that identified the malware, such as ClamAV, Spero, or SHA.

no

yes

no

Message

Any additional information associated with the malware event.

For network-based malware events, this field is populated only for files whose disposition has changed; see Retrospective Malware Events.

yes

yes

no

FireAMP Cloud

The name of the FireAMP cloud where the event originated.

no

yes

no

Device

For network-based malware events, the name of the device that detected the malware file.

For endpoint-based malware events and retrospective malware events generated by the cloud, the name of the Defense Center.

yes

yes

yes

Security Context

The metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

yes

yes

yes

Count

The number of events that match the information in each row. This field appears after you apply a constraint that creates two or more identical rows.

n/a

n/a

n/a

Malware Event Types

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

For network-based malware events, the event type can be one of:

- Threat Detected in Network File Transfer

- Threat Detected in Network File Transfer (retrospective)

An endpoint-based malware event can have any of the following types:

- Blocked Execution

- Cloud Recall Quarantine

- Cloud Recall Quarantine Attempt Failed

- Cloud Recall Quarantine Started

- Cloud Recall Restore from Quarantine

- Cloud Recall Restore from Quarantine Failed

- Cloud Recall Restore from Quarantine Started

- FireAMP IOC

- Quarantine Failure

- Quarantined Item Restored

- Quarantine Restore Failed

- Quarantine Restore Started

- Scan Completed, No Detections

- Scan Completed With Detections

- Scan Failed

- Scan Started

- Threat Detected

- Threat Detected in Exclusion

- Threat Quarantined

If a file’s trajectory map contains malware events, the events are one of the following types: Threat Detected in Network File Transfer, Threat Detected in Network File Transfer (retrospective), Threat Detected, Threat Detected in Exclusion, and Threat Quarantined. See Working with Network File Trajectory for more information.

Note that Series 2 devices, Cisco NGIPS for Blue Coat X-Series, and the DC500 Defense Center do not support network-based malware protection, which can affect the data displayed. For example, a Series 3 Defense Center managing only Series 2 devices can display only endpoint-based malware events.

Searching for Malware Events

License: Malware or Any

Using the Defense Center’s Search page, you can search for specific malware events, display the results in the event viewer, and save your search criteria to reuse later. Custom Analysis dashboard widgets, report templates, and custom user roles can also use saved searches.

Searches delivered with the system, labeled with (Cisco) in the Saved Searches list, serve as examples.

Keep in mind that your search results depend on the available data in the events you are searching. In other words, depending on the available data, your search constraints may not apply. For example, because endpoint-based malware events are not generated as a result of managed devices inspecting network traffic, they do not contain connection information (port, application protocol, and so on).

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for Malware Events

To supplement the general search syntax listed above, the following list describes some special search syntax for malware events.

Sending/Receiving IP

The system returns all events where either the Sending IP or the Receiving IP matches the IP address you specify.

Event Type

When searching for events with a specific malware event type (see Malware Event Types), enclose the event type in quotation marks, for example, "Scan Completed With Detection". Otherwise, the system performs a partial match. That is, if you search using the same string but do not use quotation marks, the system returns events with the following types:

– Scan Completed, No Detections

– Scan Completed With Detection

Initiator/Responder Continent

The system returns all events where either the Initiator Continent or the Responder Continent matches the continent you specify.

Initiator/Responder Country

The system returns all events where either the Initiator Country or the Responder Country matches the country you specify.

URI or Message

The system performs a partial match, that is, you can search for all or part of the field contents without using asterisks.

The SSL Actual Action taken

Type any of the following keywords to view malware events for encrypted traffic to which the system applied the action specified:

– Do Not Decrypt represents connections the system did not decrypt.

– Block and Block with Reset represent blocked encrypted connections.

– Decrypt (Known Key) represents incoming connections decrypted using a known private key.

– Decrypt (Replace Key) represents outgoing connections decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Resign) represents outgoing connections decrypted using a re-signed server certificate.

This column does not appear in the malware events table view.

The SSL Failure Reason

Type any of the following keywords to view malware events for encrypted traffic that the system failed to decrypt for the reason specified:

– Unknown

– No Match

– Success

– Uncached Session

– Unknown Cipher Suite

– Unsupported Cipher Suite

– Unsupported SSL Version

– SSL Compression Used

– Session Undecryptable in Passive Mode

– Handshake Error

– Decryption Error

– Pending Server Name Category Lookup

– Pending Common Name Category Lookup

– Internal Error

– Network Parameters Unavailable

– Invalid Server Certificate Handle

– Server Certificate Fingerprint Unavailable

– Cannot Cache Subject DN

– Cannot Cache Issuer DN

– Unknown SSL Version

– External Certificate List Unavailable

– External Certificate Fingerprint Unavailable

– Internal Certificate List Invalid

– Internal Certificate List Unavailable

– Internal Certificate Unavailable

– Internal Certificate Fingerprint Unavailable

– Server Certificate Validation Unavailable

– Server Certificate Validation Failure

– Invalid Action

This column does not appear in the malware events table view.

The SSL Subject Country

Type a two-character ISO 3166-1 alpha-2 country code to view malware events for encrypted traffic associated with the country of a certificate subject.

This column does not appear in the malware events table view.

The SSL Issuer Country

Type a two-character ISO 3166-1 alpha-2 country code to view encrypted traffic associated with the country of a certificate issuer.

This column does not appear in the malware events table view.

SSL Certificate Fingerprint

Type or paste the SHA hash value used to authenticate a certificate to view traffic associated with that certificate.

This column does not appear in the malware events table view.

SSL Public Key Fingerprint

Type or paste the SHA hash value used to authenticate the public key contained within a certificate to view traffic associated with that certificate.

This column does not appear in the malware events table view.

To search for malware events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Malware Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields as described in the following sections:

- See the Malware Event Fields table for information on the fields in the malware events table.

- See Special Search Syntax for Malware Events for special search syntax for malware events.

- See Viewing the Certificate Associated with an Encrypted Connection for fields related to public key certificates.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the checkbox clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in your default malware events workflow, constrained by the current time range.

Working with Captured Files

License: Malware

Supported Devices: Any except Series 2 or X-Series

Supported Defense Centers: Any except DC500

The system logs when a managed device captures a file detected in network traffic according to the rules in currently applied file policies. From the event viewer, you can view information associated with the captured file, such as the most recent file name associated with the SHA-256 value, the file disposition and threat score, the file storage status, the archive inspection status, and whether the file was manually submitted for dynamic analysis.

Note Files captured by a device containing malware generate both a file event and a malware event, as malware must be detected before it is captured. For more information, see Working with File Events and Working with Malware Events.

You can use the Defense Center’s event viewer to view and search captured files, as well as submit captured files for dynamic analysis. Additionally, the Files Dashboard provides an at-a-glance view of detailed information about the files (including malware files) detected on your network, using charts and graphs.

For more information, see:

- Viewing Captured Files

- Understanding the Captured Files Table

- Searching for Captured Files

Viewing Captured Files

License: Malware

The FireSIGHT System’s event viewer allows you to view captured files in a table, as well as manipulate the event view depending on the information relevant to your analysis.

The page you see when you access captured files differs depending on the workflow, which is simply a series of pages you can use to evaluate events by moving from a broad to a more focused view. The system is delivered with the following predefined workflows for captured files:

- Captured File Summary , the default, provides a breakdown of captured files based on type, category, and threat score.

- Dynamic Analysis Status provides a count of captured files based on whether they have been submitted for dynamic analysis.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on specifying a different default workflow, including a custom workflow, see Configuring Event View Settings.

The FireSIGHT System supports the display and input of Unicode (UTF-8) file names in all areas of the web interface, including the event viewer, event search, dashboard, Context Explorer, and so on. Note, however, that reports you generate in PDF format do not support Unicode; Unicode file names appear in the PDF report in transliterated form. For more information, see Generating and Viewing Reports.

Using the event viewer, you can:

- search for, sort, and constrain events, as well as change the time range for displayed events

- specify the columns that appear (table view only)

- view events using different workflow pages within the same workflow

- view events using a different workflow altogether

- drill down page-to-page within a workflow, constraining on specific values

- bookmark the current page and constraints so you can return to the same data (assuming the data still exists) at a later time

- view a file’s trajectory

- view the contents and inspection status of an archive file

- add a file to a file list, download a file, submit a file for dynamic analysis, or view the full text of a file’s SHA-256 value

- view a file’s Dynamic Analysis Summary report, if available

- submit up to 25 files at a time for dynamic analysis

- create a report template using the current constraints

Note that Series 2 devices, Cisco NGIPS for Blue Coat X-Series, and the DC500 Defense Center do not support network-based malware protection or archive file inspection, which can affect the data displayed. For example, a Series 3 Defense Center managing only Series 2 devices cannot display captured files.

For detailed information on using the event viewer, including creating custom workflows, see Understanding and Using Workflows.

To view file events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Files > Captured Files.

The first page of your default file events workflow appears. For information on the columns that appear, see Understanding the Captured Files Table.

Understanding the Captured Files Table

License: Malware

The Defense Center logs when a managed device captures a file being transmitted in monitored network traffic, according to the settings in an applied file policy.

. The following table describes the captured file fields.

Table 40-4 Captured File Fields

Field

Description

Last Changed

The last time the information associated with this file was updated.

File Name

The most recently detected file name associated with the file’s SHA-256 hash value.

Disposition

One of the following file dispositions:

- Malware indicates that the cloud categorized the file as malware, or that the file’s threat score exceeded the malware threshold defined in the file policy.

- Clean indicates that the cloud categorized the file as clean, or that a user added the file to the clean list.

- Unknown indicates that a malware cloud lookup occurred before the cloud assigned a disposition. The file is uncategorized.

- Custom Detection indicates that a user added the file to the custom detection list.

- Unavailable indicates that the Defense Center could not perform a malware cloud lookup. You may see a small percentage of events with this disposition; this is expected behavior.

- N/A indicates a Detect Files or Block Files rule handled the file and the Defense Center did not perform a malware cloud lookup.

SHA256

The SHA-256 hash value of the file, as well as a network file trajectory icon representing the most recently detected file event and file disposition.

To view the network file trajectory, click the trajectory icon. For more information, see Analyzing Network File Trajectory.

Threat Score

The threat score most recently associated with this file:

- Low (

)

- Medium (

)

- High (

)

- Very High (

)

To view the Dynamic Analysis Summary report, click the threat score icon.

Type

The type of file, for example, HTML or MSEXE.

Category

The general categories of file type, for example: Office Documents, Archive, Multimedia, Executables, PDF files, Encoded, Graphics, or System Files.

Storage Status

Whether the file is stored on a managed device.

Archive Inspection Status

For archive files, the status of archive inspection:

- Pending indicates that the system is still inspecting the archive file and its contents. If the file passes through your system again, complete information becomes available.

- Extracted indicates that the system was able to extract and inspect the archive’s contents.

- Failed may, in rare cases, occur if the system is unable to process an extraction.

- Depth Exceeded indicates that the archive contains further nested archive files beyond the maximum allowed depth.

- Encrypted indicates that the archive file’s contents are encrypted and could not be inspected.

- Not Inspectable indicates that the system did not extract and inspect the archive’s contents. Policy rule actions, policy configuration, and corrupted files are three major reasons for this status.

To view the contents of an archive file, right-click on its event viewer row to bring up the context menu, then select View Archive Contents. For more information, see Configuring Archive File Inspection Options.

Analysis Status

Whether the file was submitted for dynamic analysis.

Last Sent

The time the file was most recently submitted to the cloud for dynamic analysis.

Searching for Captured Files

License: Malware

Using the Defense Center’s Search page, you can search for specific captured files, display the results in the event viewer, and save your search criteria to reuse later. Custom Analysis dashboard widgets, report templates, and custom user roles can also use saved searches.

Keep in mind that your search results depend on the available data in the events you are searching. In other words, depending on the available data, your search constraints may not apply. For example, if a file has never been submitted for dynamic analysis, it may not have an associated threat score.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for Captured Files

Table 40-5 Captured Files Special Search Syntax

Search Criterion

Special Syntax

Storage Status

Specify one or more of the following:

- File Stored - returns all captured files stored on the device

- Unable to Store File - returns all captured files not stored on the device

Dynamic Analysis Status

Specify one or more of the following:

- Sent for Analysis - returns all captured files queued for dynamic analysis

- Not Sent for Analysis - returns all captured files not submitted for dynamic analysis

- Analysis Complete - returns all captured files submitted for dynamic analysis that received a threat score and dynamic analysis summary report

- Previously Analyzed - returns all files with a cached threat score that a user tried to submit for dynamic analysis again

- Failure (Analysis Timeout) - returns all captured files submitted for dynamic analysis for which the cloud has yet to return a result

- Failure (Network Issue) - returns all files that did not get submitted for dynamic analysis due to a network connectivity failure

- Failure (Cannot Run File) - returns all files submitted for dynamic analysis that the cloud could not run in the test environment

To search for captured files:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Captured Files from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields.

See the Captured File Fields table for information on the fields in the captured files table.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in your default captured file workflow, constrained by the current time range.

Working with Network File Trajectory

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The network file trajectory feature maps how hosts transferred files, including malware files, across your network. You can use the map to determine which hosts may have transferred malware, which hosts are at risk, and observe file transfer trends.

The trajectory map charts file transfer data, the disposition of the file, and if a file transfer was blocked or the file was quarantined. The data used to build the map can come from network-based malware events (any file event for which the system performed a malware cloud lookup and returned a malware disposition) and certain endpoint-based malware events related to detecting and blocking malware (any Threat Detected or Threat Quarantined event type). Vertical lines between data points represent file transfers between hosts. Horizontal lines connecting the data points show a host’s file activity over time.

You can track the transmission of any file type for which the system can perform a malware cloud lookup. To directly access a file’s trajectory, you can use the Network File Trajectory List page (Analysis > Files > Network File Trajectory) and locate specific files. Additionally, if you are analyzing an intrusion and want to review the trajectory for a related file, you can access the file’s trajectory from the Context Explorer, dashboard, or event views of connection, file, or malware events.

Table 40-6 License Requirements for Network File Trajectory

To view...

You need the following license...

network-based file and malware trajectories

Malware

endpoint-based threat and quarantine tracking

Any (you must have a FireAMP subscription)

See Understanding Malware Protection and File Control for more information.

Note that because you cannot use a Malware license with a DC500 nor enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to capture, store or block individual files, submit files for dynamic analysis, view the contents of archive files, or view file trajectories for files for which you conduct a malware cloud lookup. You can, however, still view file trajectories for endpoint-based threat and quarantine tracking.

For more information, see the following sections:

- Reviewing Network File Trajectory

- Analyzing Network File Trajectory

Reviewing Network File Trajectory

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

As you review captured files, file events, and malware events, you can view a file’s trajectory map from the Context Explorer, properly configured dashboard widgets, and various event views. You can also review the most recently viewed network file trajectories and the most recently detected malware from the Network File Trajectory List page.

For more information, see the following sections:

- Viewing the Top File Names Graph

- Drilling Down on Context Explorer Data

- Understanding the Custom Analysis Widget

- Configuring Archive File Inspection Options

- Understanding the File Events Table

- Understanding the Malware Events Table

- Understanding the Captured Files Table

- Information Available in Connection and Security Intelligence Events

- Accessing Network File Trajectory

Accessing Network File Trajectory

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Network File Trajectory List page allows you to locate files that have a SHA-256 hash value, whether to analyze the most recently detected malware, or to track a specific threat.

The page displays the malware most recently detected on your network, as well as the files whose trajectory maps you have most recently viewed. From these lists, you can view when the file was most recently seen on the network, the file’s SHA-256 hash value, name, type, current file disposition, contents (for archive files), and the number of events associated with the file. For more information on the fields, see Understanding the File Events Table.

The page also contains a search box that lets you locate files, either based on SHA-256 hash value or file name, or by the IP address of the host that transferred or received a file. After you locate a file, you can click the File SHA256 value to view the detailed trajectory map. See Analyzing Network File Trajectory for more information.

The FireSIGHT System supports the display and input of Unicode (UTF-8) file names in all areas of the web interface, including the event viewer, event search, dashboard, Context Explorer, and so on. Note, however, that reports you generate in PDF format do not support Unicode; Unicode file names appear in the PDF report in transliterated form. For more information, see Generating and Viewing Reports.

Note that because you cannot use a Malware license with a DC500, nor can you enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to view file trajectories for files for which you conduct a malware cloud lookup.

To locate a file from the Network File Trajectory List page:

Access: Any

Step 1 Select Analysis > Files > Network File Trajectory.

The Network File Trajectory List page appears, displaying the lists of recently viewed files and recent malware.

Step 2 Optionally, you can type a complete SHA-256 hash value, host IP address, or file name of a file you want to track into the search field and press Enter.

The Query Results page appears listing all files that match the search. If only one result matches, the Network File Trajectory page for that file appears.

Analyzing Network File Trajectory

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

You can trace a file through the network by viewing the detailed network file trajectory. The file’s trajectory presents summary information about a file, displays the map charting data points over time, and also lists the event data tied to the data points in a table. Using the table and the map, you can pinpoint specific file events, hosts on the network that transferred or received this file, related events in the map, and other related events in a table constrained on selected values.

Note that because you cannot use a Malware license with a DC500, nor can you enable a Malware license on a Series 2 device or Cisco NGIPS for Blue Coat X-Series, you cannot use those appliances to view file trajectories for files for which you conduct a malware cloud lookup.

For more information, see the following sections:

- Summary Information

- Trajectory Map

- Events Table

Summary Information

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

A file’s trajectory page displays basic information about the file, including file identification information, when the file was first seen and most recently seen on the network, the number of related events and hosts associated with the file, and the file’s current disposition. From this section, if the managed device stored the file, you can download it locally, submit the file for dynamic analysis, or add the file to a file list.

Tip To view related file events, click a field value link. The first page in the File Events default workflow opens in a new window, displaying all file events that also contain the selected value.

For more information about archive file inspection, see Configuring Archive File Inspection Options.

Table 40-7 Network File Trajectory Summary Information Fields

Name

Description

File SHA256

The SHA-256 hash value of the file.

The hash is displayed by default in a condensed format. To view the full hash value, hover your pointer over it. If multiple SHA-256 hash values are associated with a file name, hover your pointer over the link to view all of the hash values.
) to download the file to your local computer. If prompted, confirm you want to download the file. Follow your browser’s prompts to save the file. If the file is unavailable for download, this icon is grayed out.

Caution Cisco strongly recommends you do not download malware, as it can cause adverse consequences. Exercise caution when downloading any file, as it may contain malware. Ensure you have taken any necessary precautions to secure the download destination before downloading files.

File Names

The names of the file associated with the event, as seen on the network.

If multiple file names are associated with a SHA-256 hash value, the most recent detected file name is listed. You can expand this to view the remaining file names by clicking more.

File Type

The file type of the file, for example, HTML or MSEXE.

File Category

The general categories of file type, for example, Office Documents or System Files.

Parent Application

The client application accessing the malware file when detection occurred. These applications are not tied to network discovery or application control.

This field only appears for endpoint-based malware events.

First Seen

The first time a managed device or FireAMP Connector detected the file, and the IP address of the host that first uploaded the file.

Last Seen

The most recent time a managed device or FireAMP Connector detected the file, and the IP address of the host that last downloaded the file.

Event Count

The number of events seen on the network associated with the file, and the number of events displayed in the map if there are more than 250 detected events.

Seen On

The number of hosts that either sent or received the file. Because one host can upload and download a file at different times, the total number of hosts may not match the total number of senders plus the total number of receivers in the Seen On Breakdown field.

Seen On Breakdown

The number of hosts that sent the file, followed by the number of hosts that received the file.

Current Disposition

One of the following file dispositions:

- Malware indicates that the cloud categorized the file as malware, or that the file’s threat score exceeded the malware threshold defined in the file policy.

- Clean indicates that the cloud categorized the file as clean, or that a user added the file to the clean list.

- Unknown indicates that a malware cloud lookup occurred before the cloud assigned a disposition. The file is uncategorized.

- Custom Detection indicates that a user added the file to the custom detection list.

- Unavailable indicates that the Defense Center could not perform a malware cloud lookup. You may see a small percentage of events with this disposition; this is expected behavior.

- N/A indicates a Detect Files or Block Files rule handled the file and the Defense Center did not perform a malware cloud lookup.

) to add the file to or remove the file from the clean list or custom detection list.
This field only appears for network-based malware events.

Archive Contents

) to view information about content files in the Archive Contents window.

Threat Name

Name of the malware threat associated with the file.

This field only appears for endpoint-based malware events.

Threat Score

The file’s threat score:

- Low (

)

- Medium (

)

- High (

)

- Very High (

).

Click the threat score icon to view the Dynamic Analysis Summary report, click the threat score icon.

Click the threat score link to view all captured files with that threat score.
) to submit the file to the cloud for dynamic analysis. If the file is unavailable for submission or you cannot connect to the cloud, this icon is grayed out.

Trajectory Map

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

A file’s trajectory map visually tracks a file from the first detection on your network to the most recent. The map shows when hosts transferred or received the file, how often they transferred the file, and when the file was blocked or quarantined. The map also shows how often file events occurred for the file and when the system assigned the file a disposition or retrospective disposition. You can select a data point in the map and highlight a path that traces back to the first instance the host transferred that file; this path also intersects with every occurrence involving the host as either sender or receiver of the file. The following graphic shows an example trajectory map:

The map’s y-axis contains a list of all host IP addresses that have interacted with the file. The IP addresses are listed in descending order based on when the system first detected the file on that host. Each row contains all events associated with that IP address, whether a single file event, file transfer, or retrospective event. The x-axis contains the date and time the system detected each event. The timestamps are listed in chronological order. If multiple events occurred within a minute, all are listed within the same column. You can scroll the map horizontally and vertically to view additional events and IP addresses.

). The map then displays the remaining 240 events. The following graphic shows events truncated with the arrow icon:

). The first page of the File Events default workflow appears in a new window with all the extra events constrained based on the file type. If endpoint-based malware events are not displayed, you must switch to the Malware Events table to view these.

Each data point represents an event plus the file disposition, as described in the legend below the map. For example, a Malware Block event icon combines the Malicious Disposition icon and the Block Event icon.

Endpoint-based malware events include one icon. A retrospective event displays an icon in the column for each host on which the file is detected. File transfer events always include two icons, one file send icon and one file receive icon, connected by a vertical line. Arrows indicate the file transfer direction from sender to receiver.

). The displayed summary information matches the information displayed in the Events table. The following graphic shows an event icon’s summary information:

If you click any event summary information link, the first page of the File Events default workflow appears in a new window with all the extra events constrained based on the file type the File Summary event view opens in a new window, displaying all file events that match on the criteria value you clicked.

To locate the first time a file event occurred involving an IP address, click the address. This highlights a path to that data point, as well as any intervening file events and IP addresses related to the first file event. The corresponding event in the Events table is also highlighted. The map scrolls to that data point if not currently visible. The following graphic shows the path highlighted after clicking an IP address:

To track a file’s progress through the network, you can click any data point to highlight a path that includes all data points related to the selected data point. This includes data points associated with the following types of events:

- any file transfers in which the associated IP address was either sender or receiver

- any endpoint-based malware events involving the associated IP address

- if another IP address was involved, all file transfers in which that associated IP address was either sender or receiver

- if another IP address was involved, any endpoint-based malware events involving the other IP address

The following graphic shows the path highlighted after clicking an event icon:

All IP addresses and timestamps associated with any highlighted data point are also highlighted. The corresponding event in the Events table is also highlighted. If a path includes truncated events, the path itself is highlighted with a dotted line. Truncated events might intersect the path, but are not displayed in the map.

Events Table

License: Malware or Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Working with Intrusion Events

The FireSIGHT System can help you monitor your network for traffic that could affect the availability, integrity, and confidentiality of a host and its data. By placing managed devices on key network segments, you can examine the packets that traverse your network for malicious activity. The system has several mechanisms it uses to look for the broad range of exploits that attackers have developed.

When the system identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. Managed devices transmit their events to the Defense Center where you can view the aggregated data and gain a greater understanding of the attacks against your network assets.

You can also deploy a managed device as an inline, switched, or routed intrusion system, which allows you to configure the device to drop or replace packets that you know to be harmful.

The FireSIGHT System also provides you with the tools you need to review intrusion events and evaluate whether they are important in the context of your network environment and your security policies. These tools include:

- an event summary page that gives you an overview of the current activity on your managed devices

- text-based and graphical reports that you can generate for any time period you choose; you can also design your own reports and configure them to run at scheduled intervals

- an incident-handling tool that you can use to gather event data related to an attack; you can also add notes to help you track your investigation and response

- automated alerting that you can configure for SNMP, email, and syslog

- automated correlation policies that you can use to respond to and remediate specific intrusion events

- predefined and custom workflows that you can use to drill down through the data to identify the events that you want to investigate further

See the following sections for more information:

- Viewing Intrusion Event Statistics describes the Intrusion Event Statistics page, which provides you with an overview of the health of the appliance and a summary of the top threats to your network.

- Viewing Intrusion Event Performance explains how to generate graphs of intrusion event performance statistics.

- Viewing Intrusion Event Graphs explains how to generate charts that show event trends over time.

- Viewing Intrusion Events describes how to use the web interface to view and investigate your intrusion events.

- Understanding Workflow Pages for Intrusion Events describes the various pages that are available in intrusion event workflows and explains how you can use them to analyze your intrusion events.

- Using Drill-Down and Table View Pages describes the features of two of the types of pages in an intrusion event workflow.

- Using the Packet View explains how to use the packet view of intrusion events.

- Using Impact Levels to Evaluate Events describes how you can use impact levels to evaluate intrusion events.

- Reading Preprocessor Events explains how you can read events generated by preprocessor rules.

- Searching for Intrusion Events explains how you can use the search feature to constrain a list of intrusion events to specific criteria.

- Using the Clipboard describes how to add intrusion events to a holding area called the clipboard so that you can later add the events to incidents. This section also explains how to generate event reports based on the contents of the clipboard.

Also, see:

- Handling Incidents for more information about incident handling and how you can use incidents to track the progress of an event analysis.

- Configuring External Alerting for Intrusion Rules for more information about automated alerting.

- Working with Reports for more information about intrusion event reports.

- Using Geolocation for more information about geolocation information in intrusion events.

Viewing Intrusion Event Statistics

License: Protection

The Intrusion Event Statistics page provides you with a quick summary of the current state of your appliance and any intrusion events generated for your network.

The Intrusion Event Statistics page has three main areas:

- Host Statistics describes the Host Statistics section, which provides information about the appliance and, for Defense Centers, their managed devices.

- Event Overview describes the Event Overview, which provides an overview of the information in the event database.

- Event Statistics describes the Event Statistics, which provides more specific details about the information in the event database, such as the top 10 event types.

Each of the IP addresses, ports, protocols, event messages, and so on on the page is a link. Click any link to view the associated event information. For example, if one of the top 10 destination ports is 80 (http)/tcp, clicking that link displays the first page in the default intrusion events workflow, and lists the events targeting that port. Note that only the events (and the managed devices that generate events) in the current time range appear. Also, intrusion events that you have marked reviewed continue to appear in the statistics. For example, if the current time range is the past hour but the first event was generated five hours ago, when you click the First Event link, the resulting event pages will not show the event until you change the time range.

To view intrusion event statistics:

Access: Admin/Intrusion Admin

Step 1 Select Overview > Summary > Intrusion Event Statistics.

The Intrusion Event Statistics page appears.

Step 2 From the two selection boxes at the top of the page, select the zones and devices whose statistics you want to view, or select All Security Zones and All Devices to view statistics for all the devices that are collecting intrusion events.

Step 3 Click Get Statistics.

The Intrusion Event Statistics page refreshes with data from the devices you selected.

Tip To view data from a custom time range, click the link in the upper right page area and follow the directions in Setting Event Time Constraints.

Step 4 See the following sections for more information about the statistics that appear on the Intrusion Event Statistics page:

- Host Statistics

- Event Overview

- Event Statistics

Host Statistics

License: Protection

The Host Statistics section of the Intrusion Event Statistics page provides information about the appliance itself. On the Defense Center, this section also provides information about any managed devices.

This information includes the following:

- Time shows the current time on the appliance.

- Uptime shows the number of days, hours, and minutes since the appliance itself was restarted. On the Defense Center, the uptime also shows the last time each managed device was rebooted, the number of users logged in, and the load average.

- Disk Usage shows the percentage of the disk that is being used.

- Memory Usage shows the percentage of system memory that is being used.

- Load Average shows the average number of processes in the CPU queue for the past 1 minute, 5 minutes, and 15 minutes.

Event Overview

License: Protection

The Event Overview section of the Intrusion Event Statistics page provides an overview of the information in the intrusion event database.

These statistics include the following:

- Events shows the number of events in the intrusion event database.

- Events in Time Range shows the currently selected time range as well as the number and percentage of events from the database that fall within the time range.

- First Event shows the event message for the first event in the event database.

- Last Event shows the event message for the last event in the event database.

Note On the Defense Center, note that if you selected a managed device, the Event Overview section for that device appears instead.

Event Statistics

License: Protection

The Event Statistics section of the Intrusion Event Statistics page provides more specific information about of the information in the intrusion event database.

This information includes details on:

- the top 10 event types

- the top 10 source IP addressees

- the top 10 destination IP addresses

- the top 10 destination ports

- the protocols, ingress and egress security zones, and devices with the greatest number of events

Viewing Intrusion Event Performance

License: Protection

The intrusion event performance page allows you to generate graphs that depict performance statistics for intrusion events over a specific period of time. Graphs can be generated to reflect number of intrusion events per second, number of megabits per second, average number of bytes per packet, the percent of packets uninspected by Snort, and the number of packets blocked as the result of TCP normalization. These graphs can show statistics for the last hour, last day, last week, or last month of operation.

See Generating Intrusion Event Performance Statistics Graphs for more information.

To view the intrusion event performance statistics:

Access: Admin/Maint

Step 1 Select Overview > Summary > Intrusion Event Performance.

The Intrusion Event Performance page appears.

Generating Intrusion Event Performance Statistics Graphs

License: Protection

You can generate graphs that depict performance statistics for a Defense Center or a managed device based on the number of events per second, megabits per second, average bytes per packet, percent of packets uninspected by Snort, and the number of packets blocked as the result of TCP normalization.

Note New data is accumulated for statistics graphs every five minutes. Therefore, if you reload a graph quickly, the data may not change until the next five-minute increment occurs.

The following table lists the available graph types. Note that graph types display differently if they are populated with data affected by the network analysis policy Inline Mode setting. If Inline Mode is disabled, the graph types marked with an asterisk (*) in the web interface (a yes in the column below) populate with data about the traffic the system would have modified or dropped if Inline Mode was enabled. For more information about the Inline Mode setting, see Allowing Preprocessors to Affect Traffic in Inline Deployments.

For more information about the required options and settings, see Normalizing Inline Traffic, Allowing Preprocessors to Affect Traffic in Inline Deployments, and Setting Drop Behavior in an Inline Deployment.

Table 41-1 Intrusion Event Performance Graph Types

To generate data for...

You must...

Which represents...

Affected by Inline Mode?

Avg Bytes/Packet

n/a

the average number of bytes included in each packet.

no

ECN Flags Normalized in TCP Traffic/Packet

enable Explicit Congestion Notification and select Packet

the number of packets for which ECN flags have been cleared on a per-packet basis regardless of negotiation.

yes

ECN Flags Normalized in TCP Traffic/Session

enable Explicit Congestion Notification and select Stream

the number of times that ECN flags have been cleared on a per-stream basis when ECN use was not negotiated.

yes

Events/Sec

n/a

the number of events per second generated on the device.

no

ICMPv4 Echo Normalizations

enable Normalize ICMPv4

the number of ICMPv4 packets for which the 8-bit Code field in Echo (Request) or Echo Reply messages were cleared.

yes

ICMPv6 Echo Normalizations

enable Normalize ICMPv6

the number of ICMPv6 packets for which the 8-bit Code field in Echo (Request) or Echo Reply messages was cleared.

yes

IPv4 DF Flag Normalizations

enable Normalize IPv4 and Normalize Don’t Fragment Bit

the number of IPv4 packets for which the single-bit Don’t Fragment subfield of the IPv4 Flags header field was cleared.

yes

IPv4 Options Normalizations

enable Normalize IPv4

the number of IPv4 packets for which the option octet was set to 1 (No Operation).

yes

IPv4 Reserved Flag Normalizations

enable Normalize IPv4 and Normalize Reserved Bit

the number of IPv4 packets for which the single-bit Reserved subfield of the IPv4 Flags header field was cleared.

yes

IPv4 Resize Normalizations

enable Normalize IPv4

the number of IPv4 packets with excessive-length payload that have been truncated to the datagram length specified in the IP header.

yes

IPv4 TOS Normalizations

enable Normalize IPv4 and Normalize TOS Bit

the number of IPv4 packets for which the one-byte Differentiated Services (DS) field (formerly known as the Type of Service (TOS) field) was cleared.

yes

IPv4 TTL Normalizations

enable Normalize IPv4, Maximum TTL, and Reset TTL

the number of IPv4 Time to Live normalizations.

yes

IPv6 Options Normalizations

enable Normalize IPv6

the number of IPv6 packets for which the Option Type field in the Hop-by-Hop Options or Destination Options extension header was set to 00 (Skip and continue processing).

yes

IPv6 TTL Normalizations

enable Normalize IPv6, Minimum TTL, and Reset TTL

the number of IPv6 Hop Limit (TTL) normalizations.

yes

Mbits/Sec

n/a

the number of megabits per second of traffic that passes through the device.

no

Packet Resized to Fit MSS Normalizations

enable Trim Data to MSS

the number of packets for which the payload was longer than the TCP Data field, so the payload was trimmed to the Maximum Segment Size.

yes

Packet Resized to Fit TCP Window Normalizations

enable Trim Data to Window

the number of packets for which the TCP Data field was trimmed to fit the receiving host’s TCP window.

yes

Percent Packets Dropped

n/a

the average percentage of uninspected packets across all selected devices. For example, if you select two devices, then an average of 50% may indicate that one device has a 90% drop rate and the other has a 10% drop rate. It may also indicate that both devices have a drop rate of 50%. The graph only represents the total % drop when you select a single device.

no

RST Packets With Data Stripped Normalizations

enable Remove Data on RST

the number of packets for which data was removed from a TCP reset (RST) packet.

yes

SYN Packets With Data Stripped Normalizations

enable Remove Data on SYN

the number of packets for which data was removed from SYN packets when the TCP operating system was not Mac OS.

yes

TCP Header Padding Normalizations

enable Normalize/Clear Option Padding Bytes

the number of TCP packets in which option padding bytes were set to 0.

yes

TCP No Option Normalizations

enable Allow These TCP Options and set to an option other than any

the number of packets from which the Time Stamp option was stripped.

yes

TCP NS Flag Normalizations

enable Explicit Congestion Notification and select Packet

the number of ECN Nonce Sum (NS) option normalizations.

yes

TCP Options Normalizations

enable Allow These TCP Options and set to an option other than any

the number of options (excluding MSS, Window Scale, Time Stamp, and explicitly allowed options) for which the option field is set to No Operation (TCP Option 1).

yes

TCP Packets Blocked By Normalizations

enable Normalize TCP Payload (segment reassembly must fail)

the number of packets dropped because the TCP segments could not be properly reassembled.

yes

TCP Reserved Flags Normalizations

enable Normalize/Clear Reserved Bits

the number of TCP packets where the Reserved bits have been cleared.

yes

TCP Segment Reassembly Normalizations

enable Normalize TCP Payload (segment reassembly must be successful)

the number of packets for which the TCP Data field was normalized to ensure consistency in retransmitted data (any segments that cannot be properly reassembled are dropped).

yes

TCP SYN Option Normalizations

enable Allow These TCP Options and set to an option other than any

the number of options for which the Maximum Segment Size or Window Scale option was set to No Operation (TCP Option 1) because the SYN control bit was not set.

yes

TCP Timestamp ECR Normalizations

enable Allow These TCP Options and set to an option other than any

the number of packets for which the Time Stamp Echo Reply (TSecr) option field was cleared because the Acknowledgment (ACK) control bit was not set.

yes

TCP Urgent Pointer Normalizations

enable Normalize Urgent Pointer

the number of packets for which the two-byte TCP header Urgent Pointer field was greater than the payload length and was set to the payload length.

yes

Total Blocked Packets

configure Inline Mode or Drop when Inline

the total number of dropped packets, including rule, decoder, and preprocessor drops.

no

Total Injected Packets

configure Inline Mode

the number of packets that were resized before being retransmitted.

no

Total TCP Filtered Packets

configure TCP Stream Preprocessing

the number of packets skipped by the stream because of TCP port filtering.

no

Total UDP Filtered Packets

configure UDP Stream Preprocessing

the number of packets skipped by the stream because of UDP port filtering.

no

Urgent Flag Cleared Normalizations

enable Clear URG if Urgent Pointer is Not Set

the number of packets for which the TCP header URG control bit was cleared because the urgent pointer was not set.

yes

Urgent Pointer and Urgent Flag Cleared Normalizations

enable Clear Urgent Pointer/URG on Empty Payload

the number of packets for which the TCP header Urgent Pointer field and the URG control bit have been cleared because there was no payload.

yes

Urgent Pointer Cleared Normalizations

enable Clear Urgent Pointer if URG=0

the number of packets for which the 16-bit TCP header Urgent Pointer field was cleared because the urgent (URG) control bit was not set.

yes

To generate intrusion event performance graphs:

Access: Admin/Maint

Step 1 Select Overview > Summary > Intrusion Event Performance.

The Intrusion Event Performance page appears.

Step 2 From the Select Device list, select the devices whose data you want to view.

Step 3 From the Select Graph(s) list, select the type of graph you want to create.

Step 4 From the Select Time Range list, select the time range you would like to use for the graph.

You can choose from last hour, last day, last week, or last month.

Step 5 Click Graph.

The graph appears, displaying the information you specified.

Step 6 To save the graph, right-click it and follow the instructions for your browser to save the image.

Viewing Intrusion Event Graphs

License: Protection

The FireSIGHT System provides graphs that show you intrusion event trends over time. You can generate intrusion event graphs over time ranging from the last hour to the last month, for the following:

- one or all managed devices

- top 10 destination ports

- top 10 source IP addresses

- top 10 event messages

To generate an event graph:

Access: Admin/Intrusion Admin

Step 1 Select Overview > Summary > Intrusion Event Graphs.

The Intrusion Event Graphs page appears. Three selection boxes at the top of the page control which graph is generated.

Step 2 Under Select Device, select all to include all devices, or select the specific device you want to include in the graph.

Step 3 Under Select Graph(s), select the type of graph you want to generate.

Step 4 Under Select Time Range, select the time range for the graph.

Step 5 Click Graph.

The graph is generated.

Viewing Intrusion Events

License: Protection

When the system recognizes a packet that is potentially malicious, it generates an intrusion event and adds the event to the database.

The initial intrusion events view differs depending on the workflow you use to access the page. You can use one of the predefined workflows, which includes one or more drill-down pages, a table view of intrusion events, and a terminating packet view, or you can create your own workflow. You can also view workflows based on custom tables, which may include intrusion events. Note that an event view may be slow to display if it contains a large number of IP addresses and you have enabled the Resolve IP Addresses event view setting. See Configuring Event View Settings for more information.

You view an intrusion event to determine whether there is a threat to your network security. If you are confident that an intrusion event is not malicious, you can mark the event reviewed. Your name appears as the reviewer, and the reviewed event is no longer listed in the default intrusion events view. You can return a reviewed event to the default intrusion events view by marking the event unreviewed.

You can view intrusion events that you have marked reviewed. Reviewed events are stored in the event database and are included in the event summary statistics, but no longer appear in the default event pages. See Reviewing Intrusion Events for more information.

If you perform a backup and then delete reviewed intrusion events, restoring your backup restores the deleted intrusion events but does not restore their reviewed status. You view those restored intrusion events under Intrusion Events, not under Reviewed Events.

To quickly view connection events associated with one or more intrusion events, select the intrusion events using the check boxes in the event viewer, then select Connections from the Jump to drop-down list. This is most useful when navigating between table views of events. You can also view the intrusions associated with particular connections in a similar way.

For more information, see the following sections:

- Understanding Intrusion Events

- Creating Custom Workflows

- Using Drill-Down and Table View Pages

- Using the Packet View

- Viewing Connection Data Associated with Intrusion Events

- Reviewing Intrusion Events

- Viewing a Workflow Based on a Custom Table

To view intrusion events:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Events.

The first page of the default intrusion events workflow appears. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of intrusion events, select any of the predefined workflows that ship with the appliance by clicking (switch workflow) next to the workflow title.

See Understanding Intrusion Events to learn more about the events that appear in intrusion event views. See Understanding Workflow Pages for Intrusion Events to learn more about how to narrow your view to the intrusion events that are important to your analysis.

Understanding Intrusion Events

License: Protection

The system examines the packets that traverse your network for malicious activity that could affect the availability, integrity, and confidentiality of a host and its data. When the system identifies a possible intrusion, it generates an intrusion event, which is a record of the date, time, the type of exploit, and contextual information about the source of the attack and its target. For packet-based events, a copy of the packet or packets that triggered the event is also recorded. Note that the information available for any individual intrusion event depends on several factors, including licenses. For more information, see Service Subscriptions.

.

Time

The date and time of the event.

Priority

The event priority as determined by the Cisco VRT.

Impact

The impact level in this field indicates the correlation between intrusion data, network discovery data, and vulnerability information. For more information, see Using Impact Levels to Evaluate Events.

Note that because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign Vulnerable (impact level 1: red) impact levels for intrusion events involving those hosts, unless you use the host input feature to manually set the host operating system identity.

Inline Result

One of the following:

- a black down arrow, indicating that the system dropped the packet that triggered the rule

- a gray down arrow, indicating that IPS would have dropped the packet if you enabled the Drop when Inline intrusion policy option (in an inline deployment), or if a Drop and Generate rule generated the event while the system was pruning

- blank, indicating that the triggered rule was not set to Drop and Generate Events

Note that the system does not drop packets in a passive deployment, including when an inline interface is in tap mode, regardless of the rule state or the inline drop behavior of the intrusion policy.

Source IP

The IP address used by the sending host.

Source Country

The country of the sending host.

Destination IP

The IP address used by the receiving host.

Destination Country

The country of the receiving host.

Original Client IP

The original client IP address that was extracted from an X-Forwarded-For (XFF), True-Client-IP, or custom-defined HTTP header. To display a value for this field, you must enable the HTTP preprocessor Extract Original Client IP Address option in the network analysis policy. Optionally, in the same area of the network analysis policy, you can also specify up to six custom client IP headers, as well as set the priority order in which the system selects the value for the Original Client IP event field. See Selecting Server-Level HTTP Normalization Options for more information.

This field is enabled by default.

Source Port / ICMP Type

The port number on the sending host. For ICMP traffic, where there is no port number, the system displays the ICMP type.

Destination Port / ICMP Code

The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, the system displays the ICMP code.

SSL Status

The action associated with the SSL rule, default action, or undecryptable traffic action that logged the encrypted connection:

– Block and Block with reset represent blocked encrypted connections.

– Decrypt (Resign) represents an outgoing connection decrypted using a re-signed server certificate.

– Decrypt (Replace Key) represents an outgoing connection decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Known Key) represents an incoming connection decrypted using a known private key.

– Do not Decrypt represents a connection the system did not decrypt.

If the system fails to decrypt an encrypted connection, it displays the undecryptable traffic action taken, as well as the failure reason. For example, if the system detects traffic encrypted with an unknown cipher suite and allowed it without further inspection, this field displays Do Not Decrypt (Unknown Cipher Suite).

) to view certificate details. For more information, see Viewing the Certificate Associated with an Encrypted Connection.

VLAN ID

The innermost VLAN ID associated with the packet that triggered the intrusion event.

MPLS Label

The Multiprotocol Label Switching label associated with the packet that triggered this intrusion event.

This field is disabled by default.

Message

The explanatory text for the event. For rule-based intrusion events, the event message is pulled from the rule. For decoder- and preprocessor-based events, the event message is hard coded.

Classification

The classification where the rule that generated the event belongs. See the Rule Classifications table for a list of rule classification names and numbers.

Generator

The component that generated the event. See Table 41-7 for a list of intrusion event generator IDs.

Source User

The User ID for any known user logged in to the source host.

Destination User

The User ID for any known user logged in to the destination host.

Application Protocol

The application protocol, if available, which represents communications between hosts, detected in the traffic that triggered the intrusion event. For information on how the system identifies detected application protocols in the Defense Center web interface, see Table 45-3 .

Client

The client application, if available, which represents software running on the monitored host detected in the traffic that triggered the intrusion event.

Web Application

The web application, which represents the content or requested URL for HTTP traffic detected in the traffic that triggered the intrusion event.

Note that if the system detects an application protocol of HTTP but cannot detect a specific web application, the system supplies a generic web browsing designation here.

IOC

Whether the traffic that triggered the intrusion event also triggered an indication of compromise (IOC) for a host involved in the connection. For more information on IOC, see Understanding Indications of Compromise.

Category, Tag (Application Protocol, Client, Web Application)

Criteria that characterize an application to help you understand the application's function; see Table 45-2.

Application Risk

The risk associated with detected applications in the traffic that triggered the intrusion event. Each type of application detected in a connection has an associated risk; this field displays the highest risk of those. For more information, see Table 45-2.

Business Relevance

The business relevance associated with detected applications in the traffic that triggered the intrusion event. Each type of application detected in a connection has an associated business relevance; this field displays the lowest (least relevant) of those. For more information, see Table 45-2.

Ingress Security Zone

The ingress security zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment. See Working with Security Zones.

Egress Security Zone

For an inline deployment, the egress security zone of the packet that triggered the event. This security zone field is not populated in a passive deployment. See Working with Security Zones.

Device

The managed device where the access control policy was applied. See Managing Devices.

Security Context

The metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

Ingress Interface

The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. See Configuring Sensing Interfaces.

Egress Interface

For an inline set, the egress interface of the packet that triggered the event. This interface column is not populated for a passive interface. See Configuring Sensing Interfaces.

Intrusion Policy

The intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event was enabled. You can select an intrusion policy as the default action for an access control policy, or you can associate an intrusion policy with an access control rule. See Setting Default Handling and Inspection for Network Traffic and Configuring an Access Control Rule to Perform Intrusion Prevention.

Access Control Policy

The access control policy that includes the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled; see Managing Access Control Policies.

Access Control Rule

The access control rule that invoked the intrusion policy that generated the event; see Configuring an Access Control Rule to Perform Intrusion Prevention. Default Action indicates that the intrusion policy where the rule is enabled is not associated with a specific access control rule but, instead, is configured as the default action of the access control policy; see Setting Default Handling and Inspection for Network Traffic.

This field is blank if intrusion inspection was associated with neither an access control rule nor the default action, for example, if the packet was examined by the default intrusion policy. For more information, see Setting the Default Intrusion Policy for Access Control.

Network Analysis Policy

The network analysis policy (NAP), if any, associated with the generation of the event; see Getting Started with Network Analysis Policies.

HTTP Hostname

The host name, if present, that was extracted from the HTTP request Host header. Note that request packets do not always include the host name.

To display host names, you must enable the HTTP Inspect preprocessor Log Hostname option. See Selecting Server-Level HTTP Normalization Options for more information.

This column displays the first fifty characters of the extracted host name. You can hover your pointer over the displayed portion of an abbreviated host name to display the complete name, up to 256 bytes. You can also display the complete host name, up to 256 bytes, in the packet view. See Viewing Event Information for more information.

This field is disabled by default.

HTTP URI

The raw URI, if present, associated with the HTTP request packet that triggered the intrusion event. Note that request packets do not always include a URI.

To display the extracted URI, you must enable the HTTP Inspect preprocessor Log URI option. See Selecting Server-Level HTTP Normalization Options for more information.

To see the associated HTTP URI in intrusion events triggered by HTTP responses, you should configure HTTP server ports in the Perform Stream Reassembly on Both Ports option; note, however, that this increases resource demands for traffic reassembly. See Selecting Stream Reassembly Options.

This column displays the first fifty characters of the extracted URI. You can hover your pointer over the displayed portion of an abbreviated URI to display the complete URI, up to 2048 bytes. You can also display the complete URI, up to 2048 bytes, in the packet view. See Viewing Event Information for more information.

This field is disabled by default.

Email Sender

The address of the email sender that was extracted from the SMTP MAIL FROM command. To display a value for this field, you must enable the SMTP preprocessor Log From Address option. Multiple sender addresses are supported. See Understanding SMTP Decoding for more information.

This field is disabled by default.

Email Recipient

The address of the email recipient that was extracted from the SMTP RCPT TO command. To display a value for this field, you must enable the SMTP preprocessor Log To Addresses option. Multiple recipient addresses are supported. See Understanding SMTP Decoding for more information.

This field is disabled by default.

Email Attachments

The MIME attachment file name that was extracted from the MIME Content-Disposition header. To display attachment file names, you must enable the SMTP preprocessor Log MIME Attachment Names option. Multiple attachment file names are supported. See Understanding SMTP Decoding for more information.

This field is disabled by default.

Reviewed By

The name of the user who reviewed the event. See Reviewing Intrusion Events.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Viewing Connection Data Associated with Intrusion Events

License: Protection

The system can log the connections where intrusion events are detected. Although this logging is automatic for intrusion policies associated with access control rules, you must manually enable connection logging to see associated connection data for the default action; see Logging Connections Based on Access Control Handling.

Note The information available for any individual connection or Security Intelligence event depends on several factors, including licenses and appliance model. For more information, see License and Model Requirements for Connection Logging.

To view connection data associated with one or more intrusion events:

Access: Admin

Step 1 Select Analysis > Intrusions > Events.

The first page of the default intrusion events workflow appears.

Viewing associated data is most useful when navigating between table views of events. See Understanding Workflow Pages for Intrusion Events to learn more about how to narrow your view to the intrusion events that are important to your analysis.

Step 2 Select the intrusion events using the check boxes in the event viewer, then select Connections from the Jump to drop-down list.

You can view the intrusion events associated with particular connections in a similar way. For more information, see Navigating Between Workflows.

When you view associated events, the Defense Center uses your default connection data workflow. For more information on connection data, see Working with Connection & Security Intelligence Data.

Tip If you are using a custom workflow that does not include the table view of intrusion events, select any of the predefined workflows that ship with the appliance by clicking (switch workflow) next to the workflow title.

Reviewing Intrusion Events

License: Protection

If you have examined an intrusion event and are confident that the event does not represent a threat to your network security (perhaps because you know that none of the hosts on your network are vulnerable to the detected exploit), you can mark the event reviewed. Your name appears as the reviewer, and the reviewed event is no longer listed in the default intrusion events view. Events that you mark reviewed remain in the event database, but no longer appear in intrusion event views.

To mark an intrusion event reviewed:

Access: Admin/Intrusion Admin

Step 1 On a page that displays intrusion events, you have two options:

- To mark one or more intrusion events from the list of events, select the check boxes next to the events and click Review .

- To mark all intrusion events from the list of events, click Review All .

A success message appears and the list of reviewed events is updated.

See Understanding Intrusion Events to learn more about the events that appear in intrusion event views. See Understanding Workflow Pages for Intrusion Events to learn more about how to narrow your view to the intrusion events that are important to your analysis.

Note Although they do not appear on intrusion event-related workflow pages, reviewed events are included in the event summary statistics.

To view events previously marked reviewed:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Reviewed Events.

The first page of the default reviewed intrusion events workflow appears. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of intrusion events, select any of the predefined workflows that ship with the appliance by clicking (switch workflow) next to the workflow title.

See Understanding Intrusion Events to learn more about the events that appear in reviewed intrusion event views. See Understanding Workflow Pages for Intrusion Events to learn more about how to narrow your view to the intrusion events that are important to your analysis.

To mark reviewed events unreviewed:

Access: Admin/Intrusion Admin

Step 1 On a page that displays reviewed events, you have two options:

- To remove individual intrusion events from the list of reviewed events, select the check boxes next to the events and click Unreview .

- To remove all intrusion events from the list of reviewed events, click Unreview All .

A success message appears and the list of reviewed events is updated.

Understanding Workflow Pages for Intrusion Events

License: Protection

The preprocessor, decoder, and intrusion rules that are enabled in the current intrusion policy generate intrusion events whenever the traffic that you monitor violates the policy.

The FireSIGHT System provides a set of predefined workflows, populated with event data, that you can use to view and analyze intrusion events. Each of these workflows steps you through a series of pages to help you pinpoint the intrusion events that you want to evaluate.

The predefined intrusion event workflows contain three different types of pages, or event views:

- one or more drill-down pages

- the table view of intrusion events

- a packet view

Drill-down pages generally include two or more columns in a table (and, for some drill-down views, more than one table) that allow you to view one specific type of information.

When you “drill down” to find more information for one or more destination ports, you automatically select those events and the next page in the workflow appears. In this way, drill-down tables help you reduce the number of events you are analyzing at one time.

The initial table view of intrusion events lists each intrusion event in its own row. The columns in the table list information such as the time, the source IP address and port, the destination IP address and port, the event priority, the event message, and more.

When you select events on a table view, instead of selecting events and displaying the next page in the workflow, you add to what are called constraints. Constraints are limits that you impose on the types of events that you want to analyze.

column.

If you select one or more rows in a table view and then click View, the packet view appears. A packet view provides information about the packet that triggered the rule or the preprocessor that generated the event. Each section of the packet view contains information about a specific layer in the packet. You can expand collapsed sections to see more information.

Note Because each portscan event is triggered by multiple packets, portscan events use a special version of the packet view. See Detecting Portscans for more information.

If the predefined workflows do not meet your specific needs, you can create custom workflows that display only the information you are interested in. Custom intrusion event workflows can include drill-down pages, a table view of events, or both; the system automatically includes a packet view as the last page. You can easily switch between the predefined workflows and your own custom workflows depending on how you want to investigate events.

Tip Understanding and Using Workflows explains how to use workflows and the features common to all workflow pages. This chapter also explains how to create and use custom intrusion event workflows.

For more information, see:

- Using Drill-Down and Table View Pages, which explains how to use drill-down pages and the table view of events, which share many common features.

- Using the Packet View, which explains how to use the features in the packet view.

- Searching for Intrusion Events explains how to search the event database for specific intrusion events.

Using Drill-Down and Table View Pages

License: Protection

The workflows that you can use to investigate intrusion events take advantage of three different types of pages:

- drill-down pages

- the table view of intrusion events

- the packet view

Each of these pages is described in Understanding Workflow Pages for Intrusion Events.

Table 41-2 Intrusion Event Common Features

To...

You can...

learn more about the columns that appear

find more information in Understanding Intrusion Events.

view a host’s profile

) that appears next to the host IP address.

view geolocation details

click the flag icon that appears in the Source Country or Destination Country columns.

modify the time and date range for displayed events

find more information in Setting Event Time Constraints.

Note that events generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

sort and constrain events on the current workflow page

find more information in:

- Sorting Drill-Down Workflow Pages

- the Constraining Events on Drill-Down Pages table

- the Constraining Events on the Table View of Events table

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

Tip To avoid displaying the same intrusion events on different workflow pages, the time range pauses when you click a link at the bottom of the page to display another page of events, and resumes when you click to take any other action on the subsequent page. For more information, see Setting Event Time Constraints.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

add events to the clipboard so you can transfer them to an incident at a later time

use one of the following methods:

- To copy several intrusion events on a workflow page to the clipboard, select the check boxes next to events you want to copy, then click Copy .

- To copy all the intrusion events in the current constrained view to the clipboard, click Copy All .

The clipboard stores up to 25,000 events per user. For more information, see Using the Clipboard.

delete events from the event database

use one of the following methods:

- To delete selected intrusion events, select the check boxes next to events you want to delete, then click Delete .

- To delete all the intrusion events in the current constrained view, click Delete All , then confirm you want to delete all the events.

mark events reviewed to remove them from intrusion event pages, but not the event database

use one of the following methods:

- To review selected intrusion events, select the check boxes next to events you want to review, then click Review .

- To review all the intrusion events in the current constrained view, click Review All .

For more information, see Reviewing Intrusion Events.

download a local copy of the packet (a packet capture file in libpcap format) that triggered each selected event

use one of the following methods:

- To download the packets that triggered the selected intrusion events, select the check boxes next to events triggered by the packets you want to download, then click Download Packets .

- To download all packets that triggered the intrusion events in the current constrained view, click Download All Packets .

Captured packets are saved in libpcap format. This format is used by several popular protocol analyzers.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

temporarily use a different workflow

click (switch workflow). For more information, see Selecting Workflows.

bookmark the current page so that you can quickly return to it

click Bookmark This Page. For more information, see Using Bookmarks.

view the Intrusion Events section of the Summary Dashboard

click Dashboards. For more information, see Working with Dashboards.

navigate to the bookmark management page

click View Bookmarks. For more information, see Using Bookmarks.

generate a report based on the data in the current view

click Report Designer. For more information, see Creating a Report Template from an Event View.

The number of intrusion events that appear on the event views may be quite large, depending on:

- the time range you select

- the amount of traffic on your network

- the intrusion policy you apply

To make it easier to analyze intrusion events, you can constrain the event pages. The constraining processes are slightly different for drill-down views and the table view of intrusion events.

Tip The time range pauses when you click one of the links at the bottom of the intrusion event workflow page to navigate to another page, and resumes when you click to take any other action on the subsequent page, including exiting the workflow; this reduces the likelihood of displaying the same events as you navigate to other pages in the workflow to see more events. For more information, see Setting Event Time Constraints and Navigating to Other Pages in the Workflow.

Table 41-3 Constraining Events on Drill-Down Pages

To...

You can...

drill down to the next workflow page constraining on a specific value

click the value.

For example, on the Destination Port workflow, to constrain the events to those with a destination of port 80, click 80/tcp in the DST Port/ICMP Code column. The next page of the workflow, Events, appears and contains only port 80/tcp events.

drill down to the next workflow page constraining on selected events

select the check boxes next to the events you want to view on the next workflow page, then click View.

For example, on the Destination Port workflow, to constrain the events to those with destination ports 20/tcp and 21/tcp, select the check boxes next to the rows for those ports and click View. The next page of the workflow, Events, appears and contains only port 20/tcp and 21/tcp events.

Note If you constrain on multiple rows and the table has more than one column (not including a Count column), you build what is called a compound constraint. Compound constraints ensure that you do not include more events in your constraint than you mean to. For example, if you use the Event and Destination workflow, each row that you select on the first drill-down page creates a compound constraint. If you pick event 1:100 with a destination IP address of 10.10.10.100 and you also pick event 1:200 with a destination IP address of 192.168.10.100, the compound constraint ensures that you do not also select events with 1:100 as the event type and 192.168.10.100 as the destination IP address or events with 1:200 as the event type and 10.10.10.100 as the destination IP address.

drill down to the next workflow page keeping the current constraints

click View All.

Table 41-4 Constraining Events on the Table View of Events

To...

You can...

constrain the view to events with a single attribute

click the attribute.

For example, to constrain the view to events with a destination of port 80, click 80/tcp in the DST Port/ICMP Code column.

remove a column from the table

. .

view the packets associated with one or more events

either:

- click the down arrow icon (

) next to the event whose packets you want to view.

- select one or more events whose packets you want to view, and, at the bottom of the page, click View.

- at the bottom of the page, click View All to view the packets for all events that match the current constraints.

Tip At any point in the process, you can save the constraints as a set of search criteria. For example, if you find that over the course of a few days your network is being probed by an attacker from a single IP address, you can save your constraints during your investigation and then use them again later. You cannot, however, save compound constraints as a set of search criteria. For more information, see Performing and Saving Searches.

Tip If no intrusion events appear on the event views, adjusting the selected time range might return results. If you selected an older time range, events in that time range might have been deleted. Adjusting the rule thresholding configuration might generate events.

Using the Packet View

License: Protection

A packet view provides information about the packet that triggered the rule that generated an intrusion event.

Tip The packet view on a Defense Center does not contain packet information when the Transfer Packet option is disabled for the device detecting the event.

The packet view indicates why a specific packet was captured by providing information about the intrusion event that the packet triggered, including the event’s time stamp, message, classification, priority, and, if the event was generated by a standard text rule, the rule that generated the event. The packet view also provides general information about the packet, such as its size.

In addition, the packet view has a section that describes each layer in the packet: data link, network, and transport, as well as a section that describes the bytes that comprise the packet. If the system decrypted the packet, you can view the decrypted bytes. You can expand collapsed sections to display detailed information.

Note Because each portscan event is triggered by multiple packets, portscan events use a special version of the packet view. See Detecting Portscans for more information.

Table 41-5 Packet View Actions

To...

You can...

modify the date and time range in the packet views

find more information in Setting Event Time Constraints.

learn more about the information displayed in the packet view

find more information in:

- Viewing Event Information

- Viewing Frame Information

- Viewing Data Link Layer Information

- Viewing Network Layer Information

- Viewing Transport Layer Information

- Viewing Packet Byte Information

add an event to the clipboard so you can transfer it to the incidents at a later time

either:

- click Copy to copy the event whose packet you are viewing

- click Copy All to copy all the events whose packets you previously selected

The clipboard stores up to 25,000 events per user. For more information on the clipboard, see Using the Clipboard.

delete an event from the event database

either:

- click Delete to delete the event whose packet you are viewing

- click Delete All to delete all the events whose packets you previously selected

mark an event reviewed to remove it from event views, but not the event database.

either:

- click Review to review the event whose packet you are viewing

- click Review All to review all the events whose packets you previously selected

For more information, see Reviewing Intrusion Events. Note that reviewed events continue to be included in the event statistics on the Intrusion Event Statistics page.

download a local copy of the packet (a packet capture file in libpcap format) that triggered the event

either:

- click Download Packet to save a copy of the captured packet for the event you are viewing

- click Download All Packets to save copies of the captured packets for all the events whose packets you previously selected

The captured packet is saved in libpcap format. This format is used by several popular protocol analyzers.

Note that you cannot download a portscan packet because single portscan events are based on multiple packets; however, the portscan view provides all usable packet information. See Understanding Portscan Events for more information.

Note that you must have at least 15% available disk space in order to download.

expand or collapse a page section

click the arrow next to the section.

To display the packet view:

Access: Admin/Intrusion Admin

Step 1 On the table view of intrusion events, select packets to view. See the Constraining Events on the Table View of Events table for more information.

The packet view appears. If you selected more than one event, you can page through the packets by using the page numbers at the bottom of the page.

Viewing Event Information

License: Protection

On the packet view, you can view information about the packet in the Event Information section.

Event

The event message. For rule-based events, this corresponds to the rule message. For other events, this is determined by the decoder or preprocessor.

The ID for the event is appended to the message in the format (GID:SID:Rev). GID is the generator ID of the rules engine, the decoder, or the preprocessor that generated the event. SID is the identifier for the rule, decoder message, or preprocessor message. Rev is the revision number of the rule. For more information, refer to Reading Preprocessor Generator IDs.

Timestamp

The time that the packet was captured.

Classification

The event classification. For rule-based events, this corresponds to the rule classification. For other events, this is determined by the decoder or preprocessor.

Priority

The event priority. For rule-based events, this corresponds to either the value of the priority keyword or the value for the classtype keyword. For other events, this is determined by the decoder or preprocessor.

Ingress Security Zone

The ingress security zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment. See Working with Security Zones.

Egress Security Zone

For an inline deployment, the egress security zone of the packet that triggered the event. See Working with Security Zones.

Device

The managed device where the access control policy was applied. See Managing Devices.

Security Context

The metadata identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

Ingress Interface

The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. See Configuring Sensing Interfaces.

Egress Interface

For an inline set, the egress interface of the packet that triggered the event. See Configuring Sensing Interfaces.

Source/Destination IP

The host IP address or domain name where the packet that triggered the event (source) originated, or the target (destination) host of the traffic that triggered the event.

Note that to display the domain name, you must enable IP address resolution; for more information, see Configuring Event View Settings.

Click the address or domain name to view the context menu, then select Whois to do a whois search on the host, View Host Profile to view host information, or Blacklist Now or Whitelist Now to add the address to a global blacklist or whitelist. See Using Host Profiles and Working with the Global Whitelist and Blacklist.

Source Port/ICMP Type

Source port of the packet that triggered the event. For ICMP traffic, where there is no port number, the system displays the ICMP type.

Destination Port/ICMP Code

The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, the system displays the ICMP code.

Email Headers

The data that was extracted from the email header. Note that email headers do not appear in the table view of intrusion events, but you can use email header data as a search criterion.

To associate email headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option. See Understanding SMTP Decoding for more information. For rule-based events, this row appears when email data is extracted.

HTTP Hostname

) to display the complete host name when longer than a single row.

To display host names, you must enable the HTTP Inspect preprocessor Log Hostname option. See Selecting Server-Level HTTP Normalization Options for more information.

Note that HTTP request packets do not always include a host name. For rule-based events, this row appears when the packet contains the HTTP host name or the HTTP URI.

HTTP URI

) to display the complete URI when it is longer than a single row.

To display the URI, you must enable the HTTP Inspect preprocessor Log URI option. See Selecting Server-Level HTTP Normalization Options for more information.

Note that HTTP request packets do not always include a URI. For rule-based events, this row appears when the packet contains the HTTP host name or the HTTP URI.

To see the associated HTTP URI in intrusion events triggered by HTTP responses, you should configure HTTP server ports in the Perform Stream Reassembly on Both Ports option; note, however, that this increases resource demands for traffic reassembly. See Selecting Stream Reassembly Options.

Intrusion Policy

The intrusion policy, if present, where the intrusion, preprocessor, or decoder rule that generated the intrusion event was enabled. You can select an intrusion policy as the default action for an access control policy or associate an intrusion policy with an access control rule. See Setting Default Handling and Inspection for Network Traffic and Configuring an Access Control Rule to Perform Intrusion Prevention.

Access Control Policy

The access control policy that includes the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled. See Managing Access Control Policies.

Access Control Rule

The access control rule associated with an intrusion rule that generated the event; see Configuring an Access Control Rule to Perform Intrusion Prevention. Default Action indicates that the intrusion policy where the rule is enabled is not associated with an access control rule but, instead, is configured as the default action of the access control policy; see Setting Default Handling and Inspection for Network Traffic.

Rule

For standard text rule events, the rule that generated the event.

Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available.

Because rule data may contain sensitive information about your network, administrators may toggle users’ ability to view rule information in the packet view with the View Local Rules permission in the user role editor. For more information, see Modifying User Privileges and Options.

Actions

For standard text rule events, expand Actions to take any of the following actions on the rule that triggered the event:

– edit the rule

– view documentation for the revision of the rule

– add a comment to the rule

– change the state of the rule

– set a threshold for the rule

– suppress the rule

See Using Packet View Actions, Setting Threshold Options within the Packet View, and Setting Suppression Options within the Packet View for more information.

Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available.

Using Packet View Actions

License: Protection

On the packet view, you can take several actions in the Event Information section on the rule that triggered the event. Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available. You must expand Actions to display rule actions.

Edit

For standard text rule events, click Edit to modify the rule that generated the event.

Note that if the event is based on a shared object rule, a decoder, or a preprocessor, the rule is not available.

Note If you edit a rule provided by Cisco (as opposed to a custom standard text rule), you actually create a new local rule. Make sure you set the local rule to generate events and also disable the original rule in the current intrusion policy. Note, however, that you cannot enable local rules in the default policies. For more information, see Modifying Existing Rules.

View Documentation

For standard text rule events, click View Documentation to learn more about the rule revision that generated the event.

Rule Comment

For standard text rule events, click Rule Comment to add a text comment to the rule that generated the event.

This allows you to provide additional context and information about the rule and the exploit or policy violation it identifies. You can also add and view rule comments in the rule editor. For more information, see Adding Comments to Rules.

Disable this rule

If this event is generated by a standard text rule, you can disable the rule, if necessary. You can set the rule in all policies that you can edit locally. Alternately, you can set the rule only in the current policy (that is, the policy that generated the event) if you can edit the current policy locally.

For more information, see Setting Rule States.

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco.

Note You cannot disable shared object rules from the packet view, nor can you disable rules in the default policies.

Set this rule to generate events

If this event is generated by a standard text rule, you can set the rule to generate events in all policies that you can edit locally. Alternately, you can set the rule only in the current policy (that is, the policy that generated the event) if you can edit the current policy locally.

For more information, see Setting Rule States.

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco.

Note You cannot set shared object rules to generate events from e packet view, nor can you disable rules in the default policies.

Set this rule to drop

If your managed device is deployed inline on your network, you can set the rule that triggered the event to drop packets that trigger the rule in all policies that you can edit locally. Alternately, you can set the rule only in the current policy (that is, the policy that generated the event) if you can edit the current policy locally.

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco. Note also that this option appears only when Drop when Inline is enabled in the current policy. See Setting Drop Behavior in an Inline Deployment for more information.

Set Thresholding Options

You can use this option to create a threshold for the rule that triggered this even in all policies that you can edit locally. Alternately, you create a threshold only for the current policy (that is, the policy that generated the event) if you can edit the current policy locally.

The thresholding options are described in Setting Threshold Options within the Packet View.

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default intrusion policy provided by Cisco.

Set Suppression Options

You can use this object to suppress the rule that triggered this event in all policies that you can edit locally. Alternately, you can suppress the rule only in the current policy (that is, the policy that generated the event) if you can edit the current policy locally.

The suppression options are described in Setting Suppression Options within the Packet View.

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco.

Setting Threshold Options within the Packet View

License: Protection

You can control the number of events that are generated per rule over time by setting the threshold options in the packet view of an intrusion event. You can set threshold options in all policies that you can edit locally or, when it can be edited locally, only in the in the current policy (that is, the policy that caused the event to be generated).

To set the threshold options within the packet view:

Access: Admin/Intrusion Admin

Step 1 Within the packet view of an intrusion event that was generated by an intrusion rule, expand Actions in the Event Information section; expand Set Thresholding Options and select one of the two possible options:

- in the current policy

- in all locally created policies

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco.

The thresholding options appear.

Step 2 Select the type of threshold you want to set:

- Select limit to limit notification to the specified number of event instances per time period.

- Select threshold to provide notification for each specified number of event instances per time period.

- Select both to provide notification once per time period after a specified number of event instances.

Step 3 Select the appropriate radio button to indicate whether you want the event instances tracked by Source or Destination IP address.

Step 4 In the Count field, type the number of event instances you want to use as your threshold.

Step 5 In the Seconds field, type a number between 1 and 86400 that specifies the time period for which event instances are tracked.

Step 6 If you want to override any current thresholds for this rule in existing intrusion policies, select Override any existing settings for this rule.

Step 7 Click Save Thresholding.

The system adds your threshold and displays a message indicating success. If you chose not to override existing settings, a message appears informing you of any conflicts.

Setting Suppression Options within the Packet View

License: Protection

You can use the suppression options to suppress intrusion events altogether, or based on the source or destination IP address. You can set suppression options in all policies that you can edit locally. Alternately, you can set suppression options only in the current policy (that is, the policy that generated the event) when the current policy can be edited locally.

To suppress intrusion events within the packet view:

Access: Admin/Intrusion Admin

Step 1 Within the packet view of an intrusion event that was generated by an intrusion rule, expand Actions in the Event Information section; expand Set Suppression Options and click one of the two possible options:

- in the current policy

- in all locally created policies

Note that the current policy option appears only when you can edit the current policy; for example, you can edit a custom policy, but you cannot edit a default policy provided by Cisco.

The suppression options appear.

Step 2 Select one of the following Track By options:

- To completely suppress events for the rule that triggered this event, select Rule .

- To suppress events generated by packets originating from a specified source IP address, select Source .

- To suppress events generated by packets going to a specified destination IP address, select Destination .

Step 3 In the IP address or CIDR block field, enter the IP address or CIDR block/prefix length you want to specify as the source or destination IP address.

For information on using CIDR notation and prefix lengths in the FireSIGHT System, see IP Address Conventions.

Step 4 Click Save Suppression.

The suppression options within your intrusion policies are modified according to your specifications. If you chose not to override existing settings, a message appears informing you of any conflicts.

Viewing Frame Information

License: Protection

On the packet view, click the arrow next to Frame to view information about the captured frame. The packet view may display a single frame or multiple frames. Each frame provides information about an individual network packet. You would see multiple frames, for example, in the case of tagged packets or packets in reassembled TCP streams. For information on tagged packets, see Evaluating Post-Attack Traffic. For information on reassembled TCP streams, see Reassembling TCP Streams.

Frame n

The captured frame, where n is 1 for single-frame packets and the incremental frame number for multi-frame packets. The number of captured bytes in the frame is appended to the frame number.

Arrival Time

The date and time the frame was captured.

Time delta from previous captured frame

For multi-frame packets, the elapsed time since the previous frame was captured.

Time delta from previous displayed frame

For multi-frame packets, the elapsed time since the previous frame was displayed.

Time since reference or first frame

For multi-frame packets, the elapsed time since the first frame was captured.

Frame Number

The incremental frame number.

Frame Length

The length of the frame in bytes.

Capture Length

The length of the captured frame in bytes.

Frame is marked

Whether the frame is marked (true or false).

Protocols in frame

The protocols included in the frame.

Viewing Data Link Layer Information

License: Protection

On the packet view, click the arrow next to the data link layer protocol (for example, Ethernet II) to view the data link layer information about the packet, which contains the 48-bit media access control (MAC) addresses for the source and destination hosts. It may also display other information about the packet, depending on the hardware protocol.

Note Note that this example discusses Ethernet link layer information; other protocols may also appear.

The packet view reflects the protocol used at the data link layer. The following listing describes the information you might see for an Ethernet II or IEEE 802.3 Ethernet packet in the packet view.

Destination

The MAC address for the destination host.

Note Ethernet can also use multicast and broadcast addresses as the destination address.

Source

The MAC address for the source host.

Type

For Ethernet II packets, the type of packet that is encapsulated in the Ethernet frame; for example, IPv6 or ARP datagrams. Note that this item only appears for Ethernet II packets.

Length

For IEEE 802.3 Ethernet packets, the total length of the packet, in bytes, not including the checksum. Note that this item only appears for IEEE 802.3 Ethernet packets.

Viewing Network Layer Information

License: Protection

On the packet view, click the arrow next to the network layer protocol (for example, Internet Protocol) to view more detailed information about network layer information related to the packet.

Note Note that this example discusses IP packets; other protocols may also appear.

See the following sections for more information:

- Viewing IPv4 Network Layer Information

- Viewing IPv6 Network Layer Information

Viewing IPv4 Network Layer Information

License: Protection

The following listing describes protocol-specific information that might appear in an IPv4 packet.

Version

The Internet Protocol version number.

Header Length

The number of bytes in the header, including any IP options. An IP header with no options is 20 bytes long.

Differentiated Services Field

The values for differentiated services that indicate how the sending host supports Explicit Congestion Notification (ECN):

– 0x0 — does not support ECN-Capable Transport (ECT)

– 0x1 and 0x2 — supports ECT

– 0x3 — Congestion Experienced (CE)

Total Length

The length of the IP packet, in bytes, minus the IP header.

Identification

The value that uniquely identifies an IP datagram sent by the source host. This value is used to trace fragments of the same datagram.

Flags

The values that control IP fragmentation, where:

values for the Last Fragment flag indicate whether there are more fragments associated with the datagram:

– 0 — there are no more fragments associated with the datagram

– 1 — there are more fragments associated with the datagram

values for the Don’t Fragment flag control whether the datagram can be fragmented:

– 0 — the datagram can be fragmented

– 1 — the datagram must not be fragmented

Fragment Offset

The value for the fragment offset from the beginning of the datagram.

Time to Live (ttl)

The remaining number of hops that the datagram can make between routers before the datagram expires.

Protocol

The transport protocol that is encapsulated in the IP datagram; for example, ICMP, IGMP, TCP, or UDP.

Header Checksum

The indicator for whether the IP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an intrusion evasion attempt.

Source/Destination

The IP address or domain name for the source (or destination) host.

Note that to display the domain name, you must enable IP address resolution; for more information, see Configuring Event View Settings.

Click the address or domain name to view the context menu, then select Whois to do a whois search on the host, View Host Profile to view host information, or Blacklist Now or Whitelist Now to add the address to a global blacklist or whitelist. See Using Host Profiles and Working with the Global Whitelist and Blacklist.

Viewing IPv6 Network Layer Information

License: Protection

The following listing describes protocol-specific information that might appear in an IPv6 packet.

Traffic Class

An experimental 8-bit field in the IPv6 header for identifying IPv6 packet classes or priorities similar to the differentiated services functionality provided for IPv4. When unused, this field is set to zero.

Flow Label

A optional 20-bit IPv6 hexadecimal value 1 to FFFFF that identifies a special flow such as non-default quality of service or real-time service. When unused, this field is set to zero.

Payload Length

A 16-bit field identifying the number of octets in the IPv6 payload, which is comprised of all of the packet following the IPv6 header, including any extension headers.

Next Header

An 8-bit field identifying the type of header immediately following the IPv6 header, using the same values as the IPv4 Protocol field.

Hop Limit

An 8-bit decimal integer that each node that forwards the packet decrements by one. The packet is discarded if the decremented value reaches zero.

Source

The 128-bit IPv6 address for the source host.

Destination

The 128-bit IPv6 address for the destination host.

Viewing Transport Layer Information

License: Protection

On the packet view, click the arrow next to the transport layer protocol (for example, TCP, UDP, or ICMP) to view more information about the packet.

Tip Click Data when present to view the first twenty-four bytes of the payload for the protocol immediately above it in the Packet Information section of the packet view.

The contents of the transport layer for each of the following protocols is described below:

- TCP Packet View

- UDP Packet View

- ICMP Packet View

Note Note that these examples discuss TCP, UDP, and ICMP packets; other protocols may also appear.

TCP Packet View

License: Protection

This section describes the protocol-specific information for a TCP packet.

Source port

The number that identifies the originating application protocol.

Destination port

The number that identifies the receiving application protocol.

Sequence number

The value for the first byte in the current TCP segment, keyed to initial sequence number in the TCP stream.

Next sequence number

In a response packet, the sequence number of the next packet to send.

Acknowledgement number

The TCP acknowledgement, which is keyed to the sequence number of the previously accepted data.

Header Length

The number of bytes in the header.

Flags

The six bits that indicate the TCP segment’s transmission state:

– U — the urgent pointer is valid

– A — the acknowledgement number is valid

– P — the receiver should push data

– R — reset the connection

– S — synchronize sequence numbers to start a new connection

– F — the sender has finished sending data

Window size

The amount of unacknowledged data, in bytes, that the receiving host will accept.

Checksum

The indicator for whether the TCP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit or may be being used in an in evasion attempt.

Urgent Pointer

The position, if present, in the TCP segment where the urgent data ends. Used in conjunction with the U flag.

Options

The values, if present, for TCP options.

UDP Packet View

License: Protection

This section describes the protocol-specific information for a UDP packet.

Source port

The number that identifies the originating application protocol.

Destination port

The number that identifies the receiving application protocol.

Length

The combined length of the UDP header and data.

Checksum

The indicator for whether the UDP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit.

ICMP Packet View

License: Protection

This section describes the protocol-specific information for an ICMP packet.

Type

The type of ICMP message:

– 0 — echo reply

– 3 — destination unreachable

– 4 — source quench

– 5 — redirect

– 8 — echo request

– 9 — router advertisement

– 10 — router solicitation

– 11 — time exceeded

– 12 — parameter problem

– 13 — timestamp request

– 14 — timestamp reply

– 15 — information request (obsolete)

– 16 — information reply (obsolete)

– 17 — address mask request

– 18 — address mask reply

Code

The accompanying code for the ICMP message type. ICMP message types 3, 5, 11, and 12 have corresponding codes as described in RFC 792.

Checksum

The indicator for whether the ICMP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit.

Viewing Packet Byte Information

License: Protection

On the packet view, click the arrow next to Packet Bytes to view hexadecimal and ASCII versions of the bytes that comprise the packet. If the system decrypted traffic, you can view the decrypted packet bytes.

Using Impact Levels to Evaluate Events

License: Protection

To help you evaluate the impact an event has on your network, the Defense Center displays an impact level in the table view of intrusion events. For each event, the Defense Center adds an impact level icon whose color indicates the correlation between intrusion data, network discovery data, and vulnerability information.

Note Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign impact Vulnerable (impact level 1: red) impact levels for intrusion events involving those hosts, unless you use the host input feature to manually set the hosts’ operating system identity.

Table 41-6 Impact Levels

Impact Level

Vulnerability

Color

Description

Unknown

gray

Neither the source nor the destination host is on a network that is monitored by network discovery.

Vulnerable

red

Either:

- the source or the destination host is in the network map, and a vulnerability is mapped to the host

- the source or destination host is potentially compromised by a virus, trojan, or other piece of malicious software; see Setting Impact Level 1 for more information

Potentially Vulnerable

orange

Either the source or the destination host is in the network map and one of the following is true:

- for port-oriented traffic, the port is running a server application protocol

- for non-port-oriented traffic, the host uses the protocol

Currently Not Vulnerable

yellow

Either the source or the destination host is in the network map and one of the following is true:

- for port-oriented traffic (for example, TCP or UDP), the port is not open

- for non-port-oriented traffic (for example, ICMP), the host does not use the protocol

Unknown Target

blue

Either the source or destination host is on a monitored network, but there is no entry for the host in the network map.

To use the impact level on the table view to evaluate events:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Events.

The first page of the default intrusion events workflow appears. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Step 2 Constrain the event view to view only those events that you want to evaluate.

For more information, see Using Drill-Down and Table View Pages.

Step 3 At the top of the page, click Table View of Events.

The table view of events appears. Impact can have any of the values described in the Impact Levels table.

Step 4 To sort the table by impact level, click Impact.

The events are sorted by impact level.

Tip To reverse the sort order, click Impact again.

Reading Preprocessor Events

License: Protection

Preprocessors provide two functions: performing the specified action on the packet (for example, decoding and normalizing HTTP traffic) and reporting the execution of specified preprocessor options by generating an event whenever a packet triggers that preprocessor option and the associated preprocessor rule is enabled (for example, you can enable the Double Encoding HTTP Inspect option and the associated preprocessor rule with the HTTP Inspect generator (GID) 119 and the Snort ID (SID) 2 to generate an event when the preprocessor encounters IIS double-encoded traffic). Generating events to report the execution of preprocessors helps you detect anomalous protocol exploits. For example, attackers can craft overlapping IP fragments to cause a DoS attack on a host. The IP defragmentation preprocessor can detect this type of attack and generate an intrusion event for it.

See the following sections for more information:

- Understanding the Preprocessor Event Packet Display describes the information contained in a preprocessor-generated event.

- Reading Preprocessor Generator IDs details the information provided by the preprocessor generator ID.

Understanding the Preprocessor Event Packet Display

License: Protection

Preprocessor events differ from rule events in that the packet display does not include a detailed rule description for the event. Instead, the packet display shows the event message, the generator ID, Snort ID, the packet header data, and the packet payload. This allows you to analyze the packet’s header information, determine if its header options are being used and if they can exploit your system, and inspect the packet payload. After the preprocessors analyze each packet, the rules engine executes appropriate rules against it (if the preprocessor was able to defragment it and establish it as part of a valid session) to further analyze potential content-level threats and report on them.

Reading Preprocessor Generator IDs

License: Protection

Each preprocessor has its own Generator ID number, or GID, that indicates which preprocessor was triggered by the packet. Some of the preprocessors also have related SIDs, which are ID numbers that classify potential attacks. This helps you analyze events more effectively by categorizing the type of event much the way a rule’s Snort ID (SID) can offer context for packets triggering rules. You can list preprocessor rules by preprocessor in the Preprocessors filter group on the intrusion policy Rules page; you can also list preprocessor rules in the preprocessor and packet decoder sub-groupings in the Category filter group. See Tuning Intrusion Policies Using Rules and Table 32-1 for more information.

Note Events generated by standard text rules have a generator ID of 1. The event’s SID indicates which specific rule triggered. For shared object rules, the events have a generator ID of 3 and a SID that indicates which specific rule was triggered.

Table 41-7 Generator IDs

ID

Component

Description

For more information, see...

1

Standard Text Rule

The event was generated when the packet triggered a standard text rule.

Table 32-1

2

Tagged Packets

The event was generated by the Tag generator, which generates packets from a tagged session. This occurs when the tag rule option is used..

Evaluating Post-Attack Traffic

3

Shared Object Rule

The event was generated when the packet triggered a shared object rule.

Table 32-1

102

HTTP Decoder

The decoder engine decoded HTTP data within the packet.

Decoding HTTP Traffic

105

Back Orifice Detector

The Back Orifice Detector identified a Back Orifice attack associated with the packet.

Detecting Back Orifice

106

RPC Decoder

The RPC decoder decoded the packet.

Using the Sun RPC Preprocessor

116

Packet Decoder

The event was generated by the packet decoder.

Understanding Packet Decoding

119, 120

HTTP Inspect Preprocessor

The event was generated by the HTTP Inspect preprocessor. GID 120 rules relate to server-specific HTTP traffic.

Decoding HTTP Traffic

122

Portscan Detector

The event was generated by the portscan flow detector. See for more information

Detecting Portscans

123

IP Defragmentor

The event was generated when a fragmented IP datagram could not be properly reassembled.

Defragmenting IP Packets

124

SMTP Decoder

The event was generated when the SMTP preprocessor detected an exploit against an SMTP verb.

Understanding SMTP Decoding

125

FTP Decoder

The event was generated when the FTP/Telnet decoder detected an exploit within FTP traffic.

Understanding Server-Level FTP Options

Understanding Client-Level FTP Options

126

Telnet Decoder

The event was generated when the FTP/Telnet decoder detected an exploit within telnet traffic.

Decoding FTP and Telnet Traffic

128

SSH Preprocessor

The event was generated when the SSH preprocessor detected an exploit within SSH traffic.

Detecting Exploits Using the SSH Preprocessor

129

Stream Preprocessor

The event was generated during stream preprocessing by the stream preprocessor.

Using TCP Stream Preprocessing

131

DNS Preprocessor

The event was generated by the DNS preprocessor.

Detecting Exploits in DNS Name Server Responses

133

DCE/RPC Preprocessor

The event was generated by the DCE/RPC preprocessor.

Decoding DCE/RPC Traffic

134

Rule Latency

Packet Latency

The event was generated when rule latency suspended (134:1) or re-enabled (134:2) a group of intrusion rules, or when the system stopped inspecting a packet because the packet latency threshold was exceeded (134:3).

Configuring Packet and Intrusion Rule Latency Thresholds

135

Rate-Based Attack Detector

The event was generated when a rate-based attack detector identified excessive connections to hosts on the network.

Preventing Rate-Based Attacks

138, 139

Sensitive Data Preprocessor

The event was generated by the sensitive data preprocessor.

Detecting Sensitive Data

140

SIP Preprocessor

The event was generated by the SIP preprocessor.

Decoding the Session Initiation Protocol

141

IMAP Preprocessor

The event was generated by the IMAP preprocessor.

Decoding IMAP Traffic

142

POP Preprocessor

The event was generated by the POP preprocessor.

Decoding POP Traffic

143

GTP Preprocessor

The event was generated by the GTP preprocessor.

Configuring the GTP Command Channel

144

Modbus Preprocessor

The event was generated by the Modbus SCADA preprocessor.

Configuring the Modbus Preprocessor

145

DNP3 Preprocessor

The event was generated by the DNP3 SCADA preprocessor.

Configuring the DNP3 Preprocessor

Searching for Intrusion Events

License: Protection

You can search for specific intrusion events by using a predefined search delivered with the FireSIGHT System or by creating your own search criteria.

The predefined searches serve as examples and can provide quick access to important information about your network. You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. Keep in mind that your search results depend on the available data in the events you are searching. In other words, depending on the available data, your search constraints may not apply. For example, only intrusion events triggered on decrypted traffic contain SSL information.

Tip For information about the syntax for specifying IP addresses and ports in an intrusion event search, see Specifying IP Addresses in Searches and Specifying Ports in Searches.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

The search criteria you can use are described in the following list:

Priority

Specify the priority of the events you want to view. The priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor. Valid values are high, medium, and low.

Impact

Specify the impact level assigned to the intrusion event based on the correlation between intrusion data and network discovery data. Valid case-insensitive values are Impact 0, Impact Level 0, Impact 1, Impact Level 1, Impact 2, Impact Level 2, Impact 3, Impact Level 3, Impact 4, and Impact Level 4.

Do not use impact icon colors or partial strings (for example, do not use blue, level 1, or 0).

For more information, see Using Impact Levels to Evaluate Events.

Inline Result

Type either:

– dropped, to specify whether the packet is dropped in an inline deployment

– would have dropped, to specify whether the packet would have dropped if the intrusion policy had been set to drop packets in an inline deployment

Note that the system does not drop packets in a passive deployment, including when an inline interface is in tap mode, regardless of the rule state or the inline drop behavior of the intrusion policy.

Source IP

Specify the IP address used by the source host involved in the intrusion events.

Destination IP

Specify the IP address used by the destination host involved in the intrusion events.

Source/Destination IP

Specify the source or destination IP address used by the host whose intrusion events you want to view.

Source Country

Specify the country of the source host involved in the intrusion events.

Destination Country

Specify the country of the destination host involved in the intrusion events.

Source/Destination Country

Specify the country of the source or destination host involved in the intrusion events you want to view.

Source Continent

Specify the continent of the source host involved in the intrusion events.

Destination Continent

Specify the continent of the destination host involved in the intrusion events.

Source/Destination Continent

Specify the continent of the source or destination host involved in the intrusion events you want to view.

Original Client IP

Specify the original client IP address extracted from the X-Forwarded-For (XFF), True-Client-IP, or custom-defined HTTP headers. To extract a value for this field in an intrusion event, you must enable the HTTP preprocessor Extract Original Client IP Address option. Optionally, in the same area of the network analysis policy, you can also specify up to six custom client IP headers, as well as set the priority order in which the system selects the value for the Original Client IP event field. See Selecting Server-Level HTTP Normalization Options for more information.

Protocol

Type the name or number of the transport protocol used in the connection as listed in http://www.iana.org/assignments/protocol-numbers.

Note that there is no Protocol column in the intrusion event table view. This is the protocol associated with the source and destination port/ICMP column.

Source Port / ICMP Type

Specify the source port associated with the intrusion event.

Tip For ICMP traffic, which does not target ports, you can use this field to search for events with specific ICMP types.

Destination Port / ICMP Code

Specify the destination port associated with the intrusion event.

Tip For ICMP traffic, which does not target ports, you can use this field to search for events with specific ICMP codes.

VLAN ID

Specify the innermost VLAN ID associated with the packet that triggered the intrusion event.

MPLS Label

Specify the Multiprotocol Label Switching label of the packet associated with the packet that triggered the intrusion event.

Message

Specify all or part of the event message for the events you want to view.

Classification

Enter the classification number, or all or part of the classification name or description for the rule that generated the events you want to view. You can also enter a comma-separated list of numbers, names, or descriptions. Finally, if you add a custom classification, you can also search using all or part of its name or description. See the Rule Classifications table for a list of classification numbers, names, and descriptions.

Generator

Specify the component that generated the events you want to view, as listed in Table 41-7.

Snort ID

Table 41-8 Snort ID Search Values

Value

Example

a single SID

10000

a SID range

10000-11000

greater than a SID

>10000

greater than or equal to a SID

>=10000

less than a SID

<10000

less than or equal to a SID

<=10000

a comma-separated list of SIDs

10000,11000,12000

a single GID:SID combination

1:10000

a comma-separated list of GID:SID combinations

1:10000,1:11000,1:12000

a comma-separated list of SIDs and GID:SID combinations

10000,1:11000,12000

For more information, see Reading Preprocessor Generator IDs.

Note that the Snort ID column does not appear in search results; the SID of the events you are viewing is listed in the Message column.

Source User

Specify the User ID for a user logged in to the source host.

Destination User

Specify the User ID for a user logged in to the destination host.

Source/Destination User

Specify the User ID for a user logged in to the source or destination host.

Application Protocol

Type the name of the application protocol, which represents communications between hosts, detected in the traffic that triggered the intrusion event.

Client

Type the name of the client application, which represents software running on the monitored host detected in the traffic that triggered the intrusion event.

Web Application

Type the name of the web application, which represents the content or requested URL for HTTP traffic detected in the traffic that triggered the intrusion event.

Category, Tag (Application Protocol, Client, Web Application)

Type a category or tag associated with the application detected in the session. Use a commas to separate multiple categories or tags. These fields are case-insensitive.

Application Risk

Type the highest risk associated with the application detected in the session. Valid criteria are: Very High, High, Medium, Low, and Very Low. These fields are case-insensitive.

Business Relevance

Type the lowest business relevance associated with an application detected in the session. Valid criteria are: Very High, High, Medium, Low, and Very Low. These fields are case-insensitive.

Security Zone (Ingress, Egress, Ingress/Egress)

Type the name of a security zone associated with the packet that triggered the event. These fields are case-insensitive. See Working with Security Zones.

Device

Type the device name or IP address, or a device group, stack, or cluster name to restrict the search to specific devices where the access control policy was applied. For detailed information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

Note that the primary and secondary devices in a stacked configuration report intrusion events separately. See Managing Stacked Devices for more information.

Security Context

Type the name of the security context identifying the virtual firewall group through which the traffic passed. Note that the system only populates this field for ASA FirePOWER devices in multiple context mode.

Interface (Ingress, Egress)

Type the name of an interface associated with the packet that triggered the event; see Configuring Sensing Interfaces.

Intrusion Policy

Type the name of the intrusion policy associated with the event; see Managing Intrusion Policies.

Access Control Policy

Type the name of the access control policy associated with the event; see Managing Access Control Policies.

Access Control Rule

Type the name of the access control rule associated with the event; see Tuning Traffic Flow Using Access Control Rules.

HTTP Hostname

Specify a single host name that was extracted from the HTTP request Host header.

To associate host names with intrusion events for HTTP client traffic, you must enable the HTTP Inspect preprocessor Log Hostname option. See Selecting Server-Level HTTP Normalization Options for more information.

HTTP URI

Specify a single URI associated with the HTTP request packet that triggered the intrusion event.

To associate URIs with intrusion events for HTTP traffic, you must enable the HTTP Inspect preprocessor Log URI option. See Selecting Server-Level HTTP Normalization Options for more information.

Email Sender

Specify the address of the email sender that was extracted from the SMTP MAIL FROM command. You can also enter a comma-separated list to search for events associated with all specified addresses. See Understanding Intrusion Events for more information.

Email Recipient

Specify the address of the email recipient that was extracted from the SMTP RCPT TO command. You can also enter a comma-separated list to search for events associated with all specified addresses. See Understanding Intrusion Events for more information.

Email Attachments

Specify the MIME attachment file name that was extracted from the MIME Content-Disposition header. Enter a comma-separated list to search for events associated with all attachment file names in the list. See Understanding Intrusion Events for more information.

Email Headers

Specify data that was extracted from the email header. Note that email headers do not appear in the table view of intrusion events, but you can use email header data as a search criterion.

To associate email headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option. See Understanding SMTP Decoding for more information.

Reviewed By

Specify the name of the user who reviewed the event. See Reviewing Intrusion Events.

Tip You can enter unreviewed to search for events that have not been reviewed.

Special Search Syntax for Intrusion Events

To supplement the general search syntax listed above, the following list describes some special search syntax for intrusion events.

The SSL Actual Action taken

Type any of the following keywords to view intrusion events for encrypted traffic to which the system applied the action specified:

– Do Not Decrypt represents connections the system did not decrypt.

– Block and Block with Reset represent blocked encrypted connections.

– Decrypt (Known Key) represents incoming connections decrypted using a known private key.

– Decrypt (Replace Key) represents outgoing connections decrypted using a self-signed server certificate with a substituted public key.

– Decrypt (Resign) represents outgoing connections decrypted using a re-signed server certificate.

This column does not appear in the intrusion events table view.

The SSL Failure Reason

Type any of the following keywords to view intrusion events for encrypted traffic that the system failed to decrypt for the reason specified:

– Unknown

– No Match

– Success

– Uncached Session

– Unknown Cipher Suite

– Unsupported Cipher Suite

– Unsupported SSL Version

– SSL Compression Used

– Session Undecryptable in Passive Mode

– Handshake Error

– Decryption Error

– Pending Server Name Category Lookup

– Pending Common Name Category Lookup

– Internal Error

– Network Parameters Unavailable

– Invalid Server Certificate Handle

– Server Certificate Fingerprint Unavailable

– Cannot Cache Subject DN

– Cannot Cache Issuer DN

– Unknown SSL Version

– External Certificate List Unavailable

– External Certificate Fingerprint Unavailable

– Internal Certificate List Invalid

– Internal Certificate List Unavailable

– Internal Certificate Unavailable

– Internal Certificate Fingerprint Unavailable

– Server Certificate Validation Unavailable

– Server Certificate Validation Failure

– Invalid Action

This column does not appear in the intrusion events table view.

The SSL Subject Country

Type a two-character ISO 3166-1 alpha-2 country code to view intrusion events for encrypted traffic associated with the country of a certificate subject.

This column does not appear in the intrusion events table view.

The SSL Issuer Country

Type a two-character ISO 3166-1 alpha-2 country code to view intrusion events for encrypted traffic associated with the country of a certificate issuer.

This column does not appear in the intrusion events table view.

SSL Certificate Fingerprint

Type or paste the SHA hash value used to authenticate a certificate to view intrusion events for traffic associated with that certificate.

This column does not appear in the intrusion events table view.

SSL Public Key Fingerprint

Type or paste the SHA hash value used to authenticate the public key contained within a certificate to view intrusion events for traffic associated with that certificate.

This column does not appear in the intrusion events table view.

To search for intrusion events:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Search.

The Intrusion Events search page appears.

You can also click Search while viewing lists of intrusion events (Analysis > Intrusions > Events).

Step 2 Enter your search criteria in the appropriate fields, as described in the list above the procedure.

- For more information on search syntax, including using objects in searches, see Searching for Events.

- See Viewing the Certificate Associated with an Encrypted Connection for fields related to public key certificates.

- See Special Search Syntax for Intrusion Events for special search syntax for intrusion events.

Step 3 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 4 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 5 Click Search to start the search.

Your search results appear in the default intrusion events workflow, constrained by the current time range. For information on specifying a different default workflow, see Configuring Event View Settings.

Using the Clipboard

License: Protection

The clipboard is a holding area where you can copy intrusion events from any of the intrusion event views. For information on how to add events to the clipboard, see Using Drill-Down and Table View Pages and Using the Packet View.

The contents of the clipboard are sorted by the date and time that the events were generated. After you add intrusion events to the clipboard, you can delete them from the clipboard as well as generate reports on the contents of the clipboard.

You can also add intrusion events from the clipboard to incidents, which are compilations of events that you suspect are involved in a possible violation of your security policies. For more information about adding events from the clipboard to an incident, see Creating an Incident.

See the following sections for more information:

- Generating Clipboard Reports

- Deleting Events from the Clipboard

Generating Clipboard Reports

License: Protection

You can generate a report for the events on the clipboard just as you would from any of the event views.

To generate a report on intrusion events from the clipboard:

Access: Admin/Intrusion Admin

Step 1 Add one or more events to the clipboard:

- For information on how to add events to the clipboard from a drill-down page or table view of events, see Using Drill-Down and Table View Pages.

- For information on how to add events to the clipboard from the packet view, see Using the Packet View.

Step 2 Select Analysis > Intrusions > Clipboard.

The clipboard appears.

Step 3 You have the following options:

- To include specific events from a page on the clipboard, navigate to that page, select the check box next to the events, and click Generate Report .

- To include all the events from the clipboard, click Generate Report All .

In either case, the Report Templates page appears.

Step 4 Specify how you want your report to look, then click Generate.

The Generate Report pop-up dialog appears.

Step 5 Select one or more output formats (HTML, PDF, CSV) and, optionally, modify any of the other settings.

Tip For more information about using the Report Designer, see Working with Reports.

Step 6 Click Generate, then click Yes.

The Report Generation Complete pop-up window appears with a link to view your report.

Step 7 Click either:

- a report link, which opens a new window to display the report you selected.

- OK to return to the Report Templates page where you can modify your report design.

Deleting Events from the Clipboard

License: Protection

If you have intrusion events on the clipboard that you do not want to add to an incident, you can delete the events.

Note Deleting an event from the clipboard does not delete the event from the event database. However, deleting an event from the event database does delete the event from the clipboard.

To delete events from the clipboard:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Clipboard.

The clipboard appears.

Step 2 You have the following options:

- To delete specific intrusion events from a page on the clipboard, navigate to the page, select the check box next to the events, and click Delete .

The events are deleted.

- To delete all the intrusion events from the clipboard, click Delete All .

All the events are deleted from the clipboard. Note that if you select the Confirm 'All' Actions option in the Event Preferences, you are first prompted to confirm that you want to delete all the events.

Handling Incidents

Incident handling refers to the response an organization takes when a violation of its security policies is suspected. The FireSIGHT System includes features to support you as you collect and process information that is relevant to your investigation of an incident. You can use these features to gather intrusion events and packet data that may be related to the incident. You can also use the incident as a repository for notes about any activity that you take outside of the FireSIGHT System to mitigate the effects of the attack. For example, if your security policies require that you quarantine compromised hosts from your network, you can note that in the incident.

The FireSIGHT System also supports an incident life cycle, allowing you to change an incident’s status as you progress through your response to an attack. When you close an incident, you can note any changes you have made to your security policies as a result of any lessons learned.

See the following sections for more information about handling incidents in the FireSIGHT System:

- Incident Handling Basics

- Creating an Incident

- Editing an Incident

- Generating Incident Reports

- Creating Custom Incident Types

Incident Handling Basics

License: Protection

Each organization is likely to have its own process for discovering, defining, and responding to violations of its security policies. The sections that follow describe some of the basics of incident handling and how you can incorporate the FireSIGHT System in your incident response plan:

- Definition of an Incident

- Common Incident Handling Processes

- Incident Types in the FireSIGHT System

Definition of an Incident

License: Protection

Generally, an incident is defined as one or more intrusion events that you suspect are involved in a possible violation of your security policies. Cisco also uses the term to describe the feature you use in the FireSIGHT System to track your response to an incident.

As explained in Working with Intrusion Events, some intrusion events are more important than others to the availability, confidentiality, and integrity of your network assets. For example, the port scan detection features provided by the FireSIGHT System can keep you informed of port scanning activity on your network. Your security policy, however, may not specifically prohibit port scanning or see it as a high priority threat, so rather than take any direct action, you may instead want to keep logs of any port scanning for later forensic study.

On the other hand, if the system generates events that indicate hosts within your network have been compromised and are participating in distributed denial-of-service (DDoS) attacks, then this activity is likely a clear violation of your security policy, and you should create an incident in the FireSIGHT System to help you track your investigation of these events.

Common Incident Handling Processes

License: Protection

Each organization is likely to define its own process for handling security incidents. Most methodologies include some or all of the following phases:

- Preparation

- Detection and Notification

- Investigation and Qualification

- Communication

- Containment and Recovery

- Lessons Learned

Each of these phases is described in the sections that follow. The descriptions also explain how the FireSIGHT System fits into each phase.

Preparation

You can prepare for incidents in two ways:

- by having clear and comprehensive security policies in place, as well as the hardware and software resources to enforce them

- by having a clearly defined plan to respond to incidents and a properly trained team that can implement the plan

A key part of incident handling is understanding which parts of your network are at the greatest risk. By deploying FireSIGHT System components on those network segments, you can increase your awareness of when and how incidents occur. Also, by taking the time to carefully tune the intrusion policy for each managed device, you can ensure that the events that are generated are of the highest quality.

Detection and Notification

You cannot respond to an incident unless you can detect it. Your incident handling process should note the kinds of security-related events that you can detect and the mechanisms, both software and hardware, that you use to detect them. You should also note where you can detect violations of your security policies. If your network includes segments that are not actively or passively monitored, then you need to note that as well.

The managed devices that you deploy on your network are responsible for analyzing the traffic on the segments where they are installed, for detecting intrusions, and for generating events that describe them. Keep in mind that the access control policy you apply to each of the managed devices governs what kinds of activity they detect and how it is prioritized. You can also set notification options for certain types of intrusion events so that the incident team does not need to sift through hundreds of events. You can specify that you are notified automatically when certain high priority, high severity events are detected.

Investigation and Qualification

Your incident handling process should specify how, after a security incident is detected, an investigation is conducted. In some organizations, junior members of the team triage all the incidents and handle the less severe or lower priority cases themselves. High severity and high priority incidents are handled by more senior members of the team. You should carefully outline the escalation process so that each team member understands the criteria for raising an incident’s importance.

Part of the escalation process is tied to understanding how a detected event can affect the security of your network assets. For example, an attack against hosts running Microsoft SQL Server is not a high priority for organizations that use a different database server. Similarly, the attack is less important to you if you use SQL Server on your network, but you are confident that all the servers are patched and are not vulnerable to the attack. However, if someone has recently installed a copy of the vulnerable version of the software (perhaps for testing purposes), you may have a greater problem than a cursory investigation would suggest.

The FireSIGHT System is particularly well suited to supporting the investigation and qualification process. You can create your own event classifications, and then apply them in a way that best describes the vulnerabilities on your network. When traffic on your network triggers an event, that event is automatically prioritized and qualified for you with special indicators showing which attacks are directed against hosts that are known to be vulnerable.

The incident tracking feature in the FireSIGHT System also includes a status indicator that you can change to show which incidents have been escalated.

Communication

All incident handling processes should specify how an incident is communicated between the incident handling team and both internal and external audiences. For example, you should consider what kinds of incidents require management intervention and at what level. Also, your process should outline how and when you communicate with outside organizations. Will some incidents require that you notify law enforcement agencies? If your hosts are participating in a distributed denial of service (DDoS) against a remote site, will you inform them? Do you want to share information with organizations such as the CERT Coordination Center (CERT/CC) or FIRST?

The FireSIGHT System has features that you can use to gather intrusion data in standard formats such as HTML, PDF, and CSV (comma-separated values) so that you can easily share intrusion data with others.

For example, CERT/CC collects standard information about security incidents on its web site. CERT/CC looks for the kinds of information that you can easily extract from the FireSIGHT System, such as:

- information about the affected machines, including:

- the host name and IP

- the time zone

- the purpose or function of the host

- information about the sources of the attack, including:

- the host name and IP

- the time zone

- whether you had any contact with an attacker

- the estimated cost of handling the incident

- a description of the incident, including:

- dates

- methods of intrusion

- the intruder tools involved

- the software versions and patch levels

- any intruder tool output

- the details of vulnerabilities exploited

- the source of the attack

- any other relevant information

You can also use the comment section of an incident to record when you communicate issues and with whom.

Containment and Recovery

Your incident handling process should clearly indicate what steps are taken when a host or other network component is compromised. The range of containment and recovery options stretches from applying patches to vulnerable hosts to shutting down the target and removing it from the network. You should also consider the importance, depending upon the nature and severity of the attack, of preserving evidence in case you pursue criminal charges.

You can use the incident feature of FireSIGHT System to maintain a record of the actions you take during the containment and recovery phase of the incident.

Lessons Learned

Each security incident, whether or not it is a successful attack, is an opportunity to review your security policies. Do you need to update your firewall rules? Do you need a more structured approach to patch management? Are unauthorized wireless access points a new security issue? Each lesson learned should feed back into your security policies and help you prepare better for the next incident.

Incident Types in the FireSIGHT System

License: Protection

You can assign an incident type to each incident you create. The following types are supported by default in the FireSIGHT System:

- Intrusion

- Denial of Service

- Unauthorized Admin Access

- Web Site Defacement

- Compromise of System Integrity

- Hoax

- Theft

- Damage

- Unknown

You can also create your own incident types, as explained in Creating Custom Incident Types.

Creating an Incident

License: Protection

This section explains how you create an incident.

To create an incident:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Incidents.

The Incidents page appears.

Step 2 Click Create Incident.

The Create Incident page appears.

If you previously copied intrusion events to the clipboard, they are displayed at the bottom of the page. See Using the Clipboard for information about using the clipboard.

Step 3 From the Type drop-down menu, select the option that best describes the incident.

Step 4 In the Time Spent field, enter the amount of time you spent on the incident in the #d #h #m #s format, where # represents the number of days, hours, minutes, or seconds.

Step 5 In the Summary text box, type a short description (up to 255 alphanumeric characters spaces, and symbols) of the incident.

Step 6 In the Add Comment text box, type a more complete description (up to 8191 alphanumeric characters, spaces and symbols) for the incident.

Step 7 Do you want to add events to the incident?

- If yes , select the events on the clipboard and click Add to Incident .

You can also add all the events from the clipboard by clicking Add All to Incident.

- If no , click Save .

In either case, the incident is saved with the information you entered.

Note If you want to add individual events from more than one page on the clipboard, you must add the events from one page, then add the events from the other pages separately.

Editing an Incident

License: Protection

You can update an incident as you collect more information. You can also add or delete events from the incident as your investigation progresses.

To edit an incident:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Incidents.

The Incidents page appears.

) next to the incident you want to edit.

Step 3 You can edit any of the following aspects of the incident:

- change the status

- change the type

- add events from the clipboard

- delete events

Step 4 In the Time Spent field, enter the amount of additional time you spent on the incident.

Step 5 In the Add Comment text box, indicate your changes to the incident (up to 8191 alphanumeric characters, spaces and symbols) for the incident.

Step 6 Optionally, you can add or delete events from the incident:

- To add events from the clipboard, select the events on the clipboard and click Add to Incident .

- To add all the events from the clipboard, click Add All to Incident .

- To delete specific events from the incident, select the events and click Delete .

- To delete all events from the incident, click Delete All .

- To update the incident without adding or deleting events, click Save .

Your changes to the incident are saved.

Generating Incident Reports

License: Protection

You can use the FireSIGHT System to generate incident reports that can include the incident summary, incident status, and any comments along with information from the events you add to the incident. You can also specify whether you want to include event summary information in the report.

To generate an incident report:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Incidents.

The Incidents page appears.

) next to the incident you want to include in your report.

Step 3 You have two options:

- To include all the events from the incident in the report, click Generate Report All .

- To include specific events from the incident in the report, select the check boxes next to the events you want and click Generate Report .

In either case, the Generate Report page appears, including the options for incident reports.

Step 4 Type a name for the report. You can use alphanumeric characters, periods, and spaces.

Step 5 In Incident Report Sections, select the check boxes for the portions of the incident that you want to include in the report: status, summary, and comments.

Step 6 If you want to include event information in the report, select the workflow you want to use and then, in Report Sections, specify whether you want to include event summary information.

Step 7 Select the check boxes next to the workflow pages you want to include in the report.

Step 8 Select the check boxes next to the output formats you want to use for the report: PDF, HTML, and CSV.

Note CSV-based incident reports include only event information. They do not include the status, summary, or comments from the incident.

Step 9 Click Generate Report and confirm that you want to update the report profile.

The report is generated.

Creating Custom Incident Types

License: Protection

The FireSIGHT System is delivered with the following incident types that you can use to classify your incidents:

- Compromise of System Integrity

- Damage

- Denial of Service

- Hoax

- Intrusion

- Theft

- Unauthorized Admin Access

- Unknown

- Web Site Defacement

If these incident types do not meet your needs, you can add your own. Note that you cannot delete any custom incident types.

To create a new incident type:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Intrusions > Incidents.

The Incident page appears.

Step 2 Click Create Incident.

The Create Incident page appears.

Step 3 In the Type area, click Types.

The incident management Types page appears. The default incident types are listed at the bottom of the page.

Step 4 In the Incident Type Name field, type a name for the new incident type.

Use alphanumeric characters and spaces.

Step 5 Click Add.

The new incident type is added.

Step 6 Click Done to close the pop-up window and return to the Incidents page.

You can use the new incident type the next time you create or edit an incident.

Configuring External Alerting

While the FireSIGHT System provides various views of events within the web interface, you may want to configure external event notification to facilitate constant monitoring of critical systems. You can configure the FireSIGHT System to generate alerts that notify you via email, SNMP trap, or syslog when one of the following is generated:

- an intrusion event with a specific impact flag

- a specific type of discovery event

- a network-based malware event or retrospective malware event

- a correlation event, triggered by a specific correlation policy violation

- a connection event, triggered by a specific access control rule

- a specific status change for a module in a health policy

To have the system send these alerts, you must first create an alert response, which is a set of configurations that allows the FireSIGHT System to interact with the external system where you plan to send the alert. Those configurations may specify, for example, an email relay host, SNMP alerting parameters, or syslog facilities and priorities.

After you create the alert response, you associate it with the event that you want to use to trigger the alert. Note that the process for associating alert responses with events is different depending on the type of event:

- You associate alert responses with impact flags, discovery events, and malware events using their own configuration pages.

- You associate correlation events with alert responses (and remediation responses; see Creating Remediations) in your correlation policies.

- You associate SNMP and syslog alert responses with logged connections using access control rules and policies. Email alerting is not supported for logged connections.

- You associate alert responses with health module status changes using the health monitor.

There is another type of alerting you can perform in the FireSIGHT System, which is to configure email, SNMP, and syslog intrusion event notifications for individual intrusion events, regardless of impact flag. You configure these notifications in intrusion policies; see Configuring External Alerting for Intrusion Rules and Adding SNMP Alerts. The following table explains the licenses you must have to generate alerts.

Table 43-1 License Requirements for Generating Alerts

To generate an alert based on...

You need this license...

an intrusion event with a specific impact flag

FireSIGHT + Protection

a specific type of discovery event

FireSIGHT

a network-based malware event

Malware

a correlation policy violation

the license required to trigger the policy violation

a connection event

the license required to log the connection

health module status changes

Any

For more information, see:

- Working with Alert Responses

- Configuring Impact Flag Alerting

- Configuring Discovery Event Alerting

- Configuring Advanced Malware Protection Alerting

- Adding Responses to Rules and White Lists

- Logging Connections in Network Traffic

- Configuring Health Monitor Alerts

Working with Alert Responses

License: Any

The first step in configuring external alerting is to create an alert response, which is a set of configurations that allows the FireSIGHT System to interact with the external system where you plan to send the alert. You can create alert responses to send alerts via email, a simple network management protocol (SNMP) trap, or a system log (syslog).

The information you receive in an alert depends on the type of event that triggered the alert. For example, an impact flag alert contains timestamp, intrusion rule, impact flag, and event description information. As another example, discovery event alerts also contain timestamp and description information, as well as discovery event type information.

If you are using an alert response in a correlation policy, the information in the alert depends on the type of event that triggered the correlation policy violation.

Note If you configure an alert as a response to a correlation rule that contains a connection tracker, the alert information you receive is the same as that for alerts on traffic profile changes, even if the correlation rule itself is based on a different kind of event.

When you create an alert response, it is automatically enabled. Only enabled alert responses can generate alerts. To stop alerts from being generated, you can temporarily disable alert responses rather than deleting your configurations.

You manage alert responses on the Alerts page (Policies > Actions > Alerts). The slider next to each alert response indicates whether it is active; only enabled alert responses can generate alerts. The page also indicates whether the alert response is being used in a configuration, for example, to log connections in an access control rule. You can sort alert responses by name, type, in use status, and enabled/disabled status by clicking the appropriate column header; click the column header again to reverse the sort.

For more information, see:

- Creating an Email Alert Response

- Creating an SNMP Alert Response

- Creating a Syslog Alert Response

- Modifying an Alert Response

- Deleting an Alert Response

- Enabling and Disabling Alert Responses

Creating an Email Alert Response

License: Any

Note that you cannot perform email alerting on logged connections in an access control policy.

Before you create an email alert response, you should make sure that the Defense Center can reverse-resolve its own IP address. You should also configure your mail relay host as described in Configuring a Mail Relay Host and Notification Address.

To create an email alert response:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.

Step 2 From the Create Alert drop-down menu, select Create Email Alert.

The Create Email Alert Configuration pop-up window appears.

Step 3 In the Name field, type the name you want to use to identify the alert response.

Step 4 In the To field, type the email addresses where you want to send alerts.

Separate email addresses with commas.

Step 5 In the From field, type the email address that you want to appear as the sender of the alert.

Step 6 Next to Relay Host, verify the listed mail server is the one that you want to use to send the alert.

) to display the System Policy page in a pop-up window, then follow the directions in Configuring a Mail Relay Host and Notification Address. You must apply the system policy after you edit it for your changes to take effect.

Step 7 Click Save.

The alert response is saved and is automatically enabled.

Creating an SNMP Alert Response

License: Any

You can create SNMP alert responses using SNMPv1, SNMPv2, or SNMPv3.

Note When selecting SNMP versions for the SNMP protocol, note that SNMPv2 only supports read-only communities and SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.

Note If you want to monitor 64-bit values with SNMP, you must use SNMPv2 or SNMPv3. SNMPv1 does not support 64-bit monitoring.

If your network management system requires the Defense Center’s management information base (MIB) file, you can obtain it at /etc/sf/DCEALERT.MIB.

To create an SNMP alert response:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.

Step 2 From the Create Alert drop-down menu, select Create SNMP Alert.

The Create SNMP Alert Configuration pop-up window appears.

Step 3 In the Name field, type the name that you want to use to identify the SNMP response.

Step 4 In the Trap Server field, type the hostname or IP address of the SNMP trap server, using alphanumeric characters.

Note that the system does not warn you if you enter an invalid IPv4 address (such as 192.169.1.456) in this field. Instead, the invalid address is treated as a hostname.

Step 5 From the Version drop-down list, select the SNMP version you want to use.

SNMP v3 is the default. If you select SNMP v1 or SNMP v2, different options appear.

Step 6 Which version of SNMP did you select?

- For SNMP v1 or SNMP v2, type the SNMP community name, using alphanumeric characters or the special characters * or $, in the Community String field and skip to step 12 .

Note SNMPv2 only supports read-only communities.

- For SNMP v3, type the name of the user that you want to authenticate with the SNMP server in the User Name field and continue with the next step.

Note SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.

Step 7 From the Authentication Protocol drop-down list, select the protocol you want to use for authentication.

Step 8 In the Authentication Password field, type the password required for authentication with the SNMP server.

Step 9 From the Privacy Protocol list, select None to use no privacy protocol or DES to use Data Encryption Standard as the privacy protocol.

Step 10 In the Privacy Password field, type the privacy password required by the SNMP server.

Step 11 In the Engine ID field, type an identifier for the SNMP engine, in hexadecimal notation, using an even number of digits.

When you use SNMPv3, the system uses an Engine ID value to encode the message. Your SNMP server requires this value to decode the message.

Cisco recommends that you use the hexadecimal version of the Defense Center’s IP address. For example, if the Defense Center has an IP address of 10.1.1.77, use 0a01014D0.

Step 12 Click Save.

The alert response is saved and is automatically enabled.

Creating a Syslog Alert Response

License: Any

When configuring a syslog alert response, you can specify the severity and facility associated with the syslog messages to ensure that they are processed properly by the syslog server. The facility indicates the subsystem that creates the message and the severity defines the severity of the message. Facilities and severities are not displayed in the actual message that appears in the syslog, but are instead used to tell the system that receives the syslog message how to categorize it.

Tip For more detailed information about how syslog works and how to configure it, refer to the documentation for your system. On UNIX systems, the man pages for syslog and syslog.conf provide conceptual information and configuration instructions.

Although you can select any type of facility when creating a syslog alert response, you should select one that makes sense based on your syslog server; not all syslog servers support all facilities. For UNIX syslog servers, the syslog.conf file should indicate which facilities are saved to which log files on the server.

The following table lists the syslog facilities you can select.

Table 43-2 Available Syslog Facilities

Facility

Description

ALERT

An alert message.

AUDIT

A message generated by the audit subsystem.

AUTH

A message associated with security and authorization.

AUTHPRIV

A restricted access message associated with security and authorization. On many systems, these messages are forwarded to a secure file.

CLOCK

A message generated by the clock daemon.

Note that syslog servers running a Windows operating system will use the CLOCK facility.

CRON

A message generated by the clock daemon.

Note that syslog servers running a Linux operating system will use the CRON facility.

DAEMON

A message generated by a system daemon.

FTP

A message generated by the FTP daemon.

KERN

A message generated by the kernel. On many systems, these messages are printed to the console when they appear.

LOCAL0-LOCAL7

A message generated by an internal process.

LPR

A message generated by the printing subsystem.

MAIL

A message generated by a mail system.

NEWS

A message generated by the network news subsystem.

NTP

A message generated by the NTP daemon.

SYSLOG

A message generated by the syslog daemon.

USER

A message generated by a user-level process.

UUCP

A message generated by the UUCP subsystem.

The following table lists the standard syslog severity levels you can select.

Table 43-3 Syslog Severity Levels

Level

Description

ALERT

A condition that should be corrected immediately.

CRIT

A critical condition.

DEBUG

Messages that contain debugging information.

EMERG

A panic condition broadcast to all users.

ERR

An error condition.

INFO

Informational messages.

NOTICE

Conditions that are not error conditions, but require attention.

WARNING

Warning messages.

Before you start sending syslog alerts, make sure that the syslog server can accept remote messages.

To create a syslog alert:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.From the Create Alert drop-down menu, select Create Syslog Alert.

The Create Syslog Alert Configuration pop-up window appears.

Step 2 In the Name field, type the name you want to use to identify the saved response.

Step 3 In the Host field, type the hostname or IP address of your syslog server.

Note that the system does not warn you if you enter an invalid IPv4 address (such as 192.168.1.456) in this field. Instead, the invalid address is treated as a hostname.

Step 4 In the Port field, type the port the server uses for syslog messages.

By default, this value is 514.

Step 5 From the Facility list, select a facility.

See the Available Syslog Facilities table for a list of the available facilities.

Step 6 From the Severity list, select a severity.

See the Syslog Severity Levels table for a list of the available severities.

Step 7 In the Tag field, type the tag name that you want to appear with the syslog message.

Use only alphanumeric characters in tag names. You cannot use spaces or underscores.

As an example, if you wanted all messages sent to the syslog to be preceded with FromDC, type FromDC in the field.

Step 8 Click Save.

The alert response is saved and is automatically enabled.

Modifying an Alert Response

License: Any

For most types of alerting, if an alert response is enabled and in use, changes to the alert response take effect immediately. However, for alert responses used in access control rules to log connection events, changes do not take effect until you reapply the access control policy.

To edit an alert response:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.

).

A configuration pop-up window for that alert response appears.

Step 3 Make changes as needed.

Step 4 Click Save.

The alert response is saved.

Deleting an Alert Response

License: Any

You can delete any alert response that is not in use.

To delete an alert response:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.

).

Step 3 Confirm that you want to delete the alert response.

The alert response is deleted.

Enabling and Disabling Alert Responses

License: Any

Only enabled alert responses can generate alerts. To stop alerts from being generated, you can temporarily disable alert responses rather than deleting your configurations. Note that if an alert is in use when you disable it, it is still considered in use even though it is disabled.

To enable or disable an alert response:

Access: Admin

Step 1 Select Policies > Actions > Alerts.

The Alerts page appears.

Step 2 Next to the alert response you want to enable or disable, click the enable/disable slider.

If the alert response was enabled, it is disabled. If it was disabled, it is enabled.

Configuring Impact Flag Alerting

License: Protection

You can configure the system to alert you whenever an intrusion event with a specific impact flag occurs. Impact flags help you evaluate the impact an intrusion has on your network by correlating intrusion data, network discovery data, and vulnerability information. For more information, see Using Impact Levels to Evaluate Events.

To configure impact flag alerting:

Access: Admin

Step 1 Select Policies > Actions > Alerts, then select the Impact Flag Alerts tab.

The Impact Flag Alerts page appears.

Step 2 In the Alerts section, select the alert response you want to use for each alert type.

To create a new alert response, select New from any drop-down list. For more information, see Working with Alert Responses.

Step 3 In the Impact Configuration section, select the check boxes that correspond to the alerts you want to receive for each impact flag.

Step 4 Click Save.

Your impact flag alerting settings are saved.

Configuring Discovery Event Alerting

License: FireSIGHT

You can configure the system to alert you whenever a specific type of discovery event occurs. For information about the different event types, see Understanding Discovery Event Types and Understanding Host Input Event Types.

Note that to generate an alert based on a discovery event type, you must configure your network discovery policy to log that event type; see Configuring Discovery Event Logging. By default, logging is enabled for all event types.

To configure discovery event alerting:

Access: Admin

Step 1 Select Policies > Actions > Alerts, then select the Discovery Event Alerts tab.

The Discovery Event Alerts page appears.

Step 2 In the Alerts section, select the alert response you want to use for each alert type.

To create a new alert response, select New from any drop-down list. For more information, see Working with Alert Responses.

Step 3 In the Events Configuration section, select the check boxes that correspond to the alerts you want to receive for each discovery event type.

Step 4 Click Save.

Your discovery event alerting settings are saved.

Configuring Advanced Malware Protection Alerting

License: Malware

Supported Devices: Series 3 or virtual

Supported Defense Centers: Any except DC500

You can configure the system to alert you whenever any network-based malware event, including a retrospective event, is generated. You cannot, however, alert on endpoint-based (FireAMP) malware events. For information on malware events, see Working with Malware Events.

To generate alerts based on malware events, you must create a file policy that performs malware cloud lookups, then associate that policy with an access control rule. For more information, see Controlling Traffic Using Intrusion and File Policies.

To configure malware event alerting:

Access: Admin

Step 1 Select Policies > Actions > Alerts, then select the Advanced Malware Protections Alerts tab.

The Advanced Malware Protection Alerts page appears.

Step 2 In the Alerts section, select the alert response you want to use for each alert type.

To create a new alert response, select New from any drop-down list. For more information, see Working with Alert Responses.

Step 3 In the Event Configuration section, select the check boxes that correspond to the alerts you want to receive for each malware event type.

Keep in mind that All network-based malware events includes Retrospective Events.

Step 4 Click Save.

Your malware event alerting settings are saved.

Configuring External Alerting for Intrusion Rules

While the FireSIGHT System provides various views of intrusion events within the web interface, some enterprises prefer to define external intrusion event notification to facilitate constant monitoring of critical systems. If you want to immediately notify a specific person of critical events, you can set up email alerts to do so. You can also enable logging to syslog facilities or send event data to an SNMP trap server.

Within each intrusion policy, you can specify intrusion event notification limits, set up intrusion event notification to external logging facilities, and configure external responses to intrusion events.

Tip Some analysts prefer not to receive multiple alerts for the same intrusion event, but want to control how often they are notified of a given intrusion event occurrence. See Filtering Intrusion Event Notification Per Policy for more information.

There is another type of alerting you can perform in the FireSIGHT System, outside of your intrusion policies. You can configure email, SNMP, and syslog alert responses for other types of events, including intrusion events with specific impact flags, or connection events logged by specific access control rules. For more information, see Configuring External Alerting.

See the following sections for more information on external intrusion event notification:

- Using SNMP Responses describes the options you can configure to send event data to specified SNMP trap servers and provides the procedure for specifying the SNMP alerting options.

- Using Syslog Responses describes the options you can configure to send event data to an external syslog and provides the procedure for specifying the syslog alerting options.

- Understanding Email Alerting describes the options you can configure to send notifications of intrusion events by email.

Using SNMP Responses

License: Protection

An SNMP trap is a network management notification. You can configure the device to send intrusion event notifications as SNMP traps, also known as SNMP alerts. Each SNMP alert includes:

- the name of the server generating the trap

- the IP address of the device that detected it

- the name of the device that detected it

- the event data

You can set a variety of SNMP alerting parameters. Available parameters vary depending on the version of SNMP you use. For details on enabling and disabling SNMP alerting, see Configuring Advanced Settings in an Intrusion Policy.

Tip If your network management system requires a management information base file (MIB), you can obtain it from the Defense Center at /etc/sf/DCEALERT.MIB.

SNMP v2 Options

Option

Description

Trap Type

The trap type to use for IP addresses that appear in the alerts.

If your network management system correctly renders the INET_IPV4 address type, then you can select as Binary. Otherwise, select as String. For example, HP Openview requires the string type.

Trap Server

The server that will receive SNMP traps notification.

You can specify a single IP address or hostname.

Community String

The community name.

SNMP v3 Options

For SNMP v3, you can specify the options described in the following table.

Note When using SNMP v3, the appliance uses an Engine ID value to encode the message. Your SNMP server requires this value to decode the message. Currently, this Engine ID value will always be the hexadecimal version of the appliance’s IP address with 01 at the end of the string. For example, if the appliance sending the SNMP alert has an IP address of 172.16.1.50, the Engine ID is 0xAC10013201 or, if the appliance has an IP address of 10.1.1.77, 0x0a01014D01 is used as the Engine ID.

Table 44-2 SNMP v3 Options

Option

Description

Trap Type

The trap type to use for IP addresses that appear in the alerts.

If your network management system correctly renders the INET_IPV4 address type, then you can select as Binary. Otherwise, select as String. For example, HP Openview requires the string type.

Trap Server

The server that will receive SNMP traps notification.

You can specify a single IP address or hostname.

Authentication Password

The password required for authentication. SNMP v3 uses either the Message Digest 5 (MD5) hash function or the Secure Hash Algorithm (SHA) hash function to encrypt this password, depending on configuration.

If you specify an authentication password, authentication is enabled.

Private Password

The SNMP key for privacy. SNMP v3 uses the Data Encryption Standard (DES) block cipher to encrypt this password.

If you specify a private password, privacy is enabled. If you specify a private password, you must also specify an authentication password.

User Name

Your SNMP user name.

For information about configuring SNMP Alerting, see Configuring SNMP Responses.

Configuring SNMP Responses

License: Protection

You can configure SNMP alerting in an intrusion policy. After you apply the policy as part of an access control policy, the system notifies you of any intrusion events it detects via SNMP trap. For more details on SNMP alerting, see Using SNMP Responses.

To configure SNMP alerting options:

Access: Admin/Intrusion Admin

Step 1 Select Policies> Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether SNMP Alerting under External Responses is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The SNMP Alerting page appears.

A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Specify the trap type format that you want to use for IP addresses that appear in the alerts, as Binary or as String.

Note If your network management system correctly renders the INET_IPV4 address type, then you can use the as Binary option. Otherwise, use the as String option. For example, HP OpenView requires the as String option.

Step 6 Select either SNMP v2 or SNMP v3:

- To configure SNMP v2, enter the IP address and the community name of the trap server you want to use in the corresponding fields. See SNMP v2 Options.

- To configure SNMP v3, enter the IP address of the trap server you want to use, an authentication password, a private password, and a user name in the corresponding fields. See SNMP v3 Options for more information.

Note You must select SNMP v2 or SNMP v3.

Note When you enter an SNMP v3 password, the password displays in plain text during initial configuration but is saved in encrypted format.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Using Syslog Responses

License: Protection

The system log, or syslog, is the standard logging mechanism for network event logging. You can send syslog alerts, which are intrusion event notifications, to the syslog on an appliance. The syslog allows you to categorize information in the syslog by priority and facility. The priority reflects the severity of the alert and the facility indicates the subsystem that generated the alert. Facilities and priorities are not displayed in the actual message that appears in syslog, but are instead used to tell the system that receives the syslog message how to categorize it.

Syslog alerts contain the following information:

- date and time of alert generation

- event message

- event data

- generator ID of the triggering event

- Snort ID of the triggering event

- revision

In an intrusion policy, you can turn on syslog alerting and specify the syslog priority and facility associated with intrusion event notifications in the syslog. When you apply the intrusion policy as part of an access control policy, the system then sends syslog alerts for the intrusion events it detects to the syslog facility on the local host or on the logging host specified in the policy. The host receiving the alerts uses the facility and priority information you set when configuring syslog alerting to categorize the alerts.

Facility

Description

AUTH

A message associated with security and authorization.

AUTHPRIV

A restricted access message associated with security and authorization. On many systems, these messages are forwarded to a secure file.

CRON

A message generated by the clock daemon.

DAEMON

A message generated by a system daemon.

FTP

A message generated by the FTP daemon.

KERN

A message generated by the kernel. On many systems, these messages are printed to the console when they appear.

LOCAL0-LOCAL7

A message generated by an internal process.

LPR

A message generated by the printing subsystem.

MAIL

A message generated by a mail system.

NEWS

A message generated by the network news subsystem.

SYSLOG

A message generated by the syslog daemon.

USER

A message generated by a user-level process.

UUCP

A message generated by the UUCP subsystem.

Level

Description

EMERG

A panic condition broadcast to all users

ALERT

A condition that should be corrected immediately

CRIT

A critical condition

ERR

An error condition

WARNING

Warning messages

NOTICE

Conditions that are not error conditions, but require attention

INFO

Informational messages

DEBUG

Messages that contain debug information

For more detailed information about how syslog works and how to configure it, refer to the documentation that accompanies your system. If you are logging to a UNIX- or Linux-based system’s syslog, the syslog.conf man file (type man syslog.conf at the command line) and syslog man file (type man syslog at the command line) provide information about how syslog works and how to configure it.

Configuring Syslog Responses

License: Protection

You can configure syslog alerting in an intrusion policy. After you apply the policy as part of an access control policy, the system notifies you of any intrusion events it detects via the syslog. For more information on syslog alerting, see Using Syslog Responses.

To configure syslog alerting options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Intrusion Policy.

The Intrusion Policy page appears.

) next to the policy you want to edit.

If you have unsaved changes in another policy, click OK to discard those changes and continue. See Resolving Conflicts and Committing Policy Changes for information on saving unsaved changes in another policy.

The Policy Information page appears.

Step 3 Click Advanced Settings in the navigation panel on the left.

The Advanced Settings page appears.

Step 4 You have two choices, depending on whether Syslog Alerting under External Responses is enabled:

- If the configuration is enabled, click Edit .

- If the configuration is disabled, click Enabled , then click Edit .

The Syslog Alerting page appears.

A message at the bottom of the page identifies the intrusion policy layer that contains the configuration. See Using Layers in a Network Analysis or Intrusion Policy for more information.

Step 5 Optionally, in the Logging Hosts field, enter the remote access IP address you want to specify as logging host. Separate multiple hosts with commas.

Step 6 Select facility and priority levels from the drop-down lists.

See Using Syslog Responses for details on facility and priority options.

Step 7 Save your policy, continue editing, discard your changes, revert to the default configuration settings in the base policy, or exit while leaving your changes in the system cache. See Resolving Conflicts and Committing Policy Changes for more information.

Understanding Email Alerting

License: Protection

Email alerts are notifications of intrusion events by email. Email alerts include the following information:

- total number of alerts in the database

- last email time (the time that the system generated the last email report)

- current time (the time that the system generated the current email report)

- total number of new alerts

- number of events that matched specified email filters (if events are configured for specific rules)

- timestamp, protocol, event message, and session information (source and destination IPs and ports with traffic direction) for each event (if Summary Output is off)

Note If multiple intrusion events originate from the same source IP, a note appears beneath the event that displays the number of additional events.

- number of events per destination port

- number of events per source IP

For each rule or rule group, you can enable or disable email alerting on intrusion events. Your email alert settings are used regardless of which intrusion policy you apply to the device as part of an access control policy.

The following list describes the parameters you can set for email alerting.

On/Off

Enables or disables email notification.

From Address

Specifies the email address or addresses from which the system sends intrusion events.

To Address

Specifies the email address where the system sends intrusion events. To send email to multiple recipients, separate email addresses with commas. For example:

user1@example.com, user2@example.com

Max Alerts

Specifies the maximum number of intrusion events the system sends via email in the time frame specified by Frequency (seconds).

Frequency (seconds)

Specifies how often the system mails intrusion events. The Frequency setting also specifies the frequency with which email settings are saved.

Minimum frequency: 300 seconds

Maximum frequency: 4 billion seconds

Coalesce Alerts

Enables or disables grouping of intrusion events by source IP and event so that multiple identical intrusion events generated against the same source IP only present one event on the page.

Note that alert coalescence (grouping) occurs after events are filtered. Therefore, if you configure email alerting on specific rules, you will only receive a list of events that match the rules you specified in the Mail Alerting Configuration.

Summary Output

Enables or disables brief email alerting, which is suitable for text-limited devices such as pagers. Brief email alerts contain:

– event timestamp

– for Defense Centers, the IP address for the device that generated the event

– event protocol

– source IP and port

– destination IP and port

– event message

– the number of intrusion events generated against the same source IP

For example:

2011-05-18 10:35:10 10.1.1.100 icmp 10.10.10.1:8 -> 10.2.1.3:0

snort_decoder: Unknown Datagram decoding problem! (116:108)

Email Alerting on Specific Rules Configuration

Specifies the rules or rule groups whose events you want mailed to the specified email address or addresses.

For information about configuring email alerting, see Configuring Email Alerting.

Configuring Email Alerting

License: Protection

You can configure email alerting so that your appliance notifies you whenever an intrusion event occurs for an specific rule or rule group.

Before you can receive email alerts, you must:

- configure your mail host to receive email alerts (see Configuring a Mail Relay Host and Notification Address)

- make sure that both the managed device and the Defense Center can reverse resolve their own IP addresses

To configure email alerting options:

Access: Admin/Intrusion Admin

Step 1 Select Policies > Intrusion > Email.

The Email Alerting page appears.

Step 2 Next to State, select on to enable email alerting.

Step 3 In the From Address field, type the address you want to display in the From field in the email alerts.

Step 4 In the To Address field, type the address where you want to receive the email alerts.

Step 5 In the Max Alerts field, type the maximum number of events you want included in a single email.

Step 6 In the Min Frequency field, type the number of seconds for the minimum frequency with which you want to receive email alerts.

Step 7 To group events by IP address, next to Coalesce Alerts, select on.

Step 8 To send brief email alerts, next to Summary Output, select on.

Tip If you enable Summary Output, consider enabling Coalesce Alerts to reduce the number of alerts generated. Also consider setting Max Alerts to 1 to avoid overflowing your device’s text message buffer.

Step 9 In the Time Zone field, select your time zone from the drop-down list.

Step 10 To enable email alerting per rule, click Email Alerting per Rule Configuration.

The rule groups appear.

Tip To receive email alerts for all rules in all categories, select Select All.

Step 11 Perform one or both of the following:

- Click All next to rule categories for which you want to receive email alerts for all rules belonging to the category.

- Click the category folder within which you want to specify email alerting on individual rules in that category, then enable the rules for which you want to receive email alerts.

Step 12 Click Save.

The system saves your email alerting configuration. When applicable intrusion events occur, you receive email alerts.

Introduction to Network Discovery

The FireSIGHT System uses a feature called network discovery to monitor traffic on your network and build a comprehensive map of your network assets.

As managed devices passively observe traffic on the network segments you specify, the system compares specific packet header values and other unique data from network traffic against established definitions (called fingerprints) to determine the number and types of hosts (including network devices) on your network, as well as the operating systems, active applications, and open ports on those hosts.

You can also configure FireSIGHT System managed devices to monitor user activity on your network, which allows you to identify the source of policy breaches, attacks, or network vulnerabilities.

To supplement the data gathered by the system, you can import records generated by NetFlow-enabled devices, Nmap active scans, the host input feature, and User Agents that reside on a Microsoft Active Directory server and report LDAP authentications. The FireSIGHT System integrates these records with the information it collects via direct network traffic observation by managed devices.

The system can correlate certain types of intrusion, malware, and other events occurring on hosts on your network to determine when hosts are potentially compromised, tagging those hosts with indications of compromise (IOC) tags. IOC data can give you a clear, direct picture of the threats to your monitored network as they relate to its hosts.

The system uses all of this information to help you with forensic analysis, behavioral profiling, access control, and mitigating and responding to the vulnerabilities and exploits to which your organization is susceptible.

For more information, see:

- Understanding Discovery Data Collection

- Understanding NetFlow

- Understanding Indications of Compromise

- Creating a Network Discovery Policy

Understanding Discovery Data Collection

License: FireSIGHT

Discovery data includes information on your network’s hosts and the operating systems, active applications, and user activity on those hosts.

To begin collecting discovery data, you must first apply an access control policy. The access control policy defines the traffic that you permit, and therefore the traffic you can monitor with network discovery. Note that this means if you block certain traffic using access control, the system cannot examine that traffic for host, user, or application activity. For example, if you block access to social networking applications, the system does not provide you with any discovery data on social network applications.

After you apply an access control policy, you must configure and apply a network discovery policy, which specifies the network segments and ports you want to monitor with your managed devices, and the kinds of data you want to collect. When you apply the network discovery policy, the system begins generating discovery data, which you can then view and analyze using the Defense Center web interface.

The system stores network discovery data in the Defense Center database; for information on storage limits, see Configuring Database Event Limits. In addition to the database limits, the total number of detected hosts and users the Defense Center can store depends on your FireSIGHT license.

After you reach the licensed user limit, in most cases, the system stops adding new users to the database. To add new users, you must either manually delete old or inactive users from the database, or purge all users from the database. On the other hand, after you reach the licensed host limit, you can configure the system either to stop adding new hosts to the database, or to replace the hosts that have remained inactive for the longest time.

To supplement the data gathered by the system, you can import records generated by NetFlow-enabled devices, Nmap active scans, the host input feature, and User Agents that reside on a Microsoft Active Directory server and report LDAP authentications. The FireSIGHT System integrates these records with the information it collects via direct network traffic observation by managed devices.

For more information, see:

- Understanding Host Data Collection

- Understanding User Data Collection

- Understanding Application Detection

- Understanding Indications of Compromise

- Importing Third-Party Discovery Data

- Uses for Discovery Data

Understanding Host Data Collection

License: FireSIGHT

As the system passively monitors the traffic that travels through your network, it compares specific packet header values and other unique data from network traffic against established definitions (called fingerprints) to determine the following information about the hosts on your network, including:

- the number and types of hosts (including network devices such as bridges, routers, load balancers, and NAT devices)

- basic network topology data, including the number of hops from the discovery point on the network to the hosts

- the operating systems running on the hosts

- applications on the hosts and users associated with these applications

If the system cannot identify the operating system of a host, you can use the custom fingerprinting feature to create custom client or server fingerprints. The system uses these fingerprints to identify new hosts. You can map fingerprints to systems in the vulnerability database (VDB) to allow the appropriate vulnerability information to be displayed whenever a host is identified using the custom fingerprint. For more information, see Using Custom Fingerprinting.

You can also add or update host and operating system data through the host input feature. In addition, if you create a NetFlow-enabled discovery rule with host detection enabled, hosts can be added to the network map from NetFlow data.

You can view the hosts detected by the system using the Defense Center web interface:

- For information on viewing and searching for hosts using the event viewer, see Working with Hosts.

- For information on viewing the network map, which is a detailed representation of your network assets and topology, see Using the Network Map.

- For information on viewing host profiles, which are complete views of all the information available for your detected hosts, see Using Host Profiles.

Understanding User Data Collection

License: FireSIGHT

You can use the FireSIGHT System to monitor user activity on your network, which allows you to correlate threat, endpoint, and network intelligence with user identity information. By linking network behavior, traffic, and events directly to individual users, the system can help you to identify the source of policy breaches, attacks, or network vulnerabilities. In other words, the system can tell you the “who” behind the “what.” For example, you could determine:

- who owns the host targeted by an intrusion event that has a Vulnerable (level 1: red) impact level

- who initiated an internal attack or portscan

- who is attempting unauthorized access of a server that has high host criticality

- who is consuming an unreasonable amount of bandwidth

- who has not applied critical operating system updates

- who is using instant messaging software or peer-to-peer file-sharing applications in violation of company IT policy

Armed with this information, you can take a targeted approach to mitigate risk, block users or user activity, and take action to protect others from disruption. These capabilities also significantly improve audit controls and enhance regulatory compliance.

The system downloads the users used in access control policies from the Microsoft Active Directory LDAP server, based on the user awareness settings in the LDAP connection. The User Agent then provides login data for these users and the users are added to the user database. These users are referred to as access-controlled users. When you author access control policies that include user conditions, you write those conditions against access-controlled users. For more information, see Adding a User Condition to an Access Control Rule.

When the system detects user data from a user login, either from a User Agent, from application data detected in traffic, or from an email login over POP3, SMTP, or IMAP, the user from the login is checked against the list of users. If the login user matches an existing user reported by an agent, the data from the login is assigned to the user. Logins that do not match existing users cause a new user to be created, unless the login is in SMTP traffic. Non-matching logins in SMTP traffic are discarded.

The following diagram illustrates how the FireSIGHT System collects and stores user data.

As shown in the diagram, there are three sources for user data, and three places that data is stored. For more information on user data collection, see:

- Managed Devices

- User Agents

- Defense Center-LDAP Server Connections

- Users Database

- User Activity Database

- Access-Controlled Users Database

- User Data Collection Limitations

Managed Devices

License: FireSIGHT

You use the network discovery policy to configure managed devices to passively detect LDAP, AIM, POP3, IMAP, Oracle, SIP (VoIP), FTP, HTTP, MDNS, and SMTP logins on the networks you specify. Note that when you enable discovery of users in a network discovery rule, host discovery is automatically enabled.

Note Managed devices interpret only Kerberos logins for LDAP connections as LDAP authentications. Managed devices cannot detect encrypted LDAP authentications using protocols such as SSL or TLS.

When a device detects a login, it sends the following information to the Defense Center to be logged as user activity:

- the user name identified in the login

- the time of the login

- the IP address involved in the login, which can be the IP address of the user’s host (for LDAP, POP3, IMAP, and AIM logins), the server (for HTTP, MDNS, FTP, SMTP and Oracle logins), or the session originator (for SIP logins)

- the user’s email address (for POP3, IMAP, and SMTP logins)

- the name of the device that detected the login

If the user was previously detected, the Defense Center updates that user’s login history. Note that the Defense Center can use the email addresses in POP3 and IMAP logins to correlate with LDAP users. This means that, for example, if the Defense Center detects a new IMAP login, and the email address in the IMAP login matches that for an existing LDAP user, the IMAP login does not create a new user, rather, it updates the LDAP user’s history.

If the user has never been detected before, the Defense Center adds the user to the users database. Unique AIM, SIP, and Oracle logins always create new user records, because there is no data in those login events that the Defense Center can correlate with other login types.

The Defense Center does not log user activity or user identities in the following cases:

- if you configured the network discovery policy to ignore that login type, as described in Restricting User Logging

- if a managed device detects an SMTP login, but the users database does not contain a previously detected LDAP, POP3, or IMAP user with a matching email address

User Agents

License: FireSIGHT

If your organization uses Microsoft Active Directory LDAP servers, Cisco recommends that you install User Agents to monitor user activity via your Active Directory servers. If you want to perform user control, you must install and use User Agents; the agents associate users with IP addresses, which in turn allows access control rules with user conditions to trigger. You can use one agent to monitor user activity on up to five Active Directory servers.

To use an agent, you must configure a connection between each Defense Center connected to the agent and the monitored LDAP servers. This connection not only allows you to retrieve metadata for the users whose logins and logoffs were detected by User Agents, but also is used to specify the users and groups you want to use in access control rules. For more information on configuring LDAP servers for user discovery, see Retrieving Access-Controlled Users and LDAP User Metadata.

Each agent can monitor logins using encrypted traffic, either through regularly scheduled polling or real-time monitoring. Logins are generated by the Active Directory server when a user logs into a computer, whether at the workstation or through a Remote Desktop login.

Agents can also monitor and report user logoffs. Logoffs are generated by the agent itself when it detects a user logged out of a host IP address. Logoffs are also generated when the agent detects that the user logged into a host has changed, before the Active Directory server reports that the user has changed. Combining logoff data with login data develops a more complete view of the users logged into the network.

Polling an Active Directory server allows an agent to retrieve batches of user activity data at the defined polling interval. Real-time monitoring transmits user activity data to the agent as soon as the Active Directory server receives the data.

You can configure the agent to exclude reporting any logins or logoffs associated with a specific user name or IP address. This can be useful, for example, to exclude repeated logins to shared servers, such as file shares and print servers, as well as exclude users logging into machines for troubleshooting purposes.

The agents send records of all detected logins and logoffs that do not contain an excluded user name or IP address to Defense Centers, which log and report them as user activity. The agents detect the Defense Center version and send the login records in the appropriate data format. This supplements any user activity detected directly by managed devices. The logins reported by User Agents associate users with IP addresses, which in turn allows access control rules with user conditions to trigger.

User Agents monitor users as they log into the network or when accounts authenticate against Active Directory credentials for other reasons. Version 2.1 of the User Agent detects interactive user logins to a host, Remote Desktop logins, file-share authentication, and computer account logins, as well as user logoffs and Remote Desktop sessions where the user has logged off.

The type of login detected determines how the agent reports the login and how the login appears in the host profile. An authoritative user login for a host causes the current user mapped to the host IP address to change to the user from the new login. Other logins either do not change the current user or only change the current user for the host if the existing user on the host did not have an authoritative user login to the host. In these cases, if the expected user is no longer logged in, the agent generates a logoff for that user. User logins detected by network discovery only change the current user for the host if the existing user on the host did not have an authoritative user login to the host. Agent-detected logins have the following effect on the network map:

- When the agent detects an interactive login to a host by a user or a Remote Desktop login, the agent reports an authoritative user login for the host and changes the current user for the host to the new user.

- If the agent detects a login for file-share authentication, the agent reports a user login for the host, but does not change the current user on the host.

- If the agent detects a computer account login to a host, the agent generates a NetBIOS Name Change discovery event and the host profile reflects any change to the NetBIOS name.

- If the agent detects a login from an excluded user name, the agent does not report a login to the Defense Center.

When a login or other authentication occurs, the agent sends the following information to the Defense Center:

- the user’s LDAP user name

- the time of the login or other authentication

- the IP address of the user’s host, and the link-local address if the agent reports an IPv6 address for a computer account login

The Defense Center records login and logoff information as user activity. When a User Agent reports user data from a user login or logoff, the reported user is checked against the list of users. If the reported user matches an existing user reported by an agent, the reported data is assigned to the user. Reported users that do not match existing users cause a new user to be created.

Even though the user activity associated with an excluded user name is not reported, related user activity may still be reported. If the agent detects a user login to a machine, then the agent detects a second user login, and you have excluded the user name associated with the second user login from reporting, the agent reports a logoff for the original user. However, no login for the second user is reported. As a result, no user is mapped to the IP address, even though the excluded user is logged into the host.

Note the following limitations on user names detected by the agent:

- User names ending with a dollar sign character ( $ ) reported to the Defense Center update the network map, but do not appear as user logins.

- Defense Center display of user names containing Unicode characters may have limitations.

The total number of detected users the Defense Center can store depends on your FireSIGHT license. After you reach the licensed user limit, in most cases the system stops adding new users to the database. To add new users, you must either manually delete old or inactive users from the database, or purge all users from the database.

Defense Center-LDAP Server Connections

License: FireSIGHT

The Defense Center-LDAP server connection allows you to retrieve metadata for certain detected users. You can retrieve metadata for LDAP users, whether their logins were detected by managed devices or by a User Agent; you can also retrieve metadata for POP3 and IMAP users if those users have the same email address as an LDAP user.

If your organization uses Microsoft Active Directory servers, the connection also allows you to specify the LDAP users and groups you want to use in access control rules. If you want to perform user control, you must configure a connection between the Defense Center and an Active Directory server. If your organization does not use Active Directory, you can still detect user logins using managed devices, and you can still obtain metadata for some of those users from an Oracle or OpenLDAP server. However, you cannot perform user control based on those users or their activity.

From the LDAP server, the Defense Center obtains the following information and metadata about each user:

- LDAP user name

- first and last names

- email address

- department

- telephone number

Users Database

License: FireSIGHT

The users database contains a record for each user detected by either managed devices or User Agents. The total number of detected users the Defense Center can store depends on your FireSIGHT license. After you reach the licensed limit, in most cases the system stops adding new users to the database. To add new users, you must either manually delete old or inactive users from the database, or purge all users from the database.

However, the system favors authoritative user logins. If you have reached the limit and the system detects an authoritative user login for a previously undetected user, the system deletes the non-authoritative user who has remained inactive for the longest time, and replaces it with the new user.

You can view the contents of the users database with the Defense Center web interface. For information on viewing, search for, and deleting detected users, see Working with Users.

User Activity Database

License: FireSIGHT

The user activity database contains records of user activity on your network, either from a connection to an Active Directory LDAP server that is also monitored by a User Agent, or though network discovery. The system logs events in the following circumstances:

- when it detects individual logins or logoffs

- when it detects a new user

- when you manually delete a user

- when the system detects a user that is not in the database, but cannot add the user because you have reached your FireSIGHT licensed limit

You can view the user activity detected by the system using the Defense Center web interface. For information on viewing, searching for, and deleting user activity, see Working with User Activity. If you plan to use Version 2.1 of the User Agent to send LDAP login data to your Defense Centers, you must configure a connection for each agent on each Defense Center where you want the agent to connect. That connection allows the agent to establish a secure connection with the Defense Center, over which it can send login data. If the agent is configured to exclude specific user names, login data for those user names are not reported to the Defense Center.

In addition, if you are planning to implement user access control, you must set up a connection to each Microsoft Active Directory server where you plan to collect data, with user awareness parameters configured.

Whenever possible the FireSIGHT System correlates user activity with other types of events. For example, intrusion events can tell you the users who were logged into the source and destination hosts at the time of the event.

The system also uses user activity to generate host histories, which track the hosts that each user has logged into, and user histories, which track the users that have logged into each individual host. The system provides a graphical representation of the last twenty-four hours of each user’s activity and the last twenty-four hours of the logins to each host. For more information, see Understanding User Details and Host History and Working with User History in the Host Profile.

Access-Controlled Users Database

License: Control

The access-controlled users database contains the users and groups that you can use in access control rules, so that you can perform user control with the FireSIGHT System. These users can be one of two types:

- An access-controlled user is a user that you can add to access control rules to perform user control. You specify the groups that access-controlled users must belong to when you configure the Defense Center-LDAP server connection.

- A non-access-controlled user is any other detected user.

You specify the groups that access-controlled users must belong to when you configure the Defense Center-LDAP server connection, as described in Retrieving Access-Controlled Users and LDAP User Metadata.

If you plan to use Version 2.1 of the User Agent to send LDAP login and logoff data to your Version 5.x Defense Centers, you must configure a connection for each agent on each Defense Center where you want the agent to connect. That connection allows the agent to establish a secure connection with the Defense Center, over which it can send the user activity data.

If the agent is configured to exclude specific user names, user activity data for those user names are not reported to the Defense Center. These excluded user names remain in the database, but are not associated with IP addresses.

In addition, if you are planning to implement user access control, you must set up a connection to each Microsoft Active Directory server where you plan to collect data, with user awareness parameters configured.

The maximum number of users you can use in access control depends on your FireSIGHT license. When configuring the Defense Center-LDAP server connection, make sure the total number of users you include is less than your FireSIGHT user license. See Understanding FireSIGHT Host and User License Limits for more information.

User Data Collection Limitations

License: FireSIGHT

The following table describes the limitations of user data collection.

Table 45-1 User Awareness Limitations

Limitation

Description

user control

To perform user control, your organization must use Microsoft Active Directory LDAP servers. The system obtains the users and groups you can use in access control rules from Active Directory, and also ties users to IP addresses with the logins and logoffs reported by User Agents installed on Active Directory servers.

non-Kerberos logins for LDAP connections

Managed devices interpret only Kerberos logins for LDAP connections as LDAP authentications. Managed devices cannot detect encrypted LDAP authentications if they use other protocols, such as SSL or TLS.

On the other hand, User Agents use the security logs on Active Directory servers to collect user login data and have no such limitations.

login detection

If you want to detect logins to an Active Directory server, you must configure the Active Directory server connection with the server IP address. See the User Agent Configuration Guide for more information.

If multiple users are logged into a host using remote sessions, the agent may not detect logins from that host properly. See the User Agent Configuration Guide for more information on how to prevent this.

logoff detection

Logoffs may not be immediately detected. The timestamp associated with a logoff reflects when the agent detected the user was no longer mapped to the host IP address, which may not correspond to the actual time the user logged off of the host.

Logoffs are generated by the agent itself when it detects a user logged out of a host IP address. Logoffs are also generated when the agent detects that the user logged into a host has changed, before the Active Directory server reports that the user has changed.

real-time data retrieval

The Active Directory server must be running Windows Server 2008 or Windows Server 2012.

multiple logins to the same host by different users

The system assumes that only one user is logged into any given host at a time, and that the current user of a host is the last authoritative user login. If only non-authoritative logins have been logged into the host, the last non-authoritative login is considered the current user. If multiple users are logged in through remote sessions, the last user reported by the Active Directory server is the user reported to the Defense Center.

multiple logins to the same host by the same user

The system records the first time that a user logs into a specific host and disregards subsequent logins. If an individual user is the only person who logs into a specific host, the only login that the system records is the original login.

If another user logs into that host, however, the system records the new login. Then, if the original user logs in again, his or her new login is recorded.

Unicode characters

The user interface may not correctly display user names with Unicode characters.

LDAP user accounts in the users database

If you remove or disable an LDAP user on your LDAP servers, or exclude the user name from being reported to the Defense Center, the Defense Center does not remove that user from the users database, and that user continues to count against your licensed limit for user listed in the database. You must manually purge the user from the database.

Note that the user license limit is applied in parallel for access-controlled users; the user count for access-controlled users depends on the number of users retrieved by your LDAP configuration.

AOL Instant Messenger (AIM) login detection

Managed devices can detect AIM logins using the OSCAR protocol only. While most AIM clients use OSCAR, some use TOC2.

Understanding Application Detection

License: FireSIGHT

When the FireSIGHT System analyzes IP traffic, it attempts to identify the commonly used applications on your network. Application awareness is crucial to performing application-based access control.

There are three types of applications that the system detects:

- application protocols such as HTTP and SSH, which represent communications between hosts

- clients such as web browsers and email clients, which represent software running on the host

- web applications such as MPEG video and Facebook, which represent the content or requested URL for HTTP traffic

The system identifies applications in your network traffic either using ASCII or hexadecimal patterns in the packet headers, or the port that the traffic uses. Some application detectors use both port and pattern detection to increase the likelihood of correctly identifying traffic for a particular application. In addition, Secure Socket Layers (SSL) protocol detectors use information from the secured session to identify the application from the session. There are two sources of application detectors in the FireSIGHT System:

- Cisco -provided detectors , which detect web applications, clients, and application protocols

The availability of Cisco-provided detectors for applications (and operating systems, see Understanding Host Data Collection) depend on the version of the FireSIGHT System and the version of the VDB you have installed. Release notes and advisories contain information on new and updated detectors. You can also import individual detectors authored by Professional Services. For a complete list of detected applications, see the Support site.

- user-defined application protocol detectors , which you can create to enhance the system’s application protocol detection capabilities

You can also detect application protocols through implied application protocol detection, which implies the existence of an application protocol based on the detection of a client.

The system characterizes each application that it detects using the criteria described in the following table. The system uses these characteristics to create application filters, or groups of applications. You can use these filters and filters that you create to perform access control, as well as to constrain searches, reports, and dashboard widgets. For more information, see Working with Application Filters.

:

Table 45-2 Application Characteristics

Characteristic

Description

Example

Type

The type of application:

- Application Protocols represent communications between hosts.

- Clients represent software running on a host.

- Web Applications represent the content or requested URL for HTTP traffic.

HTTP and SSH are application protocols. Web browsers and email clients are clients.

MPEG video and Facebook are web applications.

Risk

How likely the application is to be used for purposes that might be against your organization’s security policy. An application’s risk can range from Very Low to Very High.

Peer-to-peer applications tend to have a very high risk.

Business Relevance

The likelihood that the application is used within the context of your organization’s business operations, as opposed to recreationally. An application’s business relevance can range from Very Low to Very High.

Gaming applications tend to have a very low business relevance.

Category

A general classification for the application that describes its most essential function. Each application belongs to at least one category.

Facebook is in the social networking category.

Tag

Additional information about the application. Applications can have any number of tags, including none.

Video streaming web applications often are tagged high bandwidth and displays ads.

To supplement the application data gathered by the system, you can use records generated by NetFlow-enabled devices, Nmap active scans, and the host input feature.

For more information, see:

- Understanding the Application Protocol Detection Process

- Implied Application Protocol Detection from Client Detection

- Special Considerations for Application Protocol Detection: Squid

- Special Considerations: SSL Application Detection

- Special Considerations: Referred Web Applications

- Working with Application Detectors

- Importing Third-Party Discovery Data

- Understanding NetFlow

Understanding the Application Protocol Detection Process

License: FireSIGHT

When the system detects application traffic, it first determines whether the application protocol is running on a port identified by a detector that uses that specific port as its only detection criterion. If the application protocol is running on one of those ports, the system positively identifies the application protocol using the well-known port detector.

Note Because you can create and activate user-defined port-based application protocol detectors on ports used by Cisco-provided detectors, it is possible to override Cisco’s detection capabilities. For example, if your user-defined detector identifies all application protocol traffic on port 22 as the myapplication application protocol, SSH traffic on port 22 will be misidentified as myapplication traffic.

If the application protocol is not running on one of those ports, the system employs a more robust method to identify it based on port and pattern matches. If two detectors both positively identify the traffic, the detector that employs the longer pattern match has precedence. Similarly, detectors with multiple pattern matches have precedence over single pattern matches.

Note that the system identifies only those application protocols running on hosts in your monitored networks, as defined in the network discovery policy. For example, if an internal host accesses an FTP server on a remote site that you are not monitoring, the system does not identify the application protocol as FTP. On the other hand, if a remote or internal host accesses an FTP server on a host you are monitoring, the system can positively identify the application protocol.

An exception occurs if the system can identify the client used in connections between a monitored host accessing a non-monitored server. In that case, the system positively identifies the appropriate application protocol that corresponds with the client in the connection, but does not add the application protocol to the network map. For more information, see Implied Application Protocol Detection from Client Detection. Note that client sessions must include a response from the server for application detection to occur.

The following table outlines how the FireSIGHT System identifies detected application protocols in the Defense Center web interface: the network map, host profiles, event views, and so on.

Table 45-3 FireSIGHT System Identification of Application Protocols

Application

Description

the application protocol name

The Defense Center identifies an application protocol with its name if the application protocol was:

- positively identified by the system

- identified using NetFlow data and there is a port-application protocol correlation in /etc/sf/services

- manually identified using the host input feature

- identified by Nmap or another active source

pending

The Defense Center identifies an application protocol as pending if the system can neither positively nor negatively identify the application.

Most often, the system needs to collect and analyze more connection data (from which applications are identified) before it can identify a pending application.

In the Application Details and Servers tables and in the host profile, the pending status appears only for application protocols where specific application protocol traffic was detected (rather than implied by detected client or web application traffic).

unknown

The Defense Center identifies an application protocol as unknown if the application:

- does not match any of the system’s detectors

- the application protocol was identified using NetFlow data, but there is no port-application protocol correlation in /etc/sf/services

blank

All available detected data has been examined and no application protocol was identified. In the Application Details and Servers tables and in the host profile, the application protocol is left blank for non-HTTP generic client traffic with no detected application protocol.

Implied Application Protocol Detection from Client Detection

License: FireSIGHT

If the system can identify the client used in a connection between a monitored host accessing a non-monitored server, the Defense Center infers that the connection is using the application protocol that corresponds with the client. (Because the system tracks applications only on monitored networks, connection logs usually do not include application protocol information for connections where a monitored host is accessing a non-monitored server.)

There are several consequences of the implied detection of an application protocol from the detection of a client:

- Because the system does not generate a New TCP Port or New UDP Port event for these servers, the server does not appear in the Servers table. In addition, you cannot trigger either discovery event alerts or correlation rules using the detection of these application protocol as a criterion.

- Because the application protocol is not associated with a host, you cannot view its details in host profiles, set its server identity, or use its information in host profile qualifications for traffic profiles or correlation rules. In addition, the system does not associate vulnerabilities with hosts based on this type of detection.

You can, however, trigger correlation events on the application protocol information in a connection. You can also use the application protocol information in connection logs to create connection trackers and traffic profiles.

Host Limits and Discovery Event Logging

License: FireSIGHT

When the system detects a client, server, or web application, it generates a discovery event unless the associated host has already reached its maximum number of clients, servers, or web applications.

Host profiles display up to 16 clients, 100 servers, and 100 web applications per host. See Working with Servers in the Host Profile and Viewing Applications in the Host Profile for more information.

Note that actions dependent on the detection of clients, servers, or web applications are unaffected by this limit. For example, access control rules configured to trigger on a server will still log connection events.

Special Considerations for Application Protocol Detection: Squid

License: FireSIGHT

The system positively identifies Squid server traffic when either:

- the system detects a connection from a host on your monitored network to a Squid server where proxy authentication is enabled, or

- the system detects a connection from a Squid proxy server on your monitored network to a target system (that is, the destination server where the client is requesting information or another resource)

However, the system cannot identify Squid service traffic if:

- a host on your monitored network connects to a Squid server where proxy authentication is disabled, or

- the Squid proxy server is configured to strip Via: header fields from its HTTP responses

Special Considerations: SSL Application Detection

License: FireSIGHT

The FireSIGHT System provides detectors that can use session information from a Secure Socket Layers (SSL) session to identify the application protocol, client application, or web application in the session.

When the system detects an encrypted connection, it marks that connection as either a generic HTTPS connection or as a more specific secure protocol, such as SMTPS, when applicable. When the system detects an SSL session, it adds SSL client to the Client field in connection events for the session. If it identifies a web application for the session, the system generates discovery events for the traffic.

For SSL application traffic, managed devices can also detect the common name from the server certificate and match that against a client or web application from an SSL host pattern. When the system identifies a specific client, it replaces SSL client with the name of the client.

Because the SSL application traffic is encrypted, the system can use only information in the certificate for identification, not application data within the encrypted stream. For this reason, SSL host patterns can sometimes only identify the company that authored the application, so SSL applications produced by the same company may have the same identification.

In some instances, such as when an HTTPS session is launched from within an HTTP session, managed devices detect the server name from the client certificate in a client-side packet.

To enable SSL application identification, you must create access control rules that monitor responder traffic. Those rules must have either an application condition for the SSL application or URL conditions using the URL from the SSL certificate. For network discovery, the responder IP address does not have to be in the networks to monitor in the network discovery policy; the access control policy configuration determines whether the traffic is identified. You can filter by the SSL protocol tag, in the application detectors list or when adding application conditions in access control rules, to identify detectors for SSL applications.

Special Considerations: Referred Web Applications

Web servers sometimes refer traffic to other websites, which are often advertisement servers. To help you better understand the context for referred traffic occurring on your network, the system lists the web application that referred the traffic in the Web Application field in events for the referred session. The VDB contains a list of known referred sites. When the system detects traffic from one of those sites, the referring site is stored with the event for that traffic. For example, if an advertisement accessed via Facebook is actually hosted on Advertising.com, the detected Advertising.com traffic is associated with the Facebook web application. The system can also detect referring URLs in HTTP traffic, such as when a website provides a simple link to another site; in this case, the referring URL appears in the HTTP Referrer event field.

In events, if a referring application exists, it is listed as the web application for the traffic, while the URL is that for the referred site. In the example above, the web application for the connection event for that traffic would be Facebook, but the URL would be Advertising.com. If no referring web application is detected, if the host refers to itself, or if there is a chain of referrals, a referred application may appear as the web application in the event. In the dashboard, connection and byte counts for web applications include sessions where the web application is associated with traffic referred by that application.

Note that if you create a rule to act specifically on referred traffic, you should add a condition for the referred application, rather than the referring application. To block Advertising.com traffic referred from Facebook, for example, add an application condition to your access control rule for the Advertising.com application.

Importing Third-Party Discovery Data

License: FireSIGHT

You can use Nmap active scans to add information about operating systems, applications, and vulnerabilities, supplementing the data gathered by the system. For more information on Nmap scanning and scan results, see Understanding Nmap Scans.

You can also use the host input feature to supplement the information that the system gathers from monitoring network traffic, either by configuring a third-party application to interact with the FireSIGHT System via an API, or by manually adding data. You can create product, vulnerability, and fix mappings to map third-party data to Cisco definitions, enabling impact correlation for operating systems and servers. For more information on the host input feature and mapping third-party data, see the FireSIGHT System Host Input API Guide and Importing Host Input Data.

The system reconciles the collected data about operating system and server identities and determines each identity based on fingerprint source priority values, identity conflict resolution settings, and time of collection.

You can also configure your network map to use data from NetFlow-enabled devices to enhance your network map and event tables. For more information, see Understanding NetFlow.

Uses for Discovery Data

License: FireSIGHT

Logging discovery data allows you to take advantage of many features in the FireSIGHT System, including:

- viewing the network map, which is a detailed representation of your network assets and topology that you can view by grouping hosts and network devices, host attributes, application protocols, or vulnerabilities; see Using the Network Map

- viewing host profiles, which are complete views of all the information available for your detected hosts; see Using Host Profiles

- viewing dashboards, which (among other capabilities) can provide you with an at-a-glance view of your network assets and user activity; see Using Dashboards

- viewing detailed information on the discovery events and user activity logged by the system; see Working with Discovery Events

- creating reports based on discovery data; see Working with Reports

- performing application and user control, that is, writing access control rules using application and user conditions; see Controlling Application Traffic and Adding a User Condition to an Access Control Rule

- associating hosts and any servers or clients they are running with the exploits to which they are susceptible, which allows you to identify and mitigate vulnerabilities, evaluate the impact that intrusion events have on your network, and tune intrusion rule states so that they provide maximum protection for your network assets; see Working with Vulnerabilities in the Host Profile, Using Impact Levels to Evaluate Events, Understanding Indications of Compromise, and Tailoring Intrusion Protection to Your Network Assets

- alerting you via email, SNMP trap, or syslog when the system generates either an intrusion event with a specific impact flag, or a specific type of discovery event; see Configuring External Alerting

- monitor your organization’s compliance with a white list of allowed operating systems, clients, application protocols, and protocols; see Using the FireSIGHT System as a Compliance Tool

- creating correlation policies with rules that trigger and generate correlation events when the system generates discovery events or detects user activity; see Configuring Correlation Policies and Rules

- if you log NetFlow connections, using that connection data; see Logging Connections to the Defense Center or External Server

Understanding NetFlow

License: FireSIGHT

NetFlow is an embedded instrumentation within Cisco IOS Software that characterizes network operation. Standardized through the RFC process, NetFlow is available not only on Cisco networking devices, but can also be embedded in Juniper, FreeBSD, and OpenBSD devices.

NetFlow-enabled devices are widely used to capture and export data about the traffic that passes through those devices. NetFlow-enabled devices have a database called the NetFlow cache that stores records of the flows that pass through the devices. A flow, called a connection in the FireSIGHT System, is a sequence of packets that represents a session between a source and destination host, using specific ports, protocol, and application protocol.

For the networks you specify, FireSIGHT System managed devices detect the records exported by NetFlow-enabled devices, generate connection events based on the data in those records, and finally send those events to the Defense Center to be logged in the database. You can also configure the system to add host and application protocol information to the database, based on the information in NetFlow connections.

You can use this discovery and connection data to supplement the data gathered directly by your managed devices. This is especially useful if you have NetFlow-enabled devices deployed on networks that your managed devices cannot monitor.

You configure NetFlow data collection, including connection logging, using rules in the network discovery policy. Contrast this with connection logging for connections detected by FireSIGHT System managed devices, which you configure per access control rule, as described in Logging Connections Based on Access Control Handling. Because NetFlow data collection is linked to networks rather than access control rules, you do not have as much granular control over which connections you want to log, Also, the system automatically saves all NetFlow-based connection events to the Defense Center connection event database; you cannot send them to the system log or an SNMP trap server.

For more information, see:

- Differences Between NetFlow and FireSIGHT Data

- Preparing to Analyze NetFlow Data

- Uses for Discovery Data

- Logging Connections to the Defense Center or External Server

Differences Between NetFlow and FireSIGHT Data

License: FireSIGHT

With one exception (TCP flags), the information available in NetFlow records is more limited than the information generated by monitoring network traffic using managed devices. Because the system cannot directly analyze the traffic represented by NetFlow data, when the system processes NetFlow records it uses various methods to convert that data into connection logs as well as into host and application protocol records.

There are several differences between converted NetFlow data and the discovery and connection data gathered directly by your managed devices. You should keep the differences in mind when performing analysis that requires:

- statistics on the number of detected connections

- operating system and other host-related information (including vulnerabilities)

- application data, including client information, web application information, and vendor and version server information

- knowing which host in a connection is the initiator and which is the responder

Tip For each field in a connection event, Table 39-1 indicates the available data depending on whether the connection was detected directly by FireSIGHT System managed devices, or if the connection event is based on NetFlow data.

Number of Connection Events Generated Per Monitored Session

For connections detected directly by managed devices, depending on the access control rule action, you can log a bidirectional connection event at the beginning or end of a connection, or both.

However, because NetFlow-enabled devices export unidirectional connection data, the system always generates at least two connection events for each connection detected by NetFlow-enabled devices, depending on how you configured the devices. This also means that a summary’s connection count is incremented by two for every connection based on NetFlow data, providing an inflated count of the number of connections that are actually occurring on your network.

Note that if you configure your NetFlow-enabled devices to output records only when the connection ends, the system generates two connection events for that session. On the other hand, if you configure your NetFlow-enabled devices to output records at a fixed interval even if a connection is still ongoing, the system generates a connection event for each record exported by the device. For example, if you configure your NetFlow-enabled devices to output records for long-running connections every five minutes, and a particular connection lasts twelve minutes, the system generates six connection events for that session:

- one pair of events for the first five minutes

- one pair for the second five minutes

- a final pair when the connection is terminated

For this reason. Cisco strongly recommends that you configure your NetFlow-enabled devices to output records only when monitored sessions close.

Host and Operating System Data

Although you can configure the network discovery policy to add hosts to the network map based on NetFlow records, the host profile does not include any operating system or NetBIOS data for the hosts involved in the connection, nor can the system identify if the hosts are network devices (bridges, routers, NAT devices, or load balancers). You can, however, manually set a host’s operating system identity using the host input feature.

Application Data

For connections detected directly by managed devices, the system can identify application protocols, clients, and web applications by examining the packets in the connection.

When the system processes NetFlow records, the system uses a port correlation in /etc/sf/services to extrapolate application protocol identity. However, there is no vendor or version information for those application protocols, nor do connection logs contain information on client or web applications used in the session. You can, however, manually provide this information using the host input feature.

Note that a simple port correlation means that application protocols running on non-standard ports may be unidentified or misidentified. Additionally, if no correlation exists, the system marks the application protocol as unknown in connection logs.

Vulnerability Mappings

The FireSIGHT System cannot determine which vulnerabilities might affect hosts added to the network map based on NetFlow records, unless you use the host input feature to manually set either a host’s operating system identity or an application protocol identity. Note that because there is no client information in NetFlow connections, you cannot associate client vulnerabilities with NetFlow hosts.

Initiator and Responder Information in Connections

For connections detected directly by managed devices, the system can identify which host is the initiator, or source, and which is the responder, or destination. However, NetFlow data does not contain initiator or responder information.

When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known:

- If both or neither port being used is a well-known port, the system considers the host using the lower-number port to be the responder.

- If only one of the hosts is using a well-known port, the system considers that host to be the responder.

For this purpose, a well-known port is any port that is either numbered from 1 to 1023, or that contains application protocol information in /etc/sf/services on the managed device.

Preparing to Analyze NetFlow Data

License: FireSIGHT

Before you configure the FireSIGHT System to analyze NetFlow data, you must enable the NetFlow feature on the routers or other NetFlow-enabled devices you plan to use, and configure the devices to export NetFlow version 5 data to a destination network where the sensing interface of a managed device is connected.

Note that the system can parse both NetFlow version 5 and NetFlow version 9 records. Your NetFlow-enabled devices must use one of those versions if you want to use them with your FireSIGHT System deployment. In addition, the system requires that specific fields be in the templates and records that your NetFlow-enabled devices broadcast. If your NetFlow-enabled devices are using version 9, which you can customize, you must make sure that the templates and records that the devices broadcast contain the following fields, in any order:

- IN_BYTES (1)

- IN_PKTS (2)

- PROTOCOL (4)

- TCP_FLAGS (6)

- L4_SRC_PORT (7)

- IPV4_SRC_ADDR (8)

- L4_DST_PORT (11)

- IPV4_DST_ADDR (12)

- LAST_SWITCHED (21)

- FIRST_SWITCHED (22)

- IPV6_SRC_ADDR (27)

- IPV6_DST_ADDR (28)

Because the FireSIGHT System uses managed devices to analyze NetFlow data, your deployment must include at least one managed device that can monitor your NetFlow-enabled devices. At least one sensing interface on that managed device must be connected to a network where it can collect the data that your NetFlow-enabled devices export. Because the sensing interfaces on managed devices do not usually have IP addresses, the system does not support the direct collection of NetFlow records.

In addition, Cisco strongly recommends that you configure your NetFlow-enabled devices to output records only when monitored sessions close. If you configure your NetFlow-enabled devices to output records at fixed intervals, analyzing the connection data derived from the NetFlow records may be more complicated; see Number of Connection Events Generated Per Monitored Session.

Finally, note that the Sampled NetFlow feature available on some NetFlow-enabled devices collects NetFlow statistics on only a subset of packets that pass through the devices. Although enabling this feature can improve CPU utilization on the NetFlow-enabled device, it may affect the data you are collecting for analysis by the system.

Understanding Indications of Compromise

License: FireSIGHT

As a part of network discovery, the FireSIGHT System’s Data Correlator can correlate various types of data (intrusion events, Security Intelligence, connection events, and malware events) associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. These correlations are known as indications of compromise (IOC). You activate this feature by enabling it and any of many Cisco-predefined IOC rules in the discovery policy editor. When the feature is enabled, you can also edit rule states for individual hosts from that host’s host profile. Each IOC rule corresponds to one specific IOC tag, which is associated with a host.

In addition to the Data Correlator, Cisco’s endpoint-based Collective Security Intelligence Cloud data can also generate IOC tags from IOC rules. Because this data examines activity on a host itself — such as actions taken by or on individual programs — it can provide insights into possible threats that network-only data cannot. FireAMP IOC data from endpoints is transmitted via the Cisco cloud connection.

). Event views for events that can trigger IOC tags indicate whether an event triggered an IOC.

Understanding Indications of Compromise Types

License: FireSIGHT

There are many indications of compromise (IOC) rule and tag types. All are Cisco-predefined, and one IOC rule corresponds to one IOC tag. Because IOC rules trigger based on data provided by other features of the FireSIGHT System (and, for some events, the Cisco cloud), those features must be available and active for IOC rules to set IOC tags. When Cisco develops new endpoint-based malware event IOC types, the system automatically downloads them via the cloud and begins to use them. The lists below detail IOC rule types, the features with which they are associated, and any additional licensing requirements (beyond the FireSIGHT license required for network discovery):

- Endpoint-Based Malware Event IOC Types

- Intrusion Event IOC Types

- Security Intelligence Event IOC Types

Endpoint-Based Malware Event IOC Types

License: FireSIGHT

The following list contains examples of IOC types that are associated with endpoint-based malware events, which require a subscription to the Cisco cloud. In addition to the IOC types listed below, Cisco periodically develops new types, which your system downloads and implements automatically via your connection to the cloud.

For more information on configuring endpoint-based malware protection, see Working with Cloud Connections for FireAMP and Network-Based AMP vs Endpoint-Based FireAMP.

- Adobe Reader Compromise — Adobe Reader launched shell

- Adobe Reader Compromise — PDF Compromise Detected by FireAMP

- CnC Connected — Suspected Botnet Detected by FireAMP

- Dropper Infection — Dropper Infection Detected by FireAMP

- Excel Compromise — Excel Compromise Detected by FireAMP

- Excel Compromise — Excel launched shell

- Generic IOC Detected by FireAMP

- Java Compromise — Java Compromise Detected by FireAMP

- Java Compromise — Java launched shell

- Malware Detected — Threat Detected by FireAMP - Not Executed

- Malware Detected — Threat Detected in File Transfer

- Malware Executed — Threat Detected by FireAMP - Executed

- Microsoft Calculator Compromise — Microsoft Calculator Compromise Detected by FireAMP

- Microsoft Notepad Compromise — Microsoft Calculator Compromise Detected by FireAMP

- PowerPoint Compromise — PowerPoint Compromise Detected by FireAMP

- PowerPoint Compromise — PowerPoint launched shell

- QuickTime Compromise — QuickTime Compromise Detected by FireAMP

- QuickTime Compromise — QuickTime launched shell

- Word Compromise — Word Compromise Detected by FireAMP

- Word Compromise — Word launched shell

Intrusion Event IOC Types

License: FireSIGHT+Protection

The following IOC types are associated with intrusion events, which require a Protection license. For more information on viewing intrusion events and configuring intrusion detection and protection, see Controlling Traffic Using Intrusion and File Policies and Viewing Intrusion Events.

- CnC Connected — Intrusion Event - malware-backdoor

- CnC Connected — Intrusion Event - malware-cnc

- Exploit Kit — Intrusion Event - exploit-kit

- Impact 1 Attack — Impact 1 Intrusion Event - attempted-admin

- Impact 1 Attack — Impact 1 Intrusion Event - attempted-user

- Impact 1 Attack — Impact 1 Intrusion Event - successful-admin

- Impact 1 Attack — Impact 1 Intrusion Event - successful-user

- Impact 1 Attack — Impact 1 Intrusion Event - web-application-attack

- Impact 2 Attack — Impact 2 Intrusion Event - attempted-admin

- Impact 2 Attack — Impact 2 Intrusion Event - attempted-user

- Impact 2 Attack — Impact 2 Intrusion Event - successful-admin

- Impact 2 Attack — Impact 2 Intrusion Event - successful-user

- Impact 2 Attack — Impact 2 Intrusion Event - web-application-attack

Security Intelligence Event IOC Types

License: FireSIGHT+Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

The CnC Connected — Security Intelligence Event - CnC type is associated with Security Intelligence events, a type of connection event. The Security Intelligence feature requires a Protection license. For more information on configuring Security Intelligence and viewing Security Intelligence events, see Blacklisting Using Security Intelligence IP Address Reputation and Viewing Connection and Security Intelligence Data.

Viewing and Editing Indications of Compromise Data

License: FireSIGHT

Outside the network discovery policy itself, you can view and edit indications of compromise (IOC) data in several other parts of the FireSIGHT System web interface:

- In the dashboard, the Threats tab of the Summary Dashboard displays, by default, IOC tags by host and new IOC rules triggered over time. The Custom Analysis widget offers presets based on IOC data. For information, see Using Dashboards and Configuring the Custom Analysis Widget.

- The Indications of Compromise section of the Context Explorer displays graphs of hosts by IOC category and IOC categories by host. For information, see Understanding the Indications of Compromise Section.

- Event views for discovery (IOC), connection, Security Intelligence, intrusion, and malware events display (in the IOC column) whether an event triggered an IOC rule. Endpoint-based malware events that trigger IOC rules have the event type FireAMP IOC and appear with an event subtype that specifies the compromise. You can write compliance rules against all IOC data that appears in the event viewer. For more information, see the following sections:

- Viewing Connection and Security Intelligence Data

- Viewing Intrusion Events

- Working with Malware Events

- Working with Indications of Compromise

- Configuring Correlation Policies and Rules

- The Indications of Compromise tab of the network map lists hosts on your monitored network, grouped by IOC tag. For information, see Working with the Indications of Compromise Network Map.

- In the host profile view for a potentially compromised host, you can view all IOC tags associated with that host, resolve any or all of its IOC tags, and configure IOC rule states. For information, see Working with Indications of Compromise in the Host Profile.

Creating a Network Discovery Policy

License: FireSIGHT

The network discovery policy on the Defense Center controls how the system collects data on your organization’s network assets and which network segments and ports are monitored.

Discovery rules within the policy specify what networks and ports the FireSIGHT System monitors to generate discovery data based on network data in traffic, and what zones the policy is applied to. Within a rule, you can configure whether hosts, applications, and users are discovered. You can create rules to exclude networks and zones from discovery. When you create a rule for discovery from a NetFlow device, you can choose to just log connections.

The network discovery policy has a a single default rule in place, configured to discover applications in any IPv4 traffic on the 0.0.0.0/0 network. Note that you must have applied an access control policy to the targeted device before you can apply a network discovery policy. The rule does not exclude any networks, zones, or ports, host and user discovery is not configured, and a NetFlow device is not configured. Note that the policy is applied to any managed devices by default when they are registered to the Defense Center. To begin collecting host or data, you must add or modify discovery rules and reapply the policy to a device.

Remember that the access control policy defines the traffic that you permit, and therefore the traffic you can monitor with network discovery. Note that this means if you block certain traffic using access control, the system cannot examine that traffic for host, user, or application activity. For example, if you block access to social networking applications in the access control policy, the system will not provide you with any discovery data on those applications.

If you want to adjust the scope of network discovery, you can create additional discovery rules and modify or remove the default rule. You can configure discovery of data from NetFlow devices and can restrict the protocols for traffic where user data is discovered on your network.

If you want to use the FireSIGHT System to perform intrusion detection and prevention but do not need to take advantage of discovery data, you can optimize performance by disabling new discovery. First, make sure that your applied access control policies do not contain rules with user, application, or URL conditions. Then, remove all rules from your network discovery policy and apply it to your managed devices. For more information on configuring access control rules, see Tuning Traffic Flow Using Access Control Rules.

If you enable user discovery in your discovery rules, you can detect users through user login activity in traffic over a set of application protocols. You can disable discovery in particular protocols across all rules if needed. Disabling some protocols can help avoid reaching the user limit associated with your FireSIGHT license, reserving available user count for users from the other protocols.

Advanced network discovery settings allow you to manage what data is logged, how discovery data is stored, what indications of compromise (IOC) rules are active, what vulnerability mappings are used for impact assessment, and what happens when sources offer conflicting discovery data. You can also add NetFlow devices and sources for host input.

For more information, see:

- Working with Discovery Rules

- Restricting User Logging

- Configuring Advanced Network Discovery Options

- Applying the Network Discovery Policy

Working with Discovery Rules

License: FireSIGHT

Discovery rules allow you to tailor the information discovered for your network map to include only the specific data you want. Rules in your network discovery policy are evaluated sequentially. Note that while you can create rules with overlapping monitoring criteria, doing so may affect your system performance.

When you exclude a host or a network from monitoring, the host or network does not appear in the network map and no events are reported for it. Cisco recommends that you exclude load balancers (or specific ports on load balancers) and NAT devices from monitoring. These devices may create excessive and misleading events, filling the database and overloading the Defense Center. For example, a monitored NAT device might exhibit multiple updates of its operating system in a short period of time. If you know the IP addresses of your load balancers and NAT devices, you can exclude them from monitoring.

Tip The system can identify many load balancers and NAT devices by examining your network traffic. To determine which hosts on your network are load balancers and NAT devices, apply your network discovery policy, wait for the system to populate the network map, then perform a search of hosts constraining on host type.

In addition, if you need to create a custom server fingerprint, you should temporarily exclude from monitoring the IP address that you are using to communicate with the host you are fingerprinting. Otherwise, the network map and discovery event views will be cluttered with inaccurate information about the host represented by that IP address. After you create the fingerprint, you can configure your policy to monitor that IP address again. For more information, see Fingerprinting Servers.

Cisco also recommends that you not monitor the same network segment with NetFlow-enabled devices and FireSIGHT System managed devices. Although ideally you should configure your network discovery policy with non-overlapping rules, the system does drop duplicate connection logs generated by managed devices. Note that you cannot drop duplicate connection logs for connections detected by both a managed device and a NetFlow-enabled device.

For more information, see the following sections:

- Understanding Device Selection

- Understanding Actions and Discovered Assets

- Understanding Monitored Networks

- Understanding Zones in Network Discovery Policies

- Understanding Port Exclusions

- Adding a Discovery Rule

- Creating Network Objects

- Creating Port Objects

Understanding Device Selection

License: FireSIGHT

If you select a NetFlow device in a discovery rule, the rule is limited to discovery of NetFlow data for the specified networks. Select the NetFlow device before you configure other aspects of rule behavior, as the available rule actions change when you select a NetFlow device. In addition, you cannot configure port exclusions for NetFlow traffic.

Before you can select a NetFlow device in a network discovery rule, you must configure a connection to the NetFlow device in the network discovery advanced settings. For more information, see Adding NetFlow-Enabled Devices.

Understanding Actions and Discovered Assets

License: FireSIGHT

When you configure a discovery rule, you must select an action for the rule. The action determines what assets are discovered or excluded when the system processes the rule. However, note that the affect of a rule action depends on whether you are using the rule to discover data from a managed device or from a NetFlow-enabled device.

Note that if you create a network discovery policy without any rules that discover hosts or users, applying the policy disables new discovery for the appliance. To optimize performance when using managed devices only for intrusion prevention, remove all discovery rules from your policy and apply it to the active devices.

The following table describes what assets are discovered by rules with the specified action settings in those two scenarios.

Table 45-4 Discovery Rule Actions

Action

Managed Device

NetFlow

Exclude

Excludes the specified network from monitoring. If the source or destination host for a connection is excluded from discovery, the connection is recorded but discovery events are not created for excluded hosts.

Discover: Hosts

Adds hosts to the network map based on discovery events. (Optional, unless user discovery is enabled, then required.)

Adds hosts to the network map based on NetFlow records. (Required)

Discover: Applications

Adds applications to the network map based on application detectors. Note that you cannot discover hosts or users in a rule without also discovering applications. (Required)

Adds application protocols to the network map based on NetFlow records and the port-application protocol correlation in

/etc/sf/services. (Optional)

Discover: Users

Adds users to the users table and logs user activity based on activity detected in traffic matching the user protocols configured in the network discovery policy. (Optional)

n/a

Log NetFlow Connections

n/a

Logs NetFlow connections only. Does not discover hosts or applications.

Understanding Monitored Networks

License: FireSIGHT

A discovery rule causes discovery of monitored assets only in traffic to and from hosts in the specified networks. For a discovery rule, discovery occurs for connections that have at least one IP address within the networks specified, with events generated only for IP addresses within the networks to monitor. The default discovery rule discovers applications only on the 0.0.0.0/0 and ::/0 networks.

For rules with a specified NetFlow device and the Log Network Connections option enabled, connections to and from IP addresses in the specified networks are also logged. Note that network discovery rules provide the only way to log NetFlow network connections.

You can also use network object or object groups to specify the networks to monitor. If you modify a network object used in the network discovery policy, you must reapply the policy for those changes to take effect for discovery.

Understanding Zones in Network Discovery Policies

License: FireSIGHT

For performance reasons, you should configure each discovery rule so that the zones in the rule include the sensing interfaces on your managed devices that are physically connected to the networks-to-monitor in the rule.

Unfortunately, you may not always be kept informed of network configuration changes. A network administrator may modify a network configuration through routing or host changes without informing you, which may make it challenging to stay on top of proper network discovery policy configurations. If you do not know how the sensing interfaces on your managed devices are physically connected to your network, leave the zone configuration as the default, which is to apply the discovery rule to all zones in your deployment. (If no zones are excluded, the discovery policy is applied to all zones.)

Understanding Port Exclusions

License: FireSIGHT

Just as you can exclude hosts from monitoring (see Understanding Actions and Discovered Assets), you can exclude specific ports from monitoring.

For example, load balancers can report multiple applications on the same port in a short period of time. You can configure your network discovery policy so that it excludes that port from monitoring, such as excluding port 80 on a load balancer that handles a web farm.

As another scenario, your organization may use a custom client that uses a specific range of ports. If the traffic from this client generates excessive and misleading events, you can exclude those ports from monitoring. Similarly, you may decide that you do not want to monitor DNS traffic. In that case, you could configure your policy so that it does not monitor port 53.

When adding ports to exclude, you can decide whether to use a reusable port object from the Available Ports list, add ports directly to the source or destination exclusion lists, or create a new reusable port and then move it into the exclusion lists.

Note that you cannot configure NetFlow-enabled devices to exclude ports from monitoring.

Adding a Discovery Rule

License: FireSIGHT

You can configure discovery rules to tailor the discovery of host and application data to your needs. Note that when you modify an object referenced in a rule, you must reapply the network discovery policy for those changes to take effect.

To add a discovery rule:

Access: Admin/Discovery Admin

Step 1 Check your access control policies to ensure that you are logging connections as needed for the traffic where you want to discover network data.

For more information, see Logging Connections Based on Access Control Handling. To discover the most data, log at the end of the connection for traffic you want to discover.

Step 2 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 3 Click Add Rule.

The Add Rule pop-up window appears.

Step 4 You have two options:

- If you plan to use the rule to monitor NetFlow traffic, within the Add Rule pop-up window, click NetFlow Device .

The NetFlow Device page appears.

Note that the NetFlow page is available only if you have added a NetFlow device to the discovery policy. For more information, see Adding NetFlow-Enabled Devices.

- If you plan to use the rule to monitor managed devices, skip to step 6 .

For more information, see Differences Between NetFlow and FireSIGHT Data and Understanding Device Selection

Step 5 Select the IP address for the NetFlow device you want to use from the drop-down list.

Step 6 Set the action for the rule:

- To exclude all traffic that matches the rule from network discovery, select Exclude . Note that the Port Exclusions tab is disabled when you select this rule action.

- To discover the selected types of data in traffic that matches the rule, select Discovery and select or clear the appropriate data type check boxes.

If monitoring managed device traffic, application logging is required. If monitoring users, host logging is required. If monitoring NetFlow traffic, note that you cannot log users and that logging applications is optional.

- If monitoring NetFlow traffic, to use the rule to log connections in NetFlow traffic, select Log NetFlow Connections . Note that this option only appears after you have selected a NetFlow device in the rule.

Note The system detects connections in NetFlow traffic based on network discovery policy settings. Connection logging in managed device traffic is configured in the access control policy. For more information, see Logging Connections in Network Traffic.

For more information on rule actions and discovery of assets, see Understanding Actions and Discovered Assets

Step 7 Every discovery rule must include at least one network. Optionally, to restrict the rule action to specific networks, click the Networks tab, select a network from the Available Networks list, and click Add, or type the network below the Networks list and click Add.

For information on network monitoring, see Understanding Monitored Networks. For information on adding network objects to the Available Networks list, see Creating Network Objects. Note that If you modify a network object used in the network discovery policy, you must reapply the policy for those changes to take effect for discovery.

Step 8 Optionally, to restrict the rule actions to traffic in specific zones, click Zones, select a zone or zones from the Available Zones list, and click Add.

For information on selecting zones for monitoring, see Understanding Zones in Network Discovery Policies.

Step 9 To exclude ports from monitoring, click Port Exclusions.

The Port Exclusions page appears.

Step 10 To exclude specific source ports from monitoring, you have two options:

- Select a port or ports from the Available Ports list and click Add to Source .

- To exclude traffic from a specific source port without adding a port object, under the Selected Source Ports list, select the appropriate protocol from the Protocol drop-down list, type a port number from 1 to 65535 into the Port field, and click Add .

For information on excluding ports from monitoring, see Understanding Port Exclusions. For information on adding port objects to the Available Ports list, see Creating Port Objects. Note that if you modify a port object used in the network discovery policy, you must reapply the policy for those changes to take effect for discovery.

Step 11 To exclude specific destination ports from monitoring, you have two options:

- Select a port or ports from the Available Ports list and click Add to Destination .

- To exclude traffic from a specific destination port without adding a port object, under the Selected Destination Ports list, select the appropriate protocol from the Protocol drop-down list, type a port number from 1 to 65535 into the Port field, and click Add .

Step 12 If you are finished editing the rule, click Save to return to the discovery policy rule list.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Creating Network Objects

License: FireSIGHT

The list of available networks that appears in a discovery rule contains reusable network object and groups that can be used anywhere in the FireSIGHT System. You can add new network objects to the list. Note that when you modify an object referenced in a rule, you must reapply the network discovery policy for those changes to take effect.

To create a new network object:

Admin/Discovery Admin

Step 1 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 2 Click Add Rule.

The Add Rule pop-up window appears.

).

The Network Objects pop-up window appears.

Step 4 Type a Name for the network object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 5 For each IP address, CIDR block, and prefix length you want to add to the network object, type its value and click Add.

Step 6 Click Save to add the network object to the Available Networks list.

Creating Port Objects

License: FireSIGHT

The list of available ports that appears in a discovery rule contains reusable port objects and groups that can be used anywhere in the FireSIGHT System. You can add new port objects to the list. Note that when you modify an object referenced in a rule, you must reapply the network discovery policy for those changes to take effect.

To create a new port object:

Admin/Discovery Admin

Step 1 Click Port Exclusions.

The Port Exclusions page appears.

).

The Port Objects pop-up window appears.

Step 3 Supply a Name for the port object. You can use any printable standard ASCII characters except a pipe (|) or curly braces ({}).

Step 4 In the Protocol field, specify the protocol of the traffic you want to exclude.

Select TCP, UDP, or Other and choose an option from the drop-down list to select a protocol or All.

Step 5 In the Port(s) field, enter the ports you want to exclude from monitoring.

You can specify a single port, a range of ports using the dash (-), or a comma-separated list of ports and port ranges. Allowed port values are from 1 to 65535.

Step 6 Click Save to add the port to the Available Ports list.

Restricting User Logging

License: FireSIGHT

When you apply a network discovery policy with rules that discover users, users are discovered in traffic that uses the AIM, IMAP, LDAP, Oracle, POP3, SMTP, FTP, HTTP, MDNS, and SIP protocols. These users are added to the users table, accessible through the Analysis menu. You can restrict the protocols where user activity is discovered to reduce the total number of detected users so you can focus on users likely to provide the most complete user information.

The total number of detected users the Defense Center can store depends on your FireSIGHT license. After you reach the licensed limit, in most cases the system stops adding new users to the database. To add new users, you must either manually delete old or inactive users from the database, or purge all users from the database. Restricting protocol detection helps minimize user name clutter and preserve FireSIGHT user licenses.

For example, obtaining user names through protocols such as AIM, POP3, and IMAP may introduce user names not relevant to your organization due to network access from contractors, visitors, and other guests.

As another example, AIM, Oracle, and SIP logins may create extraneous user records. This occurs because these login types are not associated with any of the user metadata that the system obtains from an LDAP server, nor are they associated with any of the information contained in the other types of login that your managed devices detect. Therefore, the Defense Center cannot correlate these users with other types of users.

Keep in mind that only managed devices can detect non-LDAP user logins. If you are using only User Agents installed on Microsoft Active Directory servers to detect user activity, restricting non-LDAP logins has no effect. Also, you cannot restrict SMTP logging. This is because users are not added to the database based on SMTP logins; although the system detects SMTP logins, the logins are not recorded unless there is already a user with a matching email address in the database.

You can choose to record failed login attempts for failed user logins detected in LDAP, POP3, FTP, or IMAP traffic. A failed login attempt does not add a new user to the list of users in the database. Note that the User Agent does not report failed login activity. The user activity type for detected failed login activity is Failed User Login.

Note that the system cannot distinguish between failed and successful HTTP logins. To see HTTP user information, you must enable Capture Failed Login Attempts.

To restrict the protocols where user logins are detected:

Admin/Discovery Admin

Step 1 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 2 Click User.

The User page appears.

Step 3 Select check boxes for protocols where you want to detect logins or clear check boxes for protocols where you do not want to detect logins.

Step 4 Optionally, to record failed login attempts detected in LDAP, POP3, FTP, or IMAP traffic, or to capture user information for HTTP logins, enable Capture Failed Login Attempts.

Step 5 Click Save to save the network policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Configuring Advanced Network Discovery Options

License: FireSIGHT

The Advanced tab of the network discovery policy allows you to configure policy-wide settings for what events are detected, how long discovery data is retained and how often it is updated, what vulnerability mappings are used for impact correlation, and how operating system and server identity conflicts are resolved. In addition, you can add host input sources and NetFlow-enabled devices to allow import of data from other sources.

Note that the database event limits for discovery and user activity events are set in the system policy. For more information, see Configuring Database Event Limits.

To configure advanced settings:

Admin/Discovery Admin

Step 1 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 2 Click Advanced.

The Advanced page appears.

Step 3 Edit advanced settings as needed:

- Configuring General Settings

- Configuring Identity Conflict Resolution

- Enabling Vulnerability Impact Assessment Mappings

- Setting Indications of Compromise Rules

- Adding NetFlow-Enabled Devices

- Configuring Data Storage

- Configuring Discovery Event Logging

- Adding Identity Sources

Step 4 When you finish configuring settings, click Save to save the policy.

Step 5 When the policy is complete and saved, apply the policy to put the updated settings into effect. For more information, see Applying the Network Discovery Policy.

Configuring General Settings

License: FireSIGHT

The general settings control how often the system updates information in the network map and whether server banners are captured during discovery.

Capture Banners

Select this check box if you want the system to store header information from network traffic that advertises server vendors and versions (“banners”). This information can provide additional context to the information gathered. You can access server banners collected for hosts by accessing server details.

Update Interval

The interval at which the system updates information (such as when any of a host’s IP addresses was last seen, when an application was used, or the number of hits for an application). The default setting is 3600 seconds (1 hour).

Note that setting a lower interval for update timeouts provides more accurate information in the host display, but generates more network events.

To update general settings:

Admin/Discovery Admin

.

The General Settings pop-up window appears.

Step 2 Update the settings as needed.

Step 3 Click Save to save the general settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Configuring Identity Conflict Resolution

License: FireSIGHT

The system matches fingerprints for operating systems and servers against patterns in traffic to determine what operating system and which applications are running on a particular host. To provide the most reliable operating system and server identity information, the system collates fingerprint information from several sources.

The system uses all passive data to derive operating system identities and assign a confidence value. For more information on current identities and how the system selects the current identity, see Enhancing Your Network Map.

By default, unless there is an identity conflict, identity data added by a scanner or third-party application overrides identity data detected by the FireSIGHT System. You can use the Identity Sources settings to rank scanner and third-party application fingerprint sources by priority. The system retains one identity for each source, but only data from the highest priority third-party application or scanner source is used as the current identity. Note, however, that user input data overrides scanner and third-party application data regardless of priority.

An identity conflict occurs when the system detects an identity that conflicts with an existing identity that came from either the active scanner or third-party application sources listed in the Identity Sources settings or from a FireSIGHT System user. By default, identity conflicts are not automatically resolved and you must resolve them through the host profile or by rescanning the host or re-adding new identity data to override the passive identity. However, you can set your system to always automatically resolve the conflict by keeping the passive identity or to always resolve it by keeping the active identity.

Generate Identity Conflict Event

Enable this option to generate an event when an identity conflict occurs on a host in the network map.

Automatically Resolve Conflicts

You have the following options:

- To force manual conflict resolution of identity conflicts, select Disabled from the Automatically Resolve Conflicts drop-down list.

- To use the passive fingerprint when an identity conflict occurs, select Identity from the Automatically Resolve Conflicts drop-down list.

- To use the current identity from the highest priority active source when an identity conflict occurs, select Keep Active from the Automatically Resolve Conflicts drop-down list.

To update identity conflict resolution settings:

Admin/Discovery Admin

.

The Edit Identity Conflict Settings pop-up window appears.

Step 2 Update the settings as needed.

Step 3 Click Save to save the identity conflict settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Enabling Vulnerability Impact Assessment Mappings

License: FireSIGHT

You can configure how the FireSIGHT System performs impact correlation with intrusion events. Your options are as follows:

- Select Use Network Discovery Vulnerability Mappings if you want to use system-based vulnerability information to perform impact correlation.

- Select Use Third-Party Vulnerability Mappings if you want to use third-party vulnerability references to perform impact correlation. For more information, see Mapping Third-Party Vulnerabilities or the FireSIGHT System Host Input API Guide .

You can select either or both of the check boxes. If the system generates an intrusion event and the host involved in the event has servers or an operating system with vulnerabilities in the selected vulnerability mapping sets, the intrusion event is marked with the Vulnerable (level 1: red) impact icon. For any servers which do not have vendor or version information, note that you need to configure vulnerability mapping in the system policy. For more information, see Mapping Vulnerabilities for Servers.

If you clear both check boxes, intrusion events will never be marked with the Vulnerable (level 1: red) impact icon. For more information, see Using Impact Levels to Evaluate Events.

To update vulnerability settings:

Admin/Discovery Admin

.

The Edit Vulnerability Settings pop-up window appears.

Step 2 Update the settings as needed.

Step 3 Click Save to save the vulnerability settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Setting Indications of Compromise Rules

License: FireSIGHT

For your system to detect and tag indications of compromise (IOC), you must first activate at least one IOC rule in your discovery policy. Each IOC rule corresponds to one type of IOC tag, and all IOC rules are predefined by Cisco; you cannot create original rules. You can enable any or all rules, depending on the needs of your network and organization. For example, if hosts using software such as Microsoft Excel never appear on your monitored network, you may decide not to enable the IOC tags that pertain to Excel-based threats. For more information on the IOC feature, see Understanding Indications of Compromise.

You must also enable the FireSIGHT System features associated with the IOC rules you enable, such as intrusion and malware protection; if a rule’s associated feature is not enabled, no relevant data is collected and the rule cannot trigger. For more information on the types of IOC rules and their associated features, see Understanding Indications of Compromise Types.

To set indications of compromise rules in the discovery policy:

Admin/Discovery Admin

.

The Edit Indications of Compromise Settings pop-up window appears.

Step 2 To toggle the entire IOC feature off or on, click the slider next to Enable IOC.

Step 3 To enable or disable individual IOC rules, click the slider in the rule’s Enabled column.

Step 4 Click Save to save your IOC rule settings and return to the Advanced tab of the discovery policy.

Your changes are saved.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Adding NetFlow-Enabled Devices

License: FireSIGHT

If you have enabled the NetFlow feature on your NetFlow-enabled devices, you can use the connection data exported by these devices to supplement the connection data collected by Cisco devices.

Before you can use them in discovery rules, you must configure the NetFlow-enabled devices you plan to use (see Preparing to Analyze NetFlow Data), then add them to the network discovery policy.

For more information on using NetFlow data with the FireSIGHT System, including information on additional prerequisites, see Understanding NetFlow.

To add NetFlow-enabled devices for connection data collection:

Admin/Discovery Admin

Step 1 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 2 Click Advanced.

The Advanced page appears.

) next to NetFlow Devices.

The Add NetFlow Device pop-up window appears.

Step 4 In the IP Address field, enter the IP address of the NetFlow-enabled device you want to use to collect connection data.

Step 5 To add additional NetFlow-enabled devices, repeat steps 3 and 4.

Step 6 Click Save.

The device appears on the list of NetFlow-enabled devices.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Configuring Data Storage

License: FireSIGHT

Data storage settings control the kinds of data stored in the database, and therefore determine the data that the FireSIGHT System can use. These settings also control how long data is retained in the network map.

The following options comprise the network discovery data storage settings.

When Host Limit Reached

You can control how hosts are handled when the Defense Center reaches its host limit (as determined by the FireSIGHT license) and the network map is full. This option is especially valuable if you want to prevent spoofed hosts from taking the place of valid hosts in the network map. To drop old hosts, select Drop hosts from the When Host Limit Reached drop-down list.To drop new hosts, select Don’t insert new hosts from the When Host Limit Reached drop-down list. For more information, see Understanding FireSIGHT Host and User License Limits.

Host Timeout

The amount of time that passes, in minutes, before the system drops a host from the network map due to inactivity. The default setting is 10080 minutes (7 days). Individual host IP and MAC addresses can time out individually, but a host does not disappear from the network map unless all of its associated addresses have timed out.

To avoid premature timeout of hosts, make sure that the host timeout value is longer than the update interval in the network discovery policy. For more information on the update interval, see Configuring General Settings.

Server Timeout

The amount of time that passes, in minutes, before the system drops a server from the network map due to inactivity. The default setting is 10080 minutes (7 days).

To avoid premature timeout of servers, make sure that the service timeout value is longer than the update interval in the network discovery policy. For more information, see Configuring General Settings.

Client Application Timeout

The amount of time that passes, in minutes, before the system drops a client from the network map due to inactivity. The default setting is 10080 minutes (7 days).

You should make sure that the client timeout value is longer than the update interval in the network discovery policy. For more information, see Configuring General Settings.

To update data storage settings:

Admin/Discovery Admin

.

The Data Storage Settings pop-up window appears.

Step 2 Update the settings as needed.

Step 3 Click Save to save the data storage settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Configuring Discovery Event Logging

License: FireSIGHT

The Event Logging Settings control whether discovery and host input events are logged. If you do not log an event, you cannot retrieve it in event views or use it to trigger correlation rules.

To set event logging settings:

Admin/Discovery Admin

.

The Event Logging Settings pop-up window appears.

Step 2 Select or clear the check boxes next to the discovery and host input event types you want to log in the database. See Understanding Discovery Event Types and Understanding Host Input Event Types for information about each event type.

Step 3 Click Save to save the event logging settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Adding Identity Sources

License: FireSIGHT

You can add new active sources through this page, or change the priority or timeout settings for existing sources. Note that adding a scanner to this page does not add the full integration capabilities that exist for the Nmap scanners, but does allow integration of imported third-party application or scan results. If you import data from a third-party application or scanner, remember to make sure that you map vulnerabilities from the source to the vulnerabilities in the network map. For more information, see Mapping Third-Party Vulnerabilities.

To add identity sources:

Admin/Discovery Admin

.

The Edit OS and Server Identity Sources pop-up window appears.

Step 2 To add a new source, click Add Source.

The Add Identity Source pop-up window appears.

Step 3 Type a Name for the source.

Step 4 Select the input source type from the Type drop-down list:

- Select Scanner if you plan to import scan results using the AddScanResult function.

- Select Application if you do not plan to import scan results.

Step 5 To indicate the duration of time that should elapse between the addition of an identity to the network map by this source and the deletion of that identity, select Hours, Days, or Weeks from the Timeout drop-down list and type the appropriate duration.

Step 6 Optionally, to promote a source and cause the operating system and application identities to be used in favor of sources below it in the list, select the source and click the up arrow.

Step 7 Optionally, to demote a source and cause the operating system and application identities to be used only if there are no identities provided by sources above it in the list, select the source and click the down arrow.

Step 8 Click Save to save the identity source settings and return to the Advanced tab of the network discovery policy.

You must apply the network discovery policy for your changes to take effect. For more information, see Applying the Network Discovery Policy.

Applying the Network Discovery Policy

License: FireSIGHT

By default, the network discovery policy is applied to any targeted zones on managed devices when they are registered with the Defense Center. Applying the network discovery policy allows the system to begin monitoring your network according to your specifications. If you change the network discovery policy, you must reapply it before your changes take effect.

When you reapply the network discovery policy:

- the system deletes and then rediscovers MAC address, TTL, and hops information from the network map for the hosts in your monitored networks

- the affected managed devices discard any discovery data that has not yet been sent to the Defense Center

When you apply a network discovery policy, make sure that you have already applied an access control policy to all devices managed by the Defense Center. If an access control policy has not been applied to each device, the network discovery policy apply fails. Note that you cannot apply a network discovery policy on a Defense Center where no FireSIGHT license is installed.

If you modify a network or port object used in the network discovery policy, you must reapply the policy for those changes to take effect for discovery.

Note that you cannot apply a network discovery policy to stacked devices running different versions of the FireSIGHT System (for example, if an upgrade on one of the devices fails).

To apply the network discovery policy:

Admin/Security Approver

Step 1 Select Policies > Network Discovery.

The Network Discovery Policy page appears.

Step 2 Click Apply.

A message appears, confirming that you want to apply the policy to all zones targeted by access control policies on the Defense Center.

Step 3 Click Yes to apply the policy.

Enhancing Network Discovery

The information about your network traffic collected by the FireSIGHT System is most valuable to you when the system can correlate this information to identify the hosts on your network that are most vulnerable and most important.

As an example, if you have several devices on your network running a customized version of SuSE Linux, the system cannot identify that operating system and so cannot map vulnerabilities to the hosts. However, knowing that the system has a list of vulnerabilities for SuSE Linux, you may want to create a custom fingerprint for one of the hosts that can then be used to identify the other hosts running the same operating system. You can include a mapping of the vulnerability list for SuSE Linux in the fingerprint to associate that list with each host that matches the fingerprint.

The system also allows you to input host data from third-party systems directly into the network map, using the host input feature. However, third-party operating system or application data does not automatically map to vulnerability information. If you want to see vulnerabilities and perform impact correlation for hosts using third-party operating system, server, and application protocol data, you must map the vendor and version information from the third-party system to the vendor and version listed in the vulnerability database (VDB). You also may want to maintain the host input data on an ongoing basis. Note that even if you map application data to FireSIGHT System vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.

If the system cannot identify application protocols running on hosts on your network, you can create user-defined application protocol detectors that allow the system to identify the applications based on a port or a pattern. You can also import, activate, and deactivate certain application detectors to further customize the application detection capability of the FireSIGHT System.

You can also replace detection of operating system and application data using scan results from the Nmap active scanner or augment the vulnerability lists with third-party vulnerabilities. The system may reconcile data from multiple sources to determine the identity for an application. For more information on how the system does this, see Understanding Current Identities. For more information on active scanning, see Configuring Active Scanning.

For more information, see the following sections:

- Assessing Your Detection Strategy

- Enhancing Your Network Map

- Using Custom Fingerprinting

- Working with Application Detectors

- Importing Host Input Data

Assessing Your Detection Strategy

License: FireSIGHT

Before you make any changes to the system’s default detection capabilities, you should analyze what hosts are not being identified correctly and why, so you can decide what solution to implement. Use the following as a guide for your decision:

- Are Your Managed Devices Correctly Placed?

- Do Unidentified Operating Systems Have a Unique TCP Stack?

- Can the FireSIGHT System Identify All Applications?

- Have You Applied Patches that Fix Vulnerabilities?

- Do You Want to Track Third-Party Vulnerabilities?

Are Your Managed Devices Correctly Placed?

License: FireSIGHT

If network devices such as load balancers, proxy servers, or NAT devices reside between the managed device and the unidentified or misidentified host, place a managed device closer to the misidentified host rather than using custom fingerprinting. Cisco does not recommend using custom fingerprinting in this scenario.

Do Unidentified Operating Systems Have a Unique TCP Stack?

License: FireSIGHT

If the system misidentifies a host, you should investigate why the host is misidentified to help you decide between creating and activating a custom fingerprint or substituting Nmap or host input data for discovery data.

Caution If you encounter misidentified hosts, contact your support representative before creating custom fingerprints.

If a host is running an operating system that is not detected by the system by default and does not share identifying TCP stack characteristics with existing detected operating systems, you should create a custom fingerprint.

For example, if you have a customized version of Linux with a unique TCP stack that the system cannot identify, you would benefit from creating a custom fingerprint, which allows the system to identify the host and continuing monitoring it, rather than using scan results or third-party data, which require you to actively update the data yourself on an ongoing basis.

Note that many open source Linux distributions use the same kernel, and as such, the system identifies them using the Linux kernel name. If you create a custom fingerprint for a Red Hat Linux system, you may see other operating systems (such as Debian Linux, Mandrake Linux, Knoppix, and so on) identified as Red Hat Linux, because the same fingerprint matches multiple Linux distributions.

You should not use a fingerprint in every situation. For example, a modification may have been made to a host’s TCP stack so that it resembles or is identical to another operating system. For example, an Apple Mac OS X host is altered, making its fingerprint identical to a Linux 2.4 host, causing the system to identify it as Linux 2.4 instead of Mac OS X. If you create a custom fingerprint for the Mac OS X host, it may cause all legitimate Linux 2.4 hosts to be erroneously identified as Mac OS X hosts. In this case, if Nmap correctly identifies the host, you could schedule regular Nmap scans for that host.

If you import data from a third-party system using host input, you must map the vendor, product, and version strings that the third party uses to describe servers and application protocols to the Cisco definitions for those products. For more information, see Managing Third-Party Product Mappings. Note that even if you map application data to FireSIGHT System vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.

The system may reconcile data from multiple sources to determine the current identity for an operating system or application. For more information on how the system does this, see Understanding Current Identities.

For Nmap data, you can schedule regular Nmap scans. For host input data, you can regularly run the Perl script for the import or the command line utility. However, note that active scan data and host input data may not be updated with the frequency of discovery data.

Can the FireSIGHT System Identify All Applications?

License: FireSIGHT

If a host is correctly identified by the system but has unidentified applications, you can create a user-defined detector to provide the system with port and pattern matching information to help identify the application. For more information, see Creating a User-Defined Application Protocol Detector.

Have You Applied Patches that Fix Vulnerabilities?

License: FireSIGHT

If the system correctly identifies a host but does not reflect applied fixes, you can use the host input feature to import patch information. When you import patch information, you must map the fix name to a fix in the database. For more information, see Mapping Third-Party Product Fixes.

Do You Want to Track Third-Party Vulnerabilities?

License: FireSIGHT

If you have vulnerability information from a third-party system that you want to use for impact correlation, you can map the third-party vulnerability identifiers for servers and application protocols to vulnerability identifiers in the Cisco database and then import the vulnerabilities using the host input feature. For more information on using the host input feature, see the FireSIGHT System Host Input API Guide. For more information on mapping third-party vulnerabilities, see Mapping Third-Party Vulnerabilities. Note that even if you map application data to FireSIGHT System vendor and version definitions, imported third-party vulnerabilities are not used for impact assessment for clients or web applications.

Enhancing Your Network Map

License: FireSIGHT

The FireSIGHT System builds the network map using data it detects by passively analyzing traffic. It also uses data added through active sources such as the host input feature and the Nmap scanner. Understanding how the system decides which data to use for an application or operating system identity can help you decide how best to augment the system’s passive detection capabilities with active input sources.

For more information, see the following topics:

- Understanding Passive Detection

- Understanding Active Detection

- Understanding Current Identities

- Understanding Identity Conflicts

Understanding Passive Detection

License: FireSIGHT

Passive detection is the detection of host operating system, client, and application information through analysis of traffic passively collected by the system. The system uses information in the VDB to help it identify your network assets.

If the system cannot identify an operating system on a host, you can manually determine it and then create a custom server or client fingerprint to help the system recognize that operating system on other hosts with similar operating system characteristics.

The system uses all collected passive fingerprints for a host operating system to create a derived fingerprint. The system creates derived fingerprints by applying a formula which calculates the most likely identity using the confidence value of each collected fingerprint and the amount of corroborating fingerprint data between identities. Common elements are identified between identities.

If you use user-defined application detectors on your network, you can augment the system’s application detection capabilities by creating custom detectors that provide the system with the information it needs to identify those applications. NetFlow can also add passively detected application information to the network map.

Note that the system does not use application protocol and operating system data that it classified as unknown because it is unable to interpret the data. The managed device reports the identity to the Defense Center as unknown and the identity data is not used to derive fingerprints.

Understanding Active Detection

License: FireSIGHT

Active detection is addition, to the network map, of data collected by active sources, such as host operating system and application information. For example, you can use the Nmap scanner to actively scan the hosts that you target on your network. Nmap discovers operating systems and applications on hosts.

In addition, the host input feature allows you to actively add host input data to the network map. There are two different categories of host input data:

- You can modify a host’s operating system or application identity through the FireSIGHT System user interface. Data added through the interface is user input data .

- You can also import data using a command line utility. Imported data is host import input data .

The system retains one identity for each active source. When you run an Nmap scan instance, for example, the results of the previous scan are replaced with the new scan results. However, if you run an Nmap scan and then replace those results with data from a client whose results are imported through the command line, the system retains both the identities from the Nmap results and the identities from the import client. Then the system uses the priorities set in the system policy to determine which active identity to use as the current identity.

Note that user input is considered one source, even if it comes from different users. As an example, if UserA sets the operating system through the host profile, and then UserB changes that definition through the host profile, the definition set by UserB is retained, and the definition set by UserA is discarded. In addition, note that user input overrides all other active sources and is used as the current identity if it exists.

Understanding Current Identities

License: FireSIGHT

The current identity for an application or an operating system on a host is the identity that the system finds most likely to be correct.

The system uses the current identity for an operating system or application for the following purposes:

- to assign vulnerabilities to a host

- for impact assessment

- when evaluating correlation rules written against operating system identifications, host profile qualifications, and compliance white lists

- for display in the Hosts and Servers table views in workflows

- for display in the host profile

- to calculate the operating system and application statistics on the Discovery Statistics page

For example, if a user sets the operating system to Windows 2003 Server on a host, Windows 2003 Server is the current identity. Attacks which target Windows 2003 Server vulnerabilities on that host are given a higher impact, and the vulnerabilities listed for that host in the host profile include Windows 2003 Server vulnerabilities.

The database may retain information from several sources for the operating system or for a particular application on a host.

The system treats an operating system or application identity as the current identity when the source for the data has the highest source priority. Possible sources have the following priority order:

1. user

2. scanner and application (set in the network discovery policy)

3. managed devices

4. NetFlow

Note that a new higher priority application identity will not override a current application identity if it has less detail than the current identity.

In addition, note that when an identity conflict occurs, the resolution of the conflict depends on settings in the network discovery policy or on your manual resolution, as described in Understanding Identity Conflicts.

Understanding Identity Conflicts

License: FireSIGHT

An identity conflict occurs when the system reports a new passive identity that conflicts with the current active identity and previously reported passive identities. For example, the previous passive identity for an operating system is reported as Windows 2000, then an active identity of Windows XP becomes current. Next, the system detects a new passive identity of Ubuntu Linux 8.04.1. The Windows XP and the Ubuntu Linux identities are in conflict.

When an identity conflict exists for the identity of the host’s operating system or one of the applications on the host, the system lists both conflicting identities as current and uses both for impact assessment until the conflict is resolved.

A user with Administrator privileges can also configure the system to generate an event when an identity conflict occurs. That user can then set up a correlation policy with a correlation rule that uses an Nmap scan as a correlation response. When an event occurs, Nmap scans the host to obtain updated host operating system and application data.

Using Custom Fingerprinting

License: FireSIGHT

The FireSIGHT System includes operating system fingerprints that the system uses to identify the operating system on each host it detects. However, sometimes the system cannot identify a host operating system or misidentifies it because no fingerprints exist that match the operating system. To correct this problem, you can create a custom fingerprint, which provides a pattern of operating system characteristics unique to the unknown or misidentified operating system, to supply the name of the operating system for identification purposes.

If the system cannot match a host’s operating system, it cannot identify the vulnerabilities for the host, because the system derives the list of vulnerabilities for each host from its operating system fingerprint. For example, if the system detects a host running Microsoft Windows, the system has a stored Microsoft Windows vulnerability list that it adds to the host profile for that host based on the detected Windows operating system.

As an example, if you have several devices on your network running a new beta version of Microsoft Windows, the system cannot identify that operating system and so cannot map vulnerabilities to the hosts. However, knowing that the system has a list of vulnerabilities for Microsoft Windows, you may want to create a custom fingerprint for one of the hosts that can then be used to identify the other hosts running the same operating system. You can include a mapping of the vulnerability list for Microsoft Windows in the fingerprint to associate that list with each host that matches the fingerprint.

When you create a custom fingerprint, you can add a customized display of operating system information, and you can select the operating system vendor, product name, and product version for the operating system which the system should use as a model for the vulnerability list for the fingerprint. The Defense Center lists the set of vulnerabilities associated with that fingerprint for any hosts running the same operating system. If the custom fingerprint you create does not have any vulnerabilities mappings in it, the system uses the fingerprint to assign the custom operating system information you provide in the fingerprint. When the system sees new traffic from a host that has already been detected and currently resides in the network map, the system updates the host with the new fingerprint information. the system also uses the new fingerprint to identify any new hosts with that operating system the first time they are detected.

Before attempting to fingerprint a host, you should determine why the host is not being identified correctly to decide whether custom fingerprinting is a viable solution. For more information, see Assessing Your Detection Strategy.

You can create two types of fingerprints with the system:

- Client fingerprints, which identify operating systems based on the SYN packet that the host sends when it connects to a TCP application running on another host on the network.

See Fingerprinting Clients for information about how to obtain a client fingerprint for a host.

- Server fingerprints, which identify operating systems based on the SYN-ACK packet that the host uses to respond to an incoming connection to a running TCP application.

See Fingerprinting Servers for information about how to obtain a server fingerprint for a host.

After creating fingerprints, you must activate them before the system can associate them with hosts. See Managing Fingerprints for more information.

Note If both a client and server fingerprint match the same host, the client fingerprint is used.

Fingerprinting Clients

License: FireSIGHT

Client fingerprints identify operating systems based on the SYN packet a host sends when it connects to a TCP application running on another host on the network.

If the Defense Center does not have direct contact with monitored hosts, you can specify a device that is managed by the Defense Center and is closest to the host you intend to fingerprint when specifying client fingerprint properties.

Before you begin the fingerprinting process, obtain the following information about the host you want to fingerprint:

- The number of network hops between the host and the Defense Center or the device you use to obtain the fingerprint. (Cisco strongly recommends that you directly connect the Defense Center or the device to the same subnet that the host is connected to.)

- The network interface (on the Defense Center or the device) that is connected to the network where the host resides.

- The actual operating system vendor, product, and version of the host.

- Access to the host in order to generate client traffic.

To obtain a client fingerprint for a host:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

Step 2 Click Create Custom Fingerprint.

The Create Custom Fingerprint page appears.

Step 3 From the Device drop-down list, select the Defense Center or the device that you want to use to collect the fingerprint.

Step 4 In the Fingerprint Name field, type an identifying name for the fingerprint.

Step 5 In the Fingerprint Description field, type a description for the fingerprint.

Step 6 From the Fingerprint Type list, select Client.

Step 7 In the Target IP Address field, type an IP address of the host you want to fingerprint. Note that the fingerprint will only be based on traffic to and from the host IP address you specify, not any of the host’s other IP addresses (if it has any).

Caution For information on enabling IPv6 on managed devices and Defense Centers, see Configuring Management Interfaces.

Step 8 In the Target Distance field, enter the number of network hops between the host and the device that you selected in step 3 to collect the fingerprint.

Caution This must be the actual number of physical network hops to the host, which may or may not be the same as the number of hops detected by the system.

Step 9 From the Interface list, select the network interface that is connected to the network segment where the host resides.

Caution Cisco recommends that you do not use the sensing interface on a managed device for fingerprinting for several reasons. First, fingerprinting does not work if the sensing interface is on a span port. Also, if you use the sensing interface on a device, the device stops monitoring the network for the amount of time it takes to collect the fingerprint. You can, however, use the management interface or any other available network interfaces to perform fingerprint collection. If you do not know which interface is the sensing interface on your device, refer to the Installation Guide for the specific model you are using to fingerprint.

Step 10 If you want to display custom information in the host profile for fingerprinted hosts (or if the host you want to fingerprint does not reside in the OS Vulnerability Mappings section), select Use Custom OS Display in the Custom OS Display section and provide the values you want to display in host profiles for the following:

- In the Vendor String field, type the operating system’s vendor name. For example, the vendor for Microsoft Windows would be Microsoft.

- In the Product String field, type the operating system’s product name. For example, the product name for Microsoft Windows 2000 would be Windows.

- In the Version String field, type the operating system’s version number. For example, the version number for Microsoft Windows 2000 would be 2000.

Step 11 In the OS Vulnerability Mappings section, select the operating system, product, and versions you want to use for vulnerability mapping.

For example, if you want your custom fingerprint to assign the list of vulnerabilities from Redhat Linux 9 to matching hosts, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the major version.

Tip When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. After the fingerprint is created and activated, you can add additional vulnerability mappings for other versions of the operating system. See Editing an Active Fingerprint for more information.

You must specify a Vendor and Product name in this section if you want to use the fingerprint to identify vulnerabilities for matching hosts or if you do not assign custom operating system display information. To map vulnerabilities for all versions of an operating system, specify only the vendor and product name. For example, to add all versions of the Palm OS, you would select PalmSource, Inc. from the Vendor list, Palm OS from the Product list, and leave all other lists at their default settings.

Note Not all options in the Major Version, Minor Version, Revision Version, Build, Patch, and Extension drop-down lists may apply to the operating system you choose. In addition, if no definition appears in a list that matches the operating system you want to fingerprint, you can leave these values empty. Be aware that if you do not create any OS vulnerability mappings in a fingerprint, the system cannot use the fingerprint to assign a vulnerabilities list with hosts identified by the fingerprint.

Step 12 Click Create.

The Custom Fingerprint status page reappears. The status page refreshes every ten seconds until it receives data from the host in question.

Tip When you click Create, the status briefly shows New, then switches to Pending, where it remains until traffic is seen for the fingerprint, then the status switches to Ready.

Step 13 Using the IP address you specified as the target IP address, access the host you are trying to fingerprint and initiate a TCP connection to the appliance.

For example, access the web interface of the Defense Center from the host you want to fingerprint or SSH into the Defense Center from the host. If you are using SSH, use the following command:

ssh -b localIPv6address DCmanagementIPv6address

where localIPv6address is the IPv6 address specified in step 7 that is currently assigned to the host and DCmanagementIPv6address is the management IPv6 address of the Defense Center.

The Custom Fingerprint page should then reload with a “Ready” status.

Note To create an accurate fingerprint, traffic must be seen by the appliance collecting the fingerprint. If you are connected through a switch, traffic to a system other than the appliance may not be seen by the system.

Step 14 After the fingerprint is created, you must activate it before the Defense Center can use it to identify hosts. See Managing Fingerprints for more information.

Fingerprinting Servers

License: FireSIGHT

Server fingerprints identify operating systems based on the SYN-ACK packet that the host uses to respond to an incoming connection to a running TCP application. Before you begin, you should obtain the following information about the host you want to fingerprint:

- The number of network hops between the host and the appliance you use to obtain the fingerprint. Cisco strongly recommends that you directly connect an unused interface on the appliance to the same subnet that the host is connected to.

- The network interface (on the appliance) that is connected to the network where the host resides.

- The actual operating system vendor, product, and version of the host.

- An IP address that is not currently in use and is authorized on the network where the host is located.

Tip If the Defense Center does not have direct contact with monitored hosts, you can specify a managed device that is closest to the host you intend to fingerprint when specifying server fingerprint properties.

To obtain a server fingerprint for a host:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

Step 2 Click Create Custom Fingerprint.

The Create Custom Fingerprint page appears.

Step 3 From the Device list, select the Defense Center or the managed device that you want to use to collect the fingerprint.

Step 4 In the Fingerprint Name field, type an identifying name for the fingerprint.

Step 5 In the Fingerprint Description field, type a description for the fingerprint.

Step 6 From the Fingerprint Type list, select Server.

Server fingerprinting options appear.

Step 7 In the Target IP Address field, type an IP address of the host you want to fingerprint. Note that the fingerprint will only be based on traffic to and from the host IP address you specify, not any of the host’s other IP addresses (if it has any).

Caution You can capture IPv6 fingerprints only with appliances running Version 5.2 and later of the FireSIGHT System.

Step 8 In the Target Distance field, enter the number of network hops between the host and the device that you selected in step 3 to collect the fingerprint.

Caution This must be the actual number of physical network hops to the host, which may or may not be the same as the number of hops detected by the system.

Step 9 From the Interface list, select the network interface that is connected to the network segment where the host resides.

Caution Cisco recommends that you do not use the sensing interface on a managed device for fingerprinting for several reasons. First, fingerprinting does not work if the sensing interface is on a span port. Also, if you use the sensing interface on a device, the device stops monitoring the network for the amount of time it takes to collect the fingerprint. You can, however, use the management interface or any other available network interfaces to perform fingerprint collection. If you do not know which interface is the sensing interface on your device, refer to the Installation Guide for the specific model you are using to fingerprint.

Step 10 Click Get Active Ports.

If the system has detected any open ports on the host, they appear in the drop-down list.

Step 11 In the Server Port field, type the port that you want the device selected to collect the fingerprint to initiate contact with, or select a port from the Get Active Ports drop-down list.

You can use any server port that you know is open on the host (for instance, 80 if the host is running a web server).

Step 12 In the Source IP Address field, type an IP address that should be used to attempt to communicate with the host.

You should use a source IP address that is authorized for use on the network but is not currently being used, for example, a DHCP pool address that is currently not in use. This prevents you from temporarily knocking another host offline while you create the fingerprint.

In addition, you should exclude that IP address from monitoring in your network discovery policy while you create the fingerprint. Otherwise, the network map and discovery event views will be cluttered with inaccurate information about the host represented by that IP address. For more information, see Understanding Discovery Data Collection.

Step 13 In the Source Subnet Mask field, type the subnet mask for the IP address you are using.

Step 14 If the Source Gateway field appears, enter the default gateway IP address that should be used to establish a route to the host.

The Source Gateway field appears if the target distance (number of hops) is 1 or higher and you are using an interface other than the management interface to connect to the network where the host resides.

Step 15 If you want to display custom information in the host profile for fingerprinted hosts or if the fingerprint name you want to use does not exist in the OS Definition section, select Use Custom OS Display in the Custom OS Display section.

Provide the values you want to appear in host profiles for the following:

- In the Vendor String field, type the operating system’s vendor name. For example, the vendor for Microsoft Windows would be Microsoft.

- In the Product String field, type the operating system’s product name. For example, the product name for Microsoft Windows 2000 would be Windows.

- In the Version String field, type the operating system’s version number. For example, the version number for Microsoft Windows 2000 would be 2000.

Step 16 In the OS Vulnerability Mappings section, select the operating system, product, and versions you want to use for vulnerability mapping. For example, if you want your custom fingerprint to assign the list of vulnerabilities from Redhat Linux 9 to matching hosts, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Tip When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. After the fingerprint is created and activated, you can add additional vulnerability mappings for other versions of the operating system. See Editing an Active Fingerprint for more information.

You must specify a Vendor and Product name in this section if you want to use the fingerprint to identify vulnerabilities for matching hosts or if you do not assign custom operating system display information. To map vulnerabilities for all versions of an operating system, specify only the vendor and product name. For example, to add all versions of the Palm OS, you would select PalmSource, Inc. from the Vendor list, Palm OS from the Product list, and leave all other lists at their default settings.

Note Not all options in the Major Version, Minor Version, Revision Version, Build, Patch, and Extension drop-down lists may apply to the operating system you choose. In addition, if no definition appears in a list that matches the operating system you want to fingerprint, you can leave these values empty. Be aware that if you do not create any OS vulnerability mappings in a fingerprint, the system cannot use the fingerprint to assign a vulnerabilities list with hosts identified by the fingerprint.

Step 17 Click Create.

Step 18 The Custom Fingerprint status page appears. It reloads every ten seconds and should reload with a “Ready” status.

Step 19 After the fingerprint is created, activate it and, optionally, add vulnerability mappings. See Managing Fingerprints for more information.

Managing Fingerprints

License: FireSIGHT

You can activate, deactivate, delete, view, and edit custom fingerprints. When creating a fingerprint, you assign a single vulnerability mapping for the fingerprint. For more information on creating a fingerprint, see Fingerprinting Clients and Fingerprinting Servers. After the fingerprint is created and activated, you can edit the fingerprint to make changes or add vulnerability mappings.

To access the Custom Fingerprints page:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

If the system is awaiting data to create a fingerprint, it automatically refreshes the page every 10 seconds until the fingerprint is created.

See the following sections for more information:

- Activating Fingerprints

- Deactivating Fingerprints

- Deleting Fingerprints

- Editing Fingerprints

Activating Fingerprints

License: FireSIGHT

After creating a custom fingerprint, you must activate it before the system can use it to identify hosts. After the new fingerprint is activated, the system uses it to re-identify previously discovered hosts and discover new hosts.

To activate a fingerprint:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

Step 2 Click the slider next to the fingerprint you want to activate.

Note The activate option is only available if the fingerprint you created is valid. If the slider is not available, try creating the fingerprint again.

The Defense Center activates the fingerprint and propagates it to all managed devices. The icon next to the fingerprint name changes to indicate that the fingerprint is active.

Deactivating Fingerprints

License: FireSIGHT

If you want to stop using a fingerprint, you can deactivate it. Deactivating a fingerprint causes a fingerprint to no longer be used, but allows it to remain on the system. When you deactivate a fingerprint, the operating system is marked as unknown for hosts that use the fingerprint. If the hosts are detected again and match a different active fingerprint, they are then identified by that active fingerprint.

Deleting a fingerprint removes it from the system completely. After deactivating a fingerprint, you can delete it.

To deactivate an active fingerprint:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

Step 2 Click the slider next to the active fingerprint you want to deactivate.

The Defense Center deactivates the fingerprint and propagates the deactivation to all managed devices.

Deleting Fingerprints

License: FireSIGHT

If you no longer have use for a fingerprint, you can delete it from the system. Note that you must deactivate fingerprints before you can delete them.

To delete a fingerprint:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

Step 2 If the fingerprints you want to delete are active, click the slider icon next to each one to deactivate it.

) next to the fingerprint you want to delete.

Step 4 Click OK to confirm that you want to delete the fingerprint.

The fingerprint is deleted.

Editing Fi ngerprints

License: FireSIGHT

After you create a fingerprint, you can view or edit it. This allows you to make changes and resubmit the fingerprint or add additional vulnerability mappings to it. You can modify fingerprints whether they are active or inactive, but depending on a fingerprint’s state, the things that can be modified differ.

If a fingerprint is inactive, you can modify all elements of the fingerprint and resubmit it to the Defense Center. This includes all properties you specified when creating the fingerprint, such as fingerprint type, target IP addresses and ports, vulnerability mappings, and so on. When you edit an inactive fingerprint and submit it, it is resubmitted to the system and, if it is a client fingerprint, you must resend traffic to the appliance before activating it. Note that you can select only a single vulnerability mapping for an inactive fingerprint. After you activate the fingerprint, you can map additional operating systems and versions to its vulnerabilities list.

If a fingerprint is active, you can modify the fingerprint name, description, custom operating system display, and map additional vulnerabilities to it.

For more information, see the following sections:

- Editing an Inactive Fingerprint

- Editing an Active Fingerprint

Editing an Inactive Fingerprint

License: FireSIGHT

If a fingerprint is inactive, you can modify its properties and resubmit it to the system. This includes making changes such as the type of fingerprint to use, the target system to fingerprint, and so on.

To edit inactive fingerprints:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

) next to the fingerprint you want to edit.

The Edit Custom Fingerprint page appears.

Step 3 Make changes to the fingerprint as necessary:

- If you are modifying a client fingerprint, see Fingerprinting Clients for more information about the options you can configure.

- If you are modifying a server fingerprint, see Fingerprinting Servers for more information about the options you can configure.

Step 4 Click Save to resubmit the fingerprint.

Note If you modified a client fingerprint, remember to send traffic from the host to the appliance gathering the fingerprint.

Editing an Active Fingerprint

License: FireSIGHT

When a fingerprint is active, you can change its name, description, and display label. In addition, you can manage vulnerability mappings, including adding and deleting vulnerability mappings.

To edit active fingerprints:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Operating Systems.

The Custom Fingerprint page appears.

) next to the fingerprint you want to edit.

The Edit Custom Fingerprint Product Mappings page appears.

Step 3 Modify the fingerprint name, description, and custom OS display, if necessary.

Step 4 If you want to delete a vulnerability mapping, click Delete next to the mapping in the Pre-Defined OS Product Maps section of the page.

Step 5 If you want to add additional operating systems for vulnerability mapping, select the Product and, if applicable, the Major Version, Minor Version, Revision Version, Build, Patch, and Extension and then click Add OS Definition.

The vulnerability mapping is added to the Pre-Defined OS Product Maps list.

Step 6 Click Save to save your changes.

Working with Application Detectors

License: FireSIGHT

When the FireSIGHT System analyzes IP traffic, it uses detectors to identify the commonly used applications on your network. You use the Detectors page (Policies > Application Detectors) to customize the detection capability of the FireSIGHT System.

The page provides information about each detector, including:

- the name of the detector

- the protocol (TCP, UDP, or both) of traffic that the detector inspects

- whether the type of the detector is application protocol, client, web application, or internal detector

- for port-based application detectors, the port used by the application traffic

- details regarding the detected application, including the name, description, risk, business relevance, tags, and categories associated with the application detected by the detector

- the state (active or inactive) of the detector

The system uses only active detectors to analyze application traffic.

You may notice that the listed detectors have different properties. For example, you can view the settings for some detectors but not others. Similarly, you can delete some detectors but not others. This is because there are several different types of Cisco-provided detectors, as described in the following sections.

Cisco-Provided Internal Detectors

Internal detectors are application detectors that are only delivered with updates to the FireSIGHT System. Internal detectors detect client, web application, or application protocol traffic, depending on the detector, but they are categorized as internal detectors rather than one of the other types because they are built-in detectors and cannot be deactivated.

Internal detectors are always on; you cannot deactivate, delete, or otherwise configure them. Examples of internal detectors are the Built-in Amazon detector and the Built-in AppleTalk detector.

Cisco-Provided Client Detectors

Cisco-provided client detectors, which detect client traffic, are delivered via VDB updates but may also be provided with updates to the FireSIGHT System. These detectors may also be provided by Cisco Professional Services as an importable detector.

You can activate and deactivate client detectors according to the needs of your organization. VDB updates may also activate or deactivate client detectors. You can export a client detector only if you import it.

The Google Earth and Immunet detectors are examples of client detectors.

Cisco-Provided Web Application Detectors

Cisco-provided web application detectors, which detect web applications in payloads of HTTP traffic, are delivered via VDB updates but may also be provided with updates to the FireSIGHT System.

You can activate and deactivate web application detectors according to the needs of your organization. VDB updates may activate or deactivate web application detectors. Examples of web application detectors are the Blackboard and LiveJournal detectors.

Cisco-Provided Application Protocol (Port) Detectors

Port-based application protocol detectors, provided by Cisco, are based on detection of network traffic on well-known ports. These detectors are delivered via VDB updates but may also be provided with updates to the FireSIGHT System or provided by Cisco Professional Services as an importable detector.

You can activate and deactivate application protocol detectors according to the needs of your organization. You can also view a detector definition to use it as the basis for a custom detector. VDB updates may activate or deactivate application protocol detectors.

The chargen and finger detectors are examples of port detectors.

Cisco-Provided Application Protocol (FireSIGHT) Detectors

FireSIGHT-based application protocol detectors, provided by Cisco, are based on detection of network traffic using FireSIGHT application fingerprints. These detectors are delivered via VDB updates but may also be provided with updates to the FireSIGHT System.

You can activate and deactivate application protocol detectors according to the needs of your organization. VDB updates may activate or deactivate Cisco-provided application protocol detectors. Examples of FireSIGHT-based application protocol detectors are the Jabber and Steam detectors.

Application Protocol (Pattern) Detectors

Pattern-based application detectors are based on detection of patterns in packets from network traffic. These detectors can be provided by Cisco Professional Services as an importable detector or created by you. This allows you to enhance the system’s detection capabilities with new pattern-based detectors without updating the FireSIGHT System as a whole.

You can activate and deactivate application protocol detectors according to the needs of your organization.

You have full control over imported and user-defined detectors; you can activate, deactivate, edit, import, export, and delete them. An example of a pattern-based detector is a user-defined detector using a pattern in the packet header to detect traffic for a custom application.

Keep in mind that the detector list may change depending on the version of the FireSIGHT System and the VDB you have installed, as well as on any individual detectors you may have imported or created. You should carefully read the release notes for each FireSIGHT System update as well as the advisories for each VDB update for information on updated detectors.

For more information, see:

- Understanding Application Detection

- Creating a User-Defined Application Protocol Detector

- Managing Detectors

Creating a User-Defined Application Protocol Detector

License: FireSIGHT

If you use custom applications on your network, you can create user-defined application protocol detectors that provide the system with the information it needs to identify those applications. You can base application protocol detection on the port or ports used by application traffic, patterns within the traffic, or on both ports and patterns.

For example, if you expect traffic for a custom application protocol to use port 1180, you can create an application protocol detector that detects traffic on that port. As another example, if you know that the header for any packet containing application protocol traffic has a string of ApplicationName in it, you can create a detector that registers the ASCII string of ApplicationName as a pattern to match.

You can create user-defined application detectors only for application protocols, not for clients or for web applications. For an explanation of each, see Understanding Application Detection. Client sessions must include a responder packet from the server for the system to begin detecting and identifying application protocols in server traffic. Note that, for UDP traffic, the system designates the source of the responder packet as the server.

User-defined application protocol detectors must use either a port or a pattern match; you cannot create a detector that uses neither, even if you base the detector on an existing detector. You can also create a detector that uses both criteria; this increases the likelihood of correctly identifying traffic for that application protocol.

Tip If you have already created a detector on another Defense Center, you can export it and then import it onto this Defense Center. You can then edit the imported detector to suit your needs. You can export and import user-defined detectors as well as detectors provided by Cisco Professional Services. However, you cannot export or import any other type of Cisco-provided detectors. For more information, see Importing and Exporting Configurations.

To create a user-defined application protocol detector:

Access: Admin/Discovery Admin

Step 1 Select Policies > Application Detectors.

The Detectors page appears.

Step 2 Click Create Detector.

The Create Detector page appears.

Step 3 Provide basic detector information, such as the detector name and description.

See Providing Basic Application Protocol Detector Information.

Step 4 Optionally, create a user-defined application for the detector.

See Creating a User-Defined Application.

Step 5 Provide detection criteria, including the protocol of traffic the detector should inspect and the port that the traffic uses.

See Specifying Detection Criteria for Application Protocol Detectors.

Step 6 Optionally, configure the detector to inspect traffic for matches to one or more patterns that occurs in traffic for that application protocol.

See Adding Detection Patterns to an Application Protocol Detector.

Step 7 Optionally, test the new detector against the contents of one or more PCAP files.

See Testing an Application Protocol Detector Against Packet Captures.

Step 8 Click Save.

The application protocol detector is saved.

Note You must activate the detector before the system can use it to analyze application protocol traffic. For more information, see Activating and Deactivating Detectors. Note that if you include the application in an access control rule, the detector is automatically activated and cannot be deactivated while in use.

Providing Basic Application Protocol Detector Information

License: FireSIGHT

You must give each user-defined application protocol detector a name, as well as identify the application protocol you want to detect. Optionally, you can provide a brief description of the detector.

In addition to the information you provide, the Defense Center indicates whether the detector is active or inactive, and whether the detector is a port or pattern detector. If a detector identifies application protocol traffic by port and pattern, the FireSIGHT System considers it a pattern detector.

If you are editing an existing detector, the Defense Center also displays the detector’s author. If you created a user-defined application protocol detector, you are the author. You are also the author for any detector that you import or that you edit and save.

To provide basic application protocol detector information:

Access: Admin/Discovery Admin

Step 1 On the Create Detector page, in the Please enter a name field, type a name for the detector.

Detector names must be unique within the protocol for the traffic you are inspecting. That is, you can create a TCP detector and a UDP detector with the same name, but you cannot create two TCP detectors with the same name.

Step 2 Identify the application protocol you want to detect. You have the following options:

- If you are creating a detector for an existing application protocol (for example, if you want to detect a particular application protocol on a non-standard port), select the application protocol from the Application Protocol drop-down list. Continue with the procedure in Specifying Detection Criteria for Application Protocol Detectors.

- If you are creating a detector for a custom application, continue with the procedure in the next section, Creating a User-Defined Application.

Creating a User-Defined Application

License: FireSIGHT

You can create a user-defined application to identify a custom application on your network. You can also create custom categories and custom tags to describe the application. Applications, categories, and tags created here are available in access control rules and in the application filter object manager as well.

For more information on application detection, including a discussion of application protocols and the categories, tags, risk levels, and business relevance used to describe them, see Understanding Application Detection.

To create a user-defined application:

Access: Admin/Discovery Admin

Step 1 On the Create Detector page, click Add.

The Application Editor pop-up window appears.

Step 2 Type a Name for the custom application.

Step 3 Type a Description for the custom application.

Step 4 Select a Business Relevance.

Step 5 Select a Risk.

Step 6 Click Add next to Categories to add a category and type a new category name or select an existing category from the Categories drop-down list.

Step 7 Optionally, click Add next to Tags to add a tag and type a new tag name or select an existing tag from the Tags drop-down list.

Click OK to return to the Create Detector page.

Step 8 Continue with the procedure in the next section, Specifying Detection Criteria for Application Protocol Detectors.

Specifying Detection Criteria for Application Protocol Detectors

License: FireSIGHT

When creating a user-defined application protocol detector, you must specify the protocol of traffic (TCP, UDP, or both) the detector should inspect. Optionally, you can specify a port that the traffic uses.

Note that if you do not specify a port, you must configure the detector to inspect traffic for matches to one or more patterns, as described in Adding Detection Patterns to an Application Protocol Detector.

To specify detection criteria for an application protocol detector:

Access: Admin/Discovery Admin

Step 1 On the Create Detector page, from the Protocol drop-down list, select the protocol for traffic the detector should inspect.

Detectors can inspect TCP, UDP, or TCP and UDP traffic.

Step 2 Optionally, to identify application protocol traffic based on the port it uses, type a port from 1 to 65535 in the Port(s) field. To use multiple ports, separate them by commas.

Step 3 You have the following options:

- If you want to configure the application protocol detector to inspect traffic for matches to one or more patterns that occurs in traffic for that application protocol, continue with the procedure in the next section, Adding Detection Patterns to an Application Protocol Detector.

- If you want to test the new detector against the contents of one or more PCAP files, skip to Testing an Application Protocol Detector Against Packet Captures.

- If you are done creating the detector, click Save .

The application protocol detector is saved.

Note that you must activate the detector before the system can use it to analyze application protocol traffic. For more information, see Activating and Deactivating Detectors.

Adding Detection Patterns to an Application Protocol Detector

License: FireSIGHT

If you know that the header for any packet containing application protocol traffic contains a particular pattern string, you can configure a user-defined application protocol detector to search for that pattern.

Application protocol detectors can search for ASCII or hexadecimal patterns, using any offset. You can also configure detectors to search for multiple patterns; in that case the application protocol traffic must match all of the patterns for the detector to positively identify the application protocol.

Note that if you do not specify a pattern, you must configure the detector to inspect traffic that uses one or more ports, as described in Specifying Detection Criteria for Application Protocol Detectors.

To add a detection pattern to an application protocol detector:

Access: Admin/Discovery Admin

Step 1 On the Create Detector page, in the Detection Patterns section, click Add.

The Add Pattern pop-up window appears.

Step 2 Specify the pattern type you want to detect: Ascii or Hex.

Step 3 Type a string of the type you specified in the Pattern String field.

Step 4 Optionally, specify where in a packet the system should begin searching for the pattern; this is called the offset.

Type the offset (in bytes from the beginning of the packet payload) in the Offset field.

Because packet payloads start at byte 0, calculate the offset by subtracting 1 from the number of bytes you want to move forward from the beginning of the packet payload. For example, to look for the pattern in the fifth bit of the packet, type 4 in the Offset field.

Step 5 Optionally, repeat steps 1 to 4 to add additional patterns.

Step 6 You have the following options:

- If you want to test the new detector against the contents of one or more PCAP files, continue with the procedure in the next section, Testing an Application Protocol Detector Against Packet Captures.

- If you are done creating the detector, click Save .

The application protocol detector is saved.

Note You must activate the detector before the system can use it to analyze application protocol traffic. For more information, see Activating and Deactivating Detectors.

Testing an Application Protocol Detector Against Packet Captures

License: FireSIGHT

If you have a packet capture (PCAP) file that contains packets with traffic from the application protocol you want to detect, you can test a user-defined application protocol detector against that PCAP file. Note that PCAP files must be 32KB or smaller; if you try to test your detector against a larger PCAP file, the Defense Center automatically truncates it.

To test an application protocol detector against a PCAP file:

Access: Admin/Discovery Admin

Step 1 On the Create Detector page, in the Packet Captures section, click Add.

A pop-up window appears.

Step 2 Browse to the PCAP file and click OK.

The PCAP file appears in the Packet Captures file list.

Step 3 To test your detector against the contents of the PCAP file, click the evaluate icon next to the PCAP file.

A message appears, indicating whether the test succeeded.

Step 4 Optionally, repeat steps 1 to 3 to test the detector against additional PCAP files.

Step 5 To save the detector, click Save.

Note You must activate the detector before the system can use it to analyze application protocol traffic. For more information, see Activating and Deactivating Detectors.

Managing Detectors

License: FireSIGHT

You view and manage detectors on the Detectors page.

From the Detectors page, you can:

- view details about the application the detector identifies

- sort, filter, and browse the list of detectors

- view a list of the Cisco-provided internal detectors

- view the properties of the Cisco-provided application protocol port detectors, and optionally save copies as new, user-defined detectors that you can modify

- create, modify, delete, and export user-defined application protocol detectors

- delete and export any application protocol detectors you individually imported

- activate and deactivate user-defined, imported, or Cisco-provided web application, client, and application protocol detectors

Note that you cannot modify or delete internal or Cisco-provided application protocol, client, or web application detectors and cannot deactivate internal detectors.

For more information, see:

- Viewing Detector Details

- Sorting the Detector List

- Filtering the Detector List

- Navigating to Other Detector Pages

- Activating and Deactivating Detectors

- Modifying Application Detectors

- Deleting Detectors

Viewing Detector Details

License: FireSIGHT

You can view more detail on a detector from the application detectors list.

To view application detector details:

Access: Admin/Discovery Admin

) in the Details column.

The information pop-up window for the detector appears.

For more information on risk, business relevance, tags, and categories, see Understanding Application Detection.

Sorting the Detector List

License: FireSIGHT

) or down arrow next to a column heading indicates that the page is sorted by that column in that direction.

To sort detectors:

Access: Admin/Discovery Admin

Step 1 On the Detectors page, click the appropriate column heading.

The detectors are sorted in the direction indicated by the arrow that appears on the column heading. To sort in the opposite direction, click the heading again.

Filtering the Detector List

License: FireSIGHT

You can filter the detectors you display on the Detectors page by a single criterion, or a combination of multiple criteria. The filter you construct is shown at the top of the page. You can use several filter groups, separately or in combination, to filter the list of detectors.

Name

Finds detectors with names or descriptions containing the string you type. Strings can contain any alphanumeric or special character.

Custom Filter

Finds detectors matching a custom application filter created on the object management page. For more information, see Working with Application Filters.

Author

Finds detectors according to who created the detector. You can filter detectors by:

– any individual user who has created or imported a detector

– Cisco, which represents all Cisco-provided detectors except individually imported add-on detectors; you are the author for any detector that you import

– Any User, which represents all detectors not provided by Cisco

State

Finds detectors according to their state, that is, Active or Inactive. For more information, see Activating and Deactivating Detectors.

Type

Finds detectors according to the detector type: Application Protocol, Web Application, Client, or Internal Detector.

Application protocol detectors have three subtypes you can use to further filter detectors:

– Port application protocol detectors include the Cisco-provided well-known port detectors, as well as any port-based user-defined application detectors.

– Pattern application protocol detectors include pattern-based or port-and-pattern-based user-defined application detectors.

– FireSIGHT application protocol detectors are application protocol fingerprint detectors provided by Cisco that can be activated and deactivated.

For more information on detector types, see Working with Application Detectors.

Protocol

Finds detectors according to which traffic protocol the detector inspects. Detectors can inspect TCP, UDP, or TCP and UDP traffic.

Category

Finds detectors according to the categories assigned to the application they detect.

Tag

Finds detectors according to the tags assigned to the application they detect.

Risk

Finds detectors according to the risks assigned to the application they detect: Very High, High, Medium, Low, and Very Low.

Business Relevance

Finds detectors according to the business relevance assigned to the application they detect: Very High, High, Medium, Low, and Very Low.

To apply a filter:

Admin/Discovery Admin

Step 1 On the Detectors page, expand the filter group you want to use to filter the detectors.

Step 2 Type the name or select the specific filter you want to use. To select all filters in a group, right-click the group name and select Check All.

Step 3 Optionally, if the filter you are using has subfilters, select the subfilter to further filter the detectors.

To remove a filter:

Access: Admin/Discovery Admin

.

The filter is removed and the results update.

To remove all filters:

Access: Admin/Discovery Admin

Step 1 Click Clear all next to the list of filters applied to the detectors.

Navigating to Other Detector Pages

License: FireSIGHT

The Detectors page displays 25 detectors at a time. The following table explains how to view additional pages of detectors using the navigation links at the bottom of the page.

Table 46-1 Navigating Detector Pages

To...

You can...

view the next page

).

view the previous page

).

view a different page

type the page number and press Enter.

jump to the last page

).

jump to the first page

).

Activating and Deactivating Detectors

License: FireSIGHT

You must activate a detector before you can use it to analyze network traffic. By default, all Cisco-provided detectors are activated.

You can activate multiple application detectors for each port to supplement the system’s detection capability.

When you include an application in an access control rule in a policy and that policy is applied, if there is no active detector for that application, one or more detectors automatically activate. Similarly, while an application is in use in an applied policy, you cannot deactivate a detector if deactivating leaves no active detectors for that application.

Tip For improved performance, deactivate any application protocol, client, or web application detectors you are not interested in.

To activate or deactivate a detector:

Access: Admin/Discovery Admin

Step 1 Select Policies > Application Detectors.

The Detectors page appears.

Step 2 Locate the detector you want to activate or deactivate.

If the detector you want to activate or deactivate is not on the first page, you can find it by paging through the detector list or applying one or more filters. For more information, see Managing Detectors.

Step 3 You have the following options:

- To activate a detector, so that the system will use it when analyzing network traffic, click the deactivated slider (

) next to the detector.

- To deactivate a detector so that the system will not use it when analyzing network traffic, click the activated slider (

) next to the detector.

Note that some application detectors are required by other detectors. If you deactivate one of these detectors, a warning appears to indicate that the detectors that depend on it are also disabled.

Modifying Application Detectors

License: FireSIGHT

Use the following procedure to modify user-defined application detectors.

To modify an application detector:

Access: Admin/Discovery Admin

Step 1 Select Policies > Applications.

The Detectors page appears.

Step 2 Locate the detector you want to modify.

If the detector you want to modify is not on the first page, you can find it by paging through the detector list or applying one or more filters. For more information, see Managing Detectors.

Step 3 To modify a user-defined detector, click Edit next to the detector you want to modify.

The Edit Application Detector page appears.

Step 4 Make changes to the detector.

See Creating a User-Defined Application Protocol Detector for information on the various configurations you can change.

Step 5 You have the following options:

- If you are modifying an inactive user-defined detector, either click Save to save your changes, or click Save as New to save the detector as a new, inactive user-defined detector.

- If you are modifying an active user-defined detector, either click Save and Reactivate to save your changes and immediately start using the modified detector, or click Save as New to save the detector as a new, inactive user-defined detector.

Note The system only uses applications with active detectors to analyze application traffic. For more information, see Activating and Deactivating Detectors.

Deleting Detectors

License: FireSIGHT

Use the following procedure to delete a detector. You can delete user-defined detectors as well as individually imported add-on detectors provided by Cisco Professional Services. You cannot delete any of the other Cisco-provided detectors, though you can deactivate many of them.

Note While a detector is in use in an applied policy, you cannot deactivate or delete the detector.

To delete a detector:

Access: Admin/Discovery Admin

Step 1 Select Policies > Application Detectors.

The Detectors page appears.

Step 2 Select the check box next to the detector you want to delete and click Delete.

If the detector you want to delete is not on the first page, you can find it by paging through the detector list or applying one or more filters. For more information, see Managing Detectors.

Step 3 Click OK to confirm that you want to delete the detector.

The detector is deleted.

Importing Host Input Data

License: FireSIGHT

If your organization has the capability to write scripts or create command line import files to import network map data from third parties, you can import data to augment the information in the network map. You can also use the host input feature by modifying operating system or application identities or deleting application protocols, protocols, host attributes, or clients using the web interface.

The system may reconcile data from multiple sources to determine the current identity of an operating system or application. For more information on how the system does this, see Understanding Current Identities.

Note that all data except third-party vulnerabilities is discarded when the affected host is removed from the network map. For more information on setting up scripts or import files, see the FireSIGHT System Host Input API Guide.

To include imported data in impact correlations, you must map the data to the operating system and application definitions in the database. For more information, see the following sections:

- Enabling the Use of Third-Party Data

- Managing Third-Party Product Mappings

- Mapping Third-Party Vulnerabilities

- Managing Custom Product Mappings

Enabling the Use of Third-Party Data

License: FireSIGHT

You can import network map data from third-party systems on your network. However, to enable features where intrusion and discovery data are used together, such as FireSIGHT recommendations, adaptive profiles, or impact assessment, you should map as many elements of it as possible to corresponding definitions. Consider the following requirements for using third-party data:

- If you have a third-party system that has specific data on your network assets, you can import that data using the host input feature. However, because third parties may name the products differently, you must map the third-party vendor, product, and versions to the corresponding Cisco product definition. After you map the products, you must enable vulnerability mappings for impact assessment in the system policy to allow impact correlation. For versionless or vendorless application protocols, you need to map vulnerabilities for the application protocols in the system policy. For more information, see Mapping Third-Party Products.

- If you import patch information from a third party and you want to mark all vulnerabilities fixed by that patch as invalid, you must map the third-party fix name to a fix definition in the database. All vulnerabilities addressed by the fix will then be removed from hosts where you add that fix. For more information, see Mapping Third-Party Product Fixes.

- If you import operating system and application protocol vulnerabilities from a third party and you want to use them for impact correlation, you must map the third-party vulnerability identification string to vulnerabilities in the database. Note that although many clients have associated vulnerabilities, and clients are used for impact assessment, you cannot import and map third-party client vulnerabilities. After the vulnerabilities are mapped, you must enable third-party vulnerability mappings for impact assessment in the system policy. For more information, see Mapping Third-Party Vulnerabilities. To cause application protocols without vendor or version information to map to vulnerabilities, an administrative user must also map vulnerabilities for the applications in the system policy. For more information, see Mapping Vulnerabilities for Servers.

- If you import application data and you want to use that data for impact correlation, you must map the vendor string for each application protocol to the corresponding Cisco application protocol definition. For more information, see Managing Custom Product Mappings.

Managing Third-Party Product Mappings

License: FireSIGHT

When you add data from third parties to the network map through the user input feature, you must map the vendor, product, and version names used by the third party to the Cisco product definitions. Mapping the products to Cisco definitions assigns vulnerabilities based on those definitions.

Similarly, if you are importing patch information from a third party, such as a patch management product, you must map the name for the fix to the appropriate vendor and product and the corresponding fix in the database.

For more information, see the following sections:

- Mapping Third-Party Products

- Mapping Third-Party Product Fixes

Mapping Third-Party Products

License: FireSIGHT

If you import data from a third party, you must map the Cisco product to the third-party name to assign vulnerabilities and perform impact correlation using that data. Mapping the product associates Cisco vulnerability information with the third-party product name, which allows the system to perform impact correlation using that data.

If you import data using the host input import feature, you can also use the AddScanResult function to map third-party products to operating system and application vulnerabilities during the import.

As an example, if you import data from a third party that lists Apache Tomcat as an application and you know it is version 6 of that product, you could add a third-party map where Vendor Name is set to Apache, Product Name is set to Tomcat, Apache is selected from the Vendor drop-down list, Tomcat is selected from the Product drop-down list, and 6 is selected from the Version drop-down list. That mapping would cause any vulnerabilities for Apache Tomcat 6 to be assigned to hosts with an application listing for Apache Tomcat.

Note that for versionless or vendorless applications, you must map vulnerabilities for the application types in the system policy. For more information, see Mapping Vulnerabilities for Servers. Note that although many clients have associated vulnerabilities, and clients are used for impact assessment, you cannot import and map third-party client vulnerabilities.

Tip If you have already created a third-party mapping on another Defense Center, you can export it and then import it onto this Defense Center. You can then edit the imported mapping to suit your needs. For more information, see Importing and Exporting Configurations.

To map a third-party product to a Cisco product definition:

Access: Admin

Step 1 Select Policies > Application Detectors, then click User Third-Party Mappings.

The User Third-Party Mappings page appears.

Step 2 You have two choices:

- To edit an existing map set, click Edit next to the map set.

- To create a new map set, click Create Product Map Set .

The Edit Third-Party Product Mappings page appears.

Step 3 Type a name for the mapping set in the Mapping Set Name field.

Step 4 Type a description in the Description field.

Step 5 You have two choices:

- To map a third-party product, click Add Product Map.

- To edit an existing third-party product map, click Edit next to the map set.

The Add Product Map page appears.

Step 6 Type the vendor string used by the third-party product in the Vendor String field.

Step 7 Type the product string used by the third-party product in the Product String field.

Step 8 Type the version string used by the third-party product in the Version String field.

Step 9 In the Product Mappings section, select the operating system, product, and versions you want to use for vulnerability mapping from the following lists (if applicable):

- Vendor

- Product

- Major Version

- Minor Version

- Revision Version

- Build

- Patch

- Extension

For example, if you want a host running a product whose name consists of third-party strings to use the vulnerabilities from Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Step 10 Click Save.

Mapping Third-Party Product Fixes

License: FireSIGHT

If you map a fix name to a particular set of fixes in the database, you can then import data from a third-party patch management application and apply the fix to a set of hosts. When the fix name is imported to a host, the system marks all vulnerabilities addressed by the fix as invalid for that host.

To map third-party fixes to Cisco fix definitions:

Access: Admin/

Step 1 Select Policies > Application Detectors, then click User Third-Party Mappings.

The User Third-Party Mappings page appears.

Step 2 You have two choices:

- To edit an existing map set, click Edit next to the map set.

- To create a new map set, click Create Product Map Set .

The Edit Third-Party Product Mappings page appears.

Step 3 Type a name for the mapping set in the Mapping Set Name field.

Step 4 Type a description in the Description field.

Step 5 You have two choices:

- To map a third-party product, click Add Fix Map.

- To edit an existing third-party product map, click Edit next to it.

The Add Fix Map page appears.

Step 6 Type the name of the fix you want to map in the Third-Party Fix Name field.

Step 7 In the Product Mappings section, select the operating system, product, and versions you want to use for fix mapping from the following lists (if applicable):

- Vendor

- Product

- Major Version

- Minor Version

- Revision Version

- Build

- Patch

- Extension

For example, if you want your mapping to assign the selected fixes from Red Hat Linux 9 to hosts where the patch is applied, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Step 8 Click Save to save the fix map.

Mapping Third-Party Vulnerabilities

License: FireSIGHT

To add vulnerability information from a third party to the VDB, you must map the third-party identification string for each imported vulnerability to any existing Cisco, Bugtraq, or Snort ID. After you create a mapping for the vulnerability, the mapping works for all vulnerabilities imported to hosts in your network map and allows impact correlation for those vulnerabilities.

Note that you must also enable impact correlation for third-party vulnerabilities to allow correlation to occur. For more information, see Enabling Vulnerability Impact Assessment Mappings. For versionless or vendorless applications, you must also map vulnerabilities for the application types in the system policy. For more information, see Mapping Vulnerabilities for Servers.

Also, although many clients have associated vulnerabilities, and clients are used for impact assessment, you cannot use third-party client vulnerabilities for impact assessment.

Tip If you have already created a third-party mapping on another Defense Center, you can export it and then import it onto this Defense Center. You can then edit the imported mapping to suit your needs. For more information, see Importing and Exporting Configurations.

To map a third-party vulnerability to an existing vulnerability:

Access: Admin

Step 1 Select Policies > Application Detectors, then click User Third-Party Mappings.

The User Third-Party Mappings page appears.

Step 2 You have two choices:

- To edit an existing vulnerability set, click Edit next to the vulnerability set.

- To create a new vulnerability set, click Create Vulnerability Map Set .

The Edit Third-Party Vulnerability Mappings page appears.

Step 3 Click Add Vulnerability Map.

The Add Vulnerability Map pop-up window appears.

Step 4 Type the third-party identification for the vulnerability in the Vulnerability ID field.

Step 5 Type a description in the Vulnerability Description field.

Step 6 Optionally, enter a Signature ID in the Snort Vulnerability ID Mappings field.

Step 7 Optionally, enter an Cisco vulnerability ID in the Cisco Vulnerability ID Mappings field.

Step 8 Optionally, enter a Bugtraq identification number in the Bugtraq Vulnerability ID Mappings field.

Step 9 Click Add.

Managing Custom Product Mappings

License: FireSIGHT

You can use product mappings to ensure that servers input by a third party are associated with the appropriate Cisco definitions. After you define and activate the product mapping, all servers or clients on hosts in your network map that have the mapped vendor strings use the custom product mappings. For this reason, you may want to map vulnerabilities for all servers in the network map with a particular vendor string instead of explicitly setting the vendor, product, and version for the server.

For more information, see the following:

- Creating Custom Product Mappings

- Editing Custom Product Mapping Lists

- Managing Custom Product Mapping Activation State

Creating Custom Product Mappings

License: FireSIGHT

If the system cannot map a server in the network map to a vendor and product in the VDB, you can manually create the mapping for the system to use when identifying servers. When you activate a custom product mapping, the system maps vulnerabilities for the selected vendor and product to all servers in the network map where that vendor string occurs.

Note Custom product mappings apply to all occurrences of an application protocol, regardless of the source of the application data (such as Nmap, the host input feature, or the FireSIGHT System itself). However, if third-party vulnerability mappings for data imported using the host input feature conflicts with the mappings you set through a custom product mapping, the third-party vulnerability mapping overrides the custom product mapping and uses the third-party vulnerability mapping settings when the input occurs. For more information, see Mapping Third-Party Vulnerabilities.

You create lists of product mappings and then enable or disable use of several mappings at once by activating or deactivating each list. When you select a vendor to map to, the system updates the list of products to include only those made by that vendor.

After you create a custom product mapping, you must activate the custom product mapping list. After you activate a list of custom product mappings, the system updates all servers with occurrences of the specified vendor strings. For data imported through the host input feature, vulnerabilities update unless you have already explicitly set the product mappings for this server.

If, for example, your company modifies the banner for your Apache Tomcat web servers to read Internal Web Server, you can map the vendor string Internal Web Server to the vendor Apache and the product Tomcat, then activate the list containing that mapping, all hosts where a server labelled Internal Web Server occurs have the vulnerabilities for Apache Tomcat in the database.

Tip You can use this feature to map vulnerabilities to local intrusion rules by mapping the SID for the rule to another vulnerability.

To create a custom product mapping:

Access: Admin

Step 1 Select Policies > Application Detectors, and click Custom Product Mappings.

The Custom Product Mappings page appears.

Step 2 Click Create Custom Product Mapping List.

The Edit Custom Product Mappings List page appears.

Step 3 Type a name in the Custom Product Mapping List Name field.

Step 4 Click Add Vendor String.

The Add Vendor String pop-up window appears.

Step 5 In the Vendor String field, type the vendor string that identifies the applications that should map to the selected vendor and product values.

Step 6 Select the vendor you want to map to from the Vendor drop-down list.

Step 7 Select the product you want to map to from the Product drop-down list.

Step 8 Click Add to add the mapped vendor string to the list.

Step 9 Optionally, repeat steps 4 to 8 as needed to add additional vendor string mappings to the list.

Step 10 When you finish, click Save.

The Custom Product Mappings page appears again, with the list you added.

Editing Custom Product Mapping Lists

License: FireSIGHT

You can modify existing custom product mapping lists by adding or removing vendor strings or changing the list name.

To edit a custom product mapping:

Access: Admin

Step 1 Select Policies > Application Detectors, then click Custom Product Mappings.

The Custom Product Mappings page appears.

) next to the product mapping list to edit.

The Edit Custom Product Mappings List page appears.

Step 3 Make changes to the list as needed. For more information, see Creating Custom Product Mappings.

Step 4 When you finish, click Save.

The Custom Product Mappings page appears, with the list you updated.

Managing Custom Product Mapping Activation State

License: FireSIGHT

You can enable or disable use of an entire list of custom product mappings at once. After you activate a custom product mapping list, each mapping on that list applies to all applications on hosts in the network map with the specified vendor string, whether detected by managed devices or imported through the host input feature.

To activate or deactivate a custom product mapping list:

Access: Admin

Step 1 Select Policies > Application Detectors, then click Custom Product Mappings.

The Custom Product Mappings page appears.

Step 2 Modify the state of custom product mapping lists:

- To enable use of a custom product mapping list, click Activate .

- To disable use of a custom product mapping list, click Deactivate .

Configuring Active Scanning

The FireSIGHT System builds a network map through passive analysis of traffic on your network. However, you may sometimes need to actively scan a host to determine information about that host. For example, if a host has a server running on an open port but the server has not received or sent traffic during the time that the system has been monitoring your network, the system does not add information about that server to the network map. If you directly scan that host using an active scanner, however, you can detect the presence of the server.

When you actively scan a host, you send packets in an attempt to obtain information about the host. The FireSIGHT System integrates with Nmap™ 6.01, an open source active scanner for network exploration and security auditing that can be used to detect operating systems and servers running on a host. With an Nmap scan, you can check for detailed information about the operating system and servers running on the host and refine the system’s vulnerability reporting based on those results.

Note Some scanning options (such as portscans) may place a significant load on networks with low bandwidths. You should always schedule scans like these to run during periods of low network use.

For more information, see the following sections:

- Understanding Nmap Scans

- Setting up Nmap Scans

- Managing Nmap Scanning

- Managing Scan Targets

- Working with Active Scan Results

Understanding Nmap Scans

License: FireSIGHT

Nmap allows you to actively scan ports on hosts on your network to determine operating system and server data for the hosts, which allows you to enhance your network map and fine-tune the accuracy of the vulnerabilities mapped to scanned hosts. Note that a host must exist in the network map before Nmap can append its results to the host profile. You can also view scan results in a results file.

When you scan a host using Nmap, servers on previously undetected open ports are added to the Servers list in the host profile for that host. The host profile lists any servers detected on filtered or closed TCP ports or on UDP ports in the Scan Results section. By default, Nmap scans more than 1660 TCP ports.

Nmap compares the results of the scan to over 1500 known operating system fingerprints to determine the operating system and assigns scores to each. The operating system assigned to the host is the operating system fingerprint with the highest score.

If the system recognizes a server identified in an Nmap scan and has a corresponding server definition, the system maps vulnerabilities for that server to the host. The system maps the names Nmap uses for servers to the corresponding Cisco server definitions, and then uses the vulnerabilities mapped to each server in the system. Similarly, the system maps Nmap operating system names to Cisco operating system definitions. When Nmap detects an operating system for a host, the system assigns vulnerabilities from the corresponding Cisco operating system definition to the host.

For more information the underlying Nmap technology used to scan, refer to the Nmap documentation at http://insecure.org.

For more information on Nmap on your Cisco appliance, see the following topics:

- Understanding Nmap Remediations

- Creating an Nmap Scanning Strategy

- Sample Nmap Scanning Profiles

Understanding Nmap Remediations

License: FireSIGHT

You can define the settings for an Nmap scan by creating an Nmap remediation. An Nmap remediation can be used as a response in a correlation policy, run on demand, or scheduled to run at a specific time. In order for the results of an Nmap scan to appear in the network map, the scanned host must already exist in the network map.

Note that Nmap-supplied server and operating system data remain static until you run another Nmap scan. If you plan to scan a host for operating system and server data using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up-to-date. For more information, see Automating Nmap Scans. Also note that if the host is deleted from the network map, any Nmap scan results for that host are discarded.

For more information about Nmap functionality, refer to the Nmap documentation at http://insecure.org. The following table explains the options configurable in Nmap remediations on a FireSIGHT System.

Table 47-1 Nmap Remediation Options

Option

Description

Corresponding Nmap Option

Scan Which Address(es) From Event?

When you use an Nmap scan as a response to a correlation rule, select an option to control which address in the event is scanned, that of the source host, the destination host, or both.

N/A

Scan Types

Select how Nmap scans ports:

- The TCP Syn scan connects quickly to thousand of ports without using a complete TCP handshake. This options allows you to scan quickly in stealth mode on hosts where the admin account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them. If a host acknowledges the Syn packet sent in a TCP Syn scan, Nmap resets the connection.

- The TCP Connect scan uses the connect() system call to open connections through the operating system on the host. You can use the TCP Connect scan if the admin user on your Defense Center or managed device does not have raw packet privileges on a host or you are scanning IPv6 networks. In other words, use this option in situations where the TCP Syn scan cannot be used.

- The TCP ACK scan sends an ACK packet to check whether ports are filtered or unfiltered.

- The TCP Window scan works in the same way as a TCP ACK scan but can also determine whether a port is open or closed.

- The TCP Maimon scan identifies BSD-derived systems using a FIN/ACK probe.

TCP Syn: -sS

TCP Connect: -sT

TCP ACK: -sA

TCP Window: -sW

TCP Maimon: -sM

Scan for UDP ports

Enable to scan UDP ports in addition to TCP ports. Note that scanning UDP ports may be time-consuming, so avoid using this option if you want to scan quickly.

-sU

Use Port From Event

If you plan to use the remediation as a response in a correlation policy, enable to cause the remediation to scan only the port specified in the event that triggers the correlation response.
option to scan the port associated with the new server.

N/A

Scan from reporting detection engine

Enable to scan a host from the appliance where the detection engine that reported the host resides.

N/A

Fast Port Scan

Enable to scan only the TCP ports listed in the nmap-services file located in the /var/sf/nmap/share/nmap/nmap-services directory on the device that does the scanning, ignoring other port settings. Note that you cannot use this option with the Port Ranges and Scan Order option.

-F

Port Ranges and Scan Order

Set the specific ports you want to scan, using Nmap port specification syntax, and the order you want to scan them. Note that you cannot use this option with the Fast Port Scan option.

-p

Probe open ports for vendor and version information

Enable to detect server vendor and version information. If you probe open ports for server vendor and version information, Nmap obtains server data that it uses to identify servers. It then replaces the Cisco server data for that server.

-sV

Service Version Intensity

Select the intensity of Nmap probes for service versions. Higher service intensity numbers cause more probes to be used and result in higher accuracy, while lower intensity probes are faster but obtain less information.

--version-intensity <intensity>

Detect Operating System

Enable to detect operating system information for the host.

If you configure detection of the operating system for a host, Nmap scans the host and uses the results to create a rating for each operating system that reflects the likelihood that the operating system is running on the host. For more information on when and how Nmap-identified identity data appears in the network map, see Understanding Current Identities.

-o

Treat All Hosts As Online

Enable to skip the host discovery process and run a port scan on every host in the target range. Note that when you enable this option, Nmap ignores settings for Host Discovery Method and Host Discovery Port List.

-PN

Host Discovery Method

Select to perform host discovery for all hosts in the target range, over the ports listed in the Host Discovery Port List, or if no ports are listed, over the default ports for that host discovery method.

Note that if you also enabled Treat All Hosts As Online, however, the Host Discovery Method option has no effect and host discovery is not performed.

Select the method to be used when Nmap tests to see if a host is present and available:

- The TCP SYN option sends an empty TCP packet with the SYN flag set and recognizes the host as available if a response is received. TCP SYN scans port 80 by default. Note that TCP SYN scans are less likely to be blocked by a firewall with stateful firewall rules.

- The TCP ACK option sends an empty TCP packet with the ACK flag set and recognizes the host as available if a response is received. TCP ACK also scans port 80 by default. Note that TCP ACK scans are less likely to be blocked by a firewall with stateless firewall rules.

- The UDP option sends a UDP packet and assumes host availability if a port unreachable response comes back from a closed port. UDP scans port 40125 by default.

TCP SYN: -PS

TCP ACK: -PA

UDP: -PU

Host Discovery Port List

Specify a customized list of ports, separated by commas, that you want to scan when doing host discovery.

port list for host discovery method

Default NSE Scripts

Enable to run the default set of Nmap scripts for host discovery and server and operating system and vulnerability detection. See http://nmap.org/nsedoc/categories/default.html for the list of default scripts.

-sC

Timing Template

Select the timing of the scan process; the higher the number you select, the faster and less comprehensive the scan.

0: T0 (paranoid)

1: T1 (sneaky)

2: T2 (polite)

3: T3 (normal)

4: T4 (aggressive)

5: T5 (insane)

Creating an Nmap Scanning Strategy

License: FireSIGHT

While active scanning can obtain valuable information, overuse of a tool such as Nmap may overload your network resources or even crash important hosts. When using any active scanner, you should create a scanning strategy to make sure that you are scanning only the hosts and ports that you need to scan.

For more information, see the following sections:

- Selecting Appropriate Scan Targets

- Selecting Appropriate Ports to Scan

- Setting Host Discovery Options

Selecting Appropriate Scan Targets

License: FireSIGHT

When you configure Nmap, you can create scan targets that identify which hosts you want to scan. A scan target includes a single IP address, a CIDR block or octet range of IP addresses, an IP address range, or a list of IP addresses or ranges to scan, as well as the ports on the host or hosts.

You can specify targets in the following ways:

- For IPv6 hosts:

– an exact IP address (for example, 192.168.1.101)

- For IPv4 hosts:

– an exact IP address (for example, 192.168.1.101) or a list of IP addresses separated by commas or spaces

– an IP address block using CIDR notation (for example, 192.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254, inclusive)

For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

– an IP address range using octet range addressing (for example, 192.168.0-255.1-254 scans all addresses in the 192.168.x.x range, except those that end in .0 and or .255)

– an IP address range using hyphenation (for example, 192.168.1.1 - 192.168.1.5 scans the six hosts between 192.168.1.1 and 192.168.1.5, inclusive)

– a list of addresses or ranges separated by commas or spaces (for example, for example, 192.168.1.0/24, 194.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254, inclusive and the 254 hosts between 194.168.1.1 and 194.168.1.254, inclusive)

Ideal scan targets for Nmap scans include hosts with operating systems that the system is unable to identify, hosts with unidentified servers, or hosts recently detected on your network. Remember that Nmap results cannot be added to the network map for hosts that do not exist in the network map.

Caution Nmap-supplied server and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up to date. For more information, see Automating Nmap Scans. Also note that if the host is deleted from the network map, any Nmap scan results are discarded. In addition, make sure you have permission to scan your targets. Using Nmap to scan hosts that do not belong to you or your company may be illegal.

Selecting Appropriate Ports to Scan

License: FireSIGHT

For each scan target you configure, you can select the ports you want to scan. You can designate individual port numbers, port ranges, or a series of port numbers and port ranges to identify the exact set of ports that should be scanned on each target.

By default, Nmap scans TCP ports 1 through 1024. If you plan to use the remediation as a response in a correlation policy, you can cause the remediation to scan only the port specified in the event that triggers the correlation response. If you run the remediation on demand or as a scheduled task, or if you do not use the port from the event, you can use other port options to determine which ports are scanned. You can choose to scan only the TCP ports listed in the nmap-services file, ignoring other port settings. You can also scan UDP ports in addition to TCP ports. Note that scanning for UDP ports may be time-consuming, so avoid using that option if you want to scan quickly. To select the specific ports or range of ports to scan, use Nmap port specification syntax to identify ports.

Setting Host Discovery Options

License: FireSIGHT

You can decide whether to perform host discovery before starting a port scan for a host, or you can assume that all the hosts you plan to scan are online. If you choose not to treat all hosts as online, you can choose what method of host discovery to use and, if needed, customize the list of ports scanned during host discovery. Host discovery does not probe the ports listed for operating system or server information; it uses the response over a particular port only to determine whether a host is active and available. If you perform host discovery and a host is not available, Nmap does not scan ports on that host.

Sample Nmap Scanning Profiles

License: FireSIGHT

The following scenarios provide examples of how Nmap might be used on your network:

- Example: Resolving Unknown Operating Systems

- Example: Responding to New Hosts

Example: Resolving Unknown Operating Systems

License: FireSIGHT

If the system cannot determine the operating system on a host on your network, you can use Nmap to actively scan the host. Nmap uses the information it obtains from the scan to rate the possible operating systems. It then uses the operating system that has the highest rating as the host operating system identification.

Using Nmap to challenge new hosts for operating system and server information deactivates the system’s monitoring of that data for scanned hosts. If you use Nmap to discover host and server operating system for hosts the system marks as having unknown operating systems, you may be able to identify groups of hosts that are similar. You can then create a custom fingerprint based on one of them to cause the system to associate the fingerprint with the operating system you know is running on the host based on the Nmap scan. Whenever possible, create a custom fingerprint rather than inputting static data through a third-party source like Nmap because the custom fingerprint allows the system to continue to monitor the host operating system and update it as needed.

To discover operating systems with Nmap:

Access: Admin/Discovery Admin

Step 1 Configure a scan instance for an Nmap module.

For more information, see Creating an Nmap Scan Instance.

Step 2 Create an Nmap remediation using the following settings:

- Enable Use Port From Event to scan the port associated with the new server.

- Enable Detect Operating System to detect operating system information for the host.

- Enable Probe open ports for vendor and version information to detect server vendor and version information.

- Enable Treat All Hosts as Online , because you know the host exists.

For information on creating Nmap remediations, see Creating an Nmap Remediation.

Step 3 Create a correlation rule that triggers when the system detects a host with an unknown operating system.

The rule should trigger when an discovery event occurs and the OS information for a host has changed and it meets the following conditions: OS Name is unknown.

For information on creating correlation rules, see Creating Rules for Correlation Policies.

Step 4 Create a correlation policy that contains the correlation rule.

For more information on creating correlation policies, see Creating Correlation Policies.

Step 5 In the correlation policy, add the Nmap remediation you created in step 2 as a response to the rule you created in step 3.

Step 6 Activate the correlation policy.

Step 7 Purge the hosts on your network map to force network discovery to restart and rebuild the network map.

Step 8 After a day or two, search for events generated by the correlation policy. Analyze the Nmap results for the operating systems detected on the hosts to see if there is a particular host configuration on your network that the system does not recognize.

For more information on analyzing Nmap results, see Analyzing Scan Results.

Step 9 If you find hosts with unknown operating systems whose Nmap results are identical, create a custom fingerprint for one of those hosts and use it to identify similar hosts in the future.

For more information, see Fingerprinting Clients.

Example: Responding to New Hosts

License: FireSIGHT

When the system detects a new host in a subnet where intrusions may be likely, you may want to scan that host to make sure you have accurate vulnerability information for it.

You can accomplish this by creating and activating a correlation policy that detects when a new host appears in this subnet, and that launches a remediation that performs an Nmap scan on the host.

After you activate the policy, you can periodically check the remediation status view (Policy & Response > Responses > Remediations > Status) to see when the remediation launched. The remediation’s dynamic scan target should include the IP addresses of the hosts it scanned as a result of the server detection. Check the host profile for those hosts to see if there are vulnerabilities that need to be addressed for the host, based on the operating system and servers detected by Nmap.

Caution If you have a large or dynamic network, detection of a new host may be too frequent an occurrence to respond to using a scan. To prevent resource overload, avoid using Nmap scans as a response to events that occur frequently. In addition, note that using Nmap to challenge new hosts for operating system and server information deactivates Cisco monitoring of that data for scanned hosts.

To scan in response to the appearance of a new host:

Access: Admin/Discovery Admin

Step 1 Configure a scan instance for an Nmap module.

For more information, see Creating an Nmap Scan Instance.

Step 2 Create an Nmap remediation using the following settings:

- Enable Use Port From Event to scan the port associated with the new server.

- Enable Detect Operating System to detect operating system information for the host.

- Enable Probe open ports for vendor and version information to detect server vendor and version information.

- Enable Treat All Hosts as Online , because you know the host exists.

For information on creating Nmap remediations, see Creating an Nmap Remediation.

Step 3 Create a correlation rule that triggers when the system detects a new host on a specific subnet.

The rule should trigger when a discovery event occurs and a new host is detected.

For information on creating correlation rules, see Creating Rules for Correlation Policies.

Step 4 Create a correlation policy that contains the correlation rule.

For more information on creating correlation policies, see Creating Correlation Policies.

Step 5 In the correlation policy, add the Nmap remediation you created in step 2 as a response to the rule you created in step 3.

Step 6 Activate the correlation policy.

Step 7 When you are notified of a new host, check the host profile to see the results of the Nmap scan and address any vulnerabilities that apply to the host.

Setting up Nmap Scans

License: FireSIGHT

To scan using Nmap, you must first configure a scan instance and a scan remediation. If you plan to schedule Nmap scans, you must also define a scan target.

For more information, see the following sections:

- Creating an Nmap Scan Instance

- Creating an Nmap Scan Target

- Creating an Nmap Remediation

Creating an Nmap Scan Instance

License: FireSIGHT

You can set up a separate scan instance for each Nmap module that you want to use to scan your network for vulnerabilities. You can set up scan instances for the local Nmap module on your Defense Center and for any devices you want to use to run scans remotely. The results of each scan are always stored on the Defense Center where you configure the scan, even if you run the scan from a remote device. To prevent accidental or malicious scanning of mission-critical hosts, you can create a blacklist for the instance to indicate the hosts that should never be scanned with the instance.

Note that you cannot add a scan instance with the same name as any existing scan instance.

To create a scan instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Click Add Nmap Instance.

The Instance Detail page appears.

Step 3 In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 4 In the Description field, specify a description with 0 to 255 alphanumeric characters, which can include spaces and special characters.

Step 5 Optionally, in the Black Listed Scan hosts field, specify any hosts or networks that should never be scanned with this scan instance, using the following syntax:

- For IPv6 hosts, an exact IP address (for example, 2001:DB8::fedd:eeff )

- For IPv4 hosts, an exact IP address (for example, 192.168.1.101 ) or an IP address block using CIDR notation (for example, 192.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254 , inclusive)

- Note that you cannot use an exclamation mark (!) to negate an address value.

If you specifically target a scan to a host that is in a blacklisted network, that scan will not run.

Step 6 Optionally, to run the scan from a remote device instead of the Defense Center, specify the IP address or name of the device as it appears in the Information page for the device in the Defense Center web interface, in the Remote Device Name field.

Step 7 Click Create.

The scan instance is created.

Creating an Nmap Scan Target

License: FireSIGHT

You can create and save scan targets that identify specific hosts and ports. Then, when you perform an on-demand scan or schedule a scan, you can use one of the saved scan targets.

For scans of targets with IPv4 addresses, you can use an IP address, a list of IP addresses, CIDR notation, or Nmap scan octets to select the hosts to scan. You can also specify a range of addresses using a hyphen. Separate addresses and ranges in a list with commas or spaces.

For scans of IPv6 addresses, use an IP address. Ranges are not supported.

Note that Nmap-supplied server and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up to date. For more information, see Automating Nmap Scans. Also note that if the host is deleted from the network map, any Nmap scan results for that host are discarded.

To create a scan target:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 On the toolbar, click Targets.

The Scan Target List page appears.

Step 3 Click Create Scan Target.

The Scan Target page appears.

Step 4 In the Name field, type the name you want to use for this scan target.

Step 5 In the IP Range text box, specify the host or hosts you want to scan, using the following syntax:

- for IPv6 hosts, an exact IP address (for example, 2001:DB8::fedd:eeff )

- for IPv4 hosts, an exact IP address (for example, 192.168.1.101 ) or comma-separated list of IP addresses

- for IPv4 hosts, an IP address block using CIDR notation (for example, 192.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254, inclusive)

For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

- for IPv4 hosts, an IP address range using octet range addressing (for example, 192.168.0-255.1-254 scans all addresses in the 192.168.x.x range, except those that end in .0 and or .255)

- for IPv4 hosts, an IP address range using hyphenation (for example, 192.168.1.1 - 192.168.1.5 scans the 6 hosts between 192.168.1.1 and 192.168.1.5, inclusive)

- for IPv4 hosts, a list of addresses or ranges separated by commas or spaces (for example, for example, 192.168.1.0/24, 194.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254, inclusive and the 254 hosts between 194.168.1.1 and 194.168.1.254, inclusive)

Note The IP Range text box accepts up to 255 characters. In addition, note that if you use a comma in a list of IP addresses or ranges in a scan target, the comma converts to a space when you save the target.

Step 6 In the Ports field, specify the ports you want to scan.

You can enter any of the following, using values from 1 to 65535:

- a port number

- a list of ports separated by commas

- a range of port numbers separated by a dash

- ranges of port numbers separated by dashes, separated by commas

Step 7 Click Save.

The scan target is created.

Creating an Nmap Remediation

License: FireSIGHT

You can define the settings for an Nmap scan by creating an Nmap remediation. An Nmap remediation can be used as a response in a correlation policy, run on demand, or scheduled to run at a specific time. In order for the results of an Nmap scan to appear in the network map, the scanned host must already exist in the network map.

For more information on the specific settings in an Nmap remediation, see Understanding Nmap Remediations.

Note that Nmap-supplied server and operating system data remains static until you run another Nmap scan. If you plan to scan a host for operating system and server data using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up-to-date. For more information, see Automating Nmap Scans. Also note that if the host is deleted from the network map, any Nmap scan results for that host are discarded.

For general information about Nmap functionality, refer to the Nmap documentation at http://insecure.org.

To create an Nmap remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Click Add Remediation next to the scan instance where you want to add a remediation.

The Edit Remediation page appears.

Step 3 In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 4 In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Step 5 If you plan to use this remediation in response to a correlation rule that triggers on an intrusion event, a connection event, or a user event, configure the Scan Which Address(es) From Event? option:

- Select Scan Source and Destination Addresses to scan the hosts represented by the source IP address and the destination IP address in the event.

- Select Scan Source Address Only to scan the host represented by the event’s source IP address.

- Select Scan Destination Address Only to scan the host represented by the event’s destination IP address.

If you plan to use this remediation in response to a correlation rule that triggers on a discovery event or a host input event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option.

Note Do not assign an Nmap remediation as a response to a correlation rule that triggers on a traffic profile change.

Step 6 Configure the Scan Type option:

- To scan quickly in stealth mode on hosts where the admin account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them, select TCP Syn Scan .

- To scan by using a system connect() call, which can be used on hosts where the admin account on your Defense Center does not have raw packet access or where IPv6 is running, select TCP Connect Scan .

- To send an ACK packet to check whether ports are filtered or unfiltered, select TCP ACK Scan .

- To send an ACK packet to check whether ports are filtered or unfiltered but also to determine whether a port is open or closed, select TCP Window Scan .

- To identify BSD-derived systems using a FIN/ACK probe, select TCP Maimon Scan .

Step 7 Optionally, to scan UDP ports in addition to TCP ports, select On for the Scan for UDP ports option.

Tip A UDP portscan takes more time than a TCP portscan. To speed up your scans, leave this option disabled.

Step 8 If you plan to use this remediation in response to correlation policy violations, configure the Use Port From Event option:

- Select On to scan the port in the correlation event, rather than the ports you specify in step 11 .

If you scan the port in the correlation event, note that the remediation scans the port on the IP addresses that you specified in step 5. These ports are also added to the remediation’s dynamic scan target.

- Select Off to scan only the ports you will specify in step 11 .

Step 9 If you plan to use this remediation in response to correlation policy violations and want to run the scan using the appliance running the detection engine that detected the event, configure the Scan from reporting detection engine option:

- To scan from the appliance running the reporting detection engine, select On .

- To scan from the appliance configured in the remediation, select Off .

Step 10 Configure the Fast Port Scan option:

- To scan only the ports listed in the nmap-services file located in the /var/sf/nmap/share/nmap/nmap-services directory on the device that does the scanning, ignoring other port settings, select On .

- To scan all TCP ports, select Off .

Step 11 In the Port Ranges and Scan Order field, type the ports you want to scan by default, using Nmap syntax, in the order you want to scan those ports.

Specify values from 1 to 65535. Separate ports using commas or spaces. You can also use a hyphen to indicate a port range. When scanning for both TCP and UDP ports, preface the list of TCP ports you want to scan with a T and the list of UDP ports with a U. For example, to scan ports 53 and 111 for UDP traffic, then scan ports 21-25 for TCP traffic, enter U:53,111,T:21-25.

Note that the Use Port From Event option overrides this setting when the remediation is launched in response to a correlation policy violation, as described in step 8.

Step 12 To probe open ports for server vendor and version information, configure Probe open ports for vendor and version information:

- Select On to scan open ports on the host for server information to identify server vendors and versions.

- Select Off to continue using Cisco server information for the host.

Step 13 If you choose to probe open ports, set the number of probes used by selecting a number from the Service Version Intensity drop-down list:

- To use more probes for higher accuracy with a longer scan, select a higher number.

- To use fewer probes for less accuracy with a faster scan, select a lower number.

Step 14 To scan for operating system information, configure Detect Operating System settings:

- Select On to scan the host for information to identify the operating system.

- Select Off to continue using Cisco operating system information for the host.

Step 15 To determine whether host discovery occurs and whether port scans are only run against available hosts, configure Treat All Hosts As Online:

- To skip the host discovery process and run a port scan on every host in the target range, select On .

- To perform host discovery using the settings for Host Discovery Method and Host Discovery Port List and skip the port scan on any host that is not available, select Off .

Step 16 Select the method you want Nmap to use when it tests for host availability:

- To send an empty TCP packet with the SYN flag set and elicit an RST response on a closed port or a SYN/ACK response on an open port on available hosts, select TCP SYN .

Note that this option scans port 80 by default and that TCP SYN scans are less likely to be blocked by a firewall with stateful firewall rules.

- To send an empty TCP packet with the ACK flag set and elicit an RST response on available hosts, select TCP ACK.

Note that this option scans port 80 by default and that TCP ACK scans are less likely to be blocked by a firewall with stateless firewall rules.

- To send a UDP packet to elicit port unreachable responses from closed ports on available hosts, select UDP . This option scans port 40125 by default.

Step 17 If you want to scan a custom list of ports during host discovery, type a list of ports appropriate for the host discovery method you selected, separated by commas, in the Host Discovery Port List field.

Step 18 Configure the Default NSE Scripts option to control whether to use the default set of Nmap scripts for host discovery and server, operating system, and vulnerability discovery:

- To run the default set of Nmap scripts, select On .

- To skip the default set of Nmap scripts, select Off .

See http://nmap.org/nsedoc/categories/default.html for the list of default scripts.

Step 19 To set the timing of the scan process, select a timing template number; select a higher number for a faster, less comprehensive scan and a lower number for a slower, more comprehensive scan.

Step 20 Click Save, then click Done.

The remediation is created.

Managing Nmap Scanning

License: FireSIGHT

You can modify or delete Nmap scan instances and remediations as needed. You can also run an on-demand Nmap scan. You can also view or download Nmap results for previous scans. For more information, see the following sections:

- Managing Nmap Scan Instances

- Managing Nmap Remediations

- Running an On-Demand Nmap Scan

Managing Nmap Scan Instances

License: FireSIGHT

You can edit or delete Nmap scan instances. For more information, see the following sections:

- Editing an Nmap Scan Instance

- Deleting an Nmap Scan Instance

Editing an Nmap Scan Instance

License: FireSIGHT

Use the following procedure to modify scan instances. Note that you can view, add, and delete remediations associated with the instance when you modify it.

To edit a scan instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Click View next to the instance you want to edit.

The Instance Detail page appears.

Step 3 Optionally, click View next to the remediation you want to view or edit.

For more information on editing remediations, see Editing an Nmap Remediation.

Step 4 Optionally, click Delete next to the remediation you want to delete.

For more information on deleting remediations, see Deleting an Nmap Remediation.

Step 5 Optionally, click Add to add a new remediation to this scan instance.

For more information on creating new remediations, see Managing Nmap Remediations.

Step 6 Optionally, make changes to the scan instance settings, then click Save.

Step 7 Click Done.

The scan instance is modified.

Deleting an Nmap Scan Instance

License: FireSIGHT

Delete an Nmap scan instance when you no longer want to use the Nmap module profiled in the instance. Note that when you delete the scan instance, you also delete any remediations that use that instance.

To delete a scan instance:

Access: Admin/Discovery Admin

Step 1 Click Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Click Delete next to the scan instance you want to delete.

The instance is deleted.

Managing Nmap Remediations

License: FireSIGHT

You can edit or delete Nmap remediations. For more information, see the following sections:

- Editing an Nmap Remediation

- Deleting an Nmap Remediation

Editing an Nmap Remediation

License: FireSIGHT

Modifications you make to Nmap remediations do not affect scans in progress. The new settings take effect when the next scan starts.

To edit an Nmap remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Next to the remediation you want to edit, click View.

The Remediation Edit page appears.

Step 3 Make modifications as necessary.

For information on the settings you can change, see Creating an Nmap Remediation.

Step 4 Click Save, then click Done.

The remediation is modified.

Deleting an Nmap Remediation

License: FireSIGHT

Delete an Nmap remediation if you no longer need it.

To delete an Nmap remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Next to the remediation you want to delete, click Delete.

Step 3 Confirm that you want to delete the remediation.

The remediation is deleted.

Running an On-Demand Nmap Scan

License: FireSIGHT

You can launch on-demand Nmap scans whenever needed. You can specify the target for an on-demand scan by entering the IP addresses and ports you want to scan or by selecting an existing scan target.

Note that Nmap-supplied server and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up to date. For more information, see Automating Nmap Scans. In addition, note that if the host is deleted from the network map, any Nmap scan results are discarded.

To run an on-demand Nmap scan:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Next to the Nmap remediation you want to use to perform the scan, click Scan.

The Nmap Scan Target dialog box appears.

Step 3 Optionally, to scan using a saved scan target, select a target from the Saved Targets drop-down list and click Load.

The IP addresses and ports associated with the scan target populate the IP Range(s) and Ports fields.

Tip To create a scan target, click Edit/Add Targets. For more information, see Creating an Nmap Scan Target.

Step 4 In the IP Range(s) field, specify the IP address for hosts you want to scan or modify the loaded list, up to 255 characters.

For hosts with IPv4 addresses, you can specify multiple IP addresses separated by commas or use CIDR notation. You can also negate IP addresses by preceding them with an exclamation point (!). For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

For hosts with IPv6 addresses, use an exact IP address. Ranges are not supported.

Step 5 In the Ports field, specify the ports you want to scan or modify the loaded list.

You can enter a port number, a list of ports separated by commas, or a range of port numbers separated by a dash. For details on entering ports, see Specifying Ports in Searches.

Step 6 Click Scan Now.

The Nmap server performs the scan.

Note that Nmap validates IP address ranges and displays an error message if the range is invalid. If this occurs, correct the contents of the IP Range(s) field to indicate a valid IP address range.

Managing Scan Targets

License: FireSIGHT

When you configure an Nmap module, you can create and save scan targets that identify the hosts and ports you want to target when you perform an on-demand or a scheduled scan, so that you do not have to construct a new scan target every time. A scan target includes a single IP address or a block of IP addresses to scan, as well as the ports on the host or hosts. For Nmap targets, you can also use Nmap octet range addressing or IP address ranges. For more information on Nmap octet range addressing, refer to the Nmap documentation at http://insecure.org.

Note that scans for scan targets containing a large number of hosts can take an extended period of time. As a workaround, scan fewer hosts at a time.

After you create a scan target, you can modify or delete it.

For more information, see the following sections:

- Creating an Nmap Scan Target

- Editing a Scan Target

- Deleting a Scan Target

Editing a Scan Target

License: FireSIGHT

You can modify scan targets you created.

Tip You might want to edit a remediation’s dynamic scan target if you do not want to use the remediation to scan a specific IP address, but the IP address was added to the target because the host was involved in a correlation policy violation that launched the remediation.

To edit an existing scan target:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 On the toolbar, click Targets.

The Scan Target List page appears.

Step 3 Click Edit next to the scan target you want to edit.

The Scan Target page appears.

Step 4 Make modifications as necessary and click Save.

The scan target is updated.

Deleting a Scan Target

License: FireSIGHT

Delete a scan target if you no longer want to scan the hosts listed in it.

To delete a scan target:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 On the toolbar, click Targets.

The Scan Target List page appears.

Step 3 Next to the scan target you want to delete, click Delete.

The scan target is deleted.

Working with Active Scan Results

License: FireSIGHT

For information on how to monitor Nmap scans in progress, import results from scans previously performed through the FireSIGHT System or results preformed outside the FireSIGHT System, and view and analyze scan results, see the following sections:

- Viewing Scan Results

- Understanding the Scan Results Table

- Analyzing Scan Results

- Monitoring Scans

- Importing Scan Results

- Searching for Scan Results

Viewing Scan Results

License: FireSIGHT

You can view a table of scan results, and then manipulate the event view depending on the information you are looking for.

The page you see when you access scan results differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of scan results.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

Table 47-2 Scan Results Table Functions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Scan Results Table.

modify the time and date range for the scan result

click the time range link. For more information, see Setting Event Time Constraints.

sort scan results

click the column title. Click the column title again to reverse the sort order.

constrain the columns that appear

. . To add a disabled column back to the view, .

drill down to the next page in the workflow, constraining on a specific value

use one of the following methods:

- on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some users, select the check boxes next to the users you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.
For more information, see Constraining Events.

configure scan instances and remediations

Click Scanners in the toolbar.

For more information, see Setting up Nmap Scans.

navigate within and between workflow pages

find more information in Using Workflow Pages.

navigate to other event views to view associated events

the name of the event view you want to see from the Jump to drop-down list. For more information, see Navigating Between Workflows.

search for scan results

click Search. For more information, see Searching for Scan Results.

To view scan results:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

Step 2 Click Scan Results.

The first page of the default scan results workflow appears. To use a different workflow, including a custom workflow, click (switch workflows) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Understanding the Scan Results Table

License: FireSIGHT

When you run an Nmap scan, the Defense Center collects the scan results in a database. The fields in the scan results table are described in the following table.

Table 47-3 Scan Results Fields

Field

Description

Start Time

The date and time that the scan that produced the results started.

End Time

The date and time that the scan that produced the results ended.

Scan Target

The IP address (or host name, if DNS resolution is enabled) of the scan target for the scan that produced the results.

Scan Type

Either Nmap or the name of the third-party scanner to indicate the type of the scan that produced the results.

Scan Mode

The mode of the scan that produced the results:

- On Demand — results from scans run on demand.

- Imported — results from scans on a different system and imported onto the Defense Center.

- Scheduled — results from scans run as a scheduled task.

Analyzing Scan Results

License: FireSIGHT

You can view scan results that you create using the local Nmap module as a rendered page in a pop-up window. You can also download the Nmap results file in raw XML format.

You can also view operating system and server information detected by Nmap in host profiles and in the network map. If a scan of a host produces server information for servers on filtered or closed ports, or if a scan collects information that cannot be included in the operating system information or the servers section, the host profile includes those results in an Nmap Scan Results section. For more information, see Viewing Host Profiles.

Monitoring Scans

License: FireSIGHT

You can check the progress of an Nmap scan and cancel scan jobs currently in progress. Scan results provide the start time and end time of each scan. Also, after a scan is completed, you can also view the scan results as a rendered page in a pop-up window. Nmap results you can download and view using the Nmap Version 1.01 DTD, available at http://insecure.org. You can also clear scan results.

To monitor a scan:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

Step 2 Click Scan Results.

The first page of the default scan results workflow appears. To use a different workflow, including a custom workflow, click (switch workflows) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of scan results, click (switch workflows) by the workflow title, then select Scan Results.

Step 3 You can perform the following actions:

- To view the scan results as a rendered page in a pop-up window, click View next to the scan job.

- To save a copy of the scan results file so that you can view the raw XML code in any text editor, click Download next to the scan job.

Importing Scan Results

License: FireSIGHT

You can import XML results files created by an Nmap scan performed outside of the FireSIGHT System. You can also import XML results files that you previously downloaded from the FireSIGHT System. To import Nmap scan results, the results file must be in XML format and adhere to the Nmap Version 1.01 DTD. For more information on creating Nmap results and on the Nmap DTD, refer to the Nmap documentation at http://insecure.org. For information on downloading XML results from the FireSIGHT System, see Monitoring Scans.

Note that a host must exist in the network map before Nmap can append its results to the host profile.

To import results:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scan Instances page appears.

Step 2 On the toolbar, click Import Results.

The Import Results page appears.

Step 3 Click Browse to navigate to the results file.

Step 4 After you return to the Import Results page, click Import to import the results.

The results file is imported.

Searching for Scan Results

License: FireSIGHT

You can search for Nmap or third-party scan results for any scans run on an appliance or managed appliance in your FireSIGHT System.

Table 47-4 Scan Results Search Criteria

Field

Search Criteria Rules

Start Time

Type the date and time that the scan that produced the results started.

See Specifying Time Constraints in Searches for the syntax for entering time.

End Time

Type the date and time that the scan that produced the results ended.

See Specifying Time Constraints in Searches for the syntax for entering time.

Scan Target

Type the IP address (or host name, if DNS resolution is enabled) of the scan target for the scan that produced the results.

Use a specific IP address or CIDR notation to specify a range of IP addresses. See Specifying IP Addresses in Searches for a full description of the syntax allowed for IP addresses.

Scan Type

Type Nmap or a third-party scanner ID to indicate the type of the scan that produced the results.

Scan Mode

Type the mode of the scan that produced the results:

- Type On Demand to retrieve results from scans run on demand.

- Type Imported to retrieve results from scans on a different system and imported onto the Defense Center.

- Type Scheduled to retrieve results from scans run as a scheduled task.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

To search for scan results:

Access: Admin/Discovery Admin

Step 1 Select Analysis > Search, then select Scan Results from the table drop-down list.

The Scan Results search page appears.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 2 Enter your search criteria in the appropriate fields, as described in the Scan Results Search Criteria table.

If you enter criteria for multiple fields, the search returns only the records that match search criteria specified for all fields.

Step 3 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 4 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 5 Click Search to start the search.

Your search results appear.

Using the Network Map

The FireSIGHT System passively collects traffic traveling over the network, decodes the data, and then compares it to established operating system and fingerprints. From this information, the system builds a network map, which is a detailed representation of your network.

The network map allows you to use the Defense Center to view your network topology in terms of hosts and network devices (bridges, routers, NAT devices, and load balancers). It is a useful tool for a quick, overall view of your network. The network map also allows you to drill down on associated host attributes, applications, clients, indications of compromised hosts, and vulnerabilities. In other words, you can select different views of the network map to suit the analysis you perform.

You can augment the information your system collects by adding operating system, application, client, protocol, or host attribute information from a third-party application using the host input feature. You can also actively scan hosts in the network map using Nmap and add the scan results to your network map.

You can use the custom topology feature to help you organize and identify subnets in the views of the network map. For example, if each department in your organization uses a different subnet, you can assign familiar labels to those subnets using the custom topology feature.

For more information, see the following sections:

- Understanding the Network Map

- Working with the Hosts Network Map

- Working with the Network Devices Network Map

- Working with the Indications of Compromise Network Map

- Working with the Mobile Devices Network Map

- Working with the Applications Network Map

- Working with the Vulnerabilities Network Map

- Working with the Host Attributes Network Map

- Working with Custom Network Topologies

Understanding the Network Map

License: FireSIGHT

Each view of the network map has the same format: a hierarchical tree with expandable categories and sub-categories. When you click a category, it expands to show you the sub-categories beneath it. You can select different views of the network map depending on the kind of analysis you are performing.

The Defense Center gathers data from all security zones where discovery policies are applied (including zones that process data from NetFlow-enabled devices). If multiple devices detect the same network asset, the Defense Center combines the information into a composite representation of the asset.

Although you can configure your network discovery policy to add data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.

From any network map, you can view any host’s host profile, which provides a complete view of all the information collected by the system for that host. The host profile contains general information, such as the host name, operating system, and all associated IP addresses, as well as more specific information including detected protocols, applications, indications of compromise, and clients that are running on the host. The host profile also includes information about the vulnerabilities associated with the host and its detected assets. For more information on host profiles, see Using Host Profiles.

You can delete an item from the network map if you are no longer interested in investigating it. You can delete hosts and applications from the network map; you can also delete or deactivate vulnerabilities. If the system detects activity associated with a deleted host, it re-adds the host to the network map. Similarly, deleted applications are re-added to the applications network map if the system detects a change in the application (for example, if an Apache web server is upgraded to a new version). Vulnerabilities are reactivated on specific hosts if the system detects a change that makes the host vulnerable.

You can also use the network map to deactivate vulnerabilities network-wide, which means that you deem these hosts, which the system has judged to be vulnerable, to be safe from that particular attack or exploit.

Tip If you want to permanently exclude a host or subnet from the network map, modify the network discovery policy. You may wish to exclude load balancers and NAT devices from monitoring. They may create excessive and misleading events, filling the database and overloading the Defense Center. See Understanding Host Data Collection for more information.

Working with the Hosts Network Map

License: FireSIGHT

Use the hosts network map to view the hosts on your network, organized by subnet in a hierarchical tree, as well as to drill down to the host profiles for specific hosts. This network map view provides a count of all unique hosts detected by the system, regardless of whether the hosts have one IP address or multiple IP addresses.

Although you can configure your network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for hosts added to the network map using NetFlow data, unless you provide it using the host input feature.

By creating a custom topology for your network, you can assign meaningful labels to your subnets, such as department names, that appear in the hosts network map.

You can also view the hosts network map according to the organization you specified in the custom topology; see Working with Custom Network Topologies.

You can delete entire networks, subnets, or individual hosts from the hosts network map. For example, if you know that a host is no longer attached to your network, you can delete it from the network map to simplify your analysis. If the system afterwards detects activity associated with the deleted host, it re-adds the host to the network map. If you want to permanently exclude a host or subnet from the network map, modify the network discovery policy. See Creating a Network Discovery Policy for more information.

Note Cisco strongly recommends that you do not delete network devices from the network map, because the system uses their locations to determine network topology (including generating network hops and TTL values for monitored hosts). Although you cannot delete network devices from the network devices network map, make sure you do not delete them from the hosts network map.

To view the hosts network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map, then select the Hosts tab.

The hosts network map appears, displaying a host count and a list of host IP addresses and MAC addresses. Each address or partial address is a link to the next level.

Step 2 Drill down to the specific IP address or MAC address of the host you want to investigate.

For example, to view a host with the IP address 192.168.40.11, click 192, then 192.168, then 192.168.40, then 192.168.40.11. When you click 192.168.40.11, the host profile appears. For more information on host profiles, see Using Host Profiles.

).

) next to the element you want to delete, then confirm that you want to delete the host or subnet.

The host is deleted. If the system rediscovers the host, it re-adds the host to the network map.

Step 4 Optionally, switch between the hosts view and the topology view of the hosts network map:

- To switch to a view of the hosts network map organized by your custom topology, on the hosts view (the default), click (topology) at the top of the network map.

- To switch to a view of the hosts network map organized by subnet, on the topology view, click (hosts) at the top of the network map.

For information on configuring custom topologies, see Working with Custom Network Topologies.

Working with the Network Devices Network Map

License: FireSIGHT

Use the network devices network map to view the network devices (bridges, routers, NAT devices, and load balancers) that connect one segment of your network to another, as well as to drill down to the host profiles of those network devices. The network devices network map is separated into two sections: IP and MAC. The IP section lists network devices identified by an IP address; the MAC section lists network devices identified by a MAC address. This network map view also provides a count of all unique network devices detected by the system, regardless of whether the devices have one IP address or multiple IP addresses.

If you create a custom topology for your network, the labels you assign to your subnets appear in the network devices network map.

The methods the system uses to distinguish network devices include:

- the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their types (Cisco devices only)

- the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge

- the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router

- the detection of TTL value changes from the client side, or TTL values that change more frequently than a typical boot time, which identify NAT devices and load balancers

If a network device communicates using CDP, it may have one or more IP addresses. If it communicates using STP, it may only have a MAC address.

You cannot delete network devices from the network map, because the system uses their locations to determine network topology (including generating network hops and TTL values for monitored hosts).

The host profile for a network device has a Systems section rather than an Operating Systems section, which includes a Hardware column that reflects the hardware platform for any mobile devices detected behind the network device. If a value for a hardware platform is listed under Systems, that system represents a mobile device or devices detected behind the network device. Note that mobile devices may or may not have hardware platform information, but hardware platform information is never detected for systems that are not mobile devices.

To view the network devices network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map > Network Devices.

The network devices network map appears, displaying a count of unique network devices and a list of network device IP addresses and MAC addresses. Each address or partial address is a link to the next level of addresses or to the host profile for an individual host.

Step 2 Drill down to the specific IP address or MAC address of the network device you want to investigate.

The host profile for the network device appears. For more information on host profiles, see Using Host Profiles.

).

Working with the Indications of Compromise Network Map

License: FireSIGHT

Use the indications of compromise (IOC) network map to view the compromised hosts on your network, organized by IOC category. Affected hosts are listed beneath each category.

The system uses data from multiple sources to determine a host’s compromised status, including intrusion events, Security Intelligence, and FireAMP.

From the indications of compromise network map, you can view the host profile of each host determined to have been compromised in a specific way. You can also delete (mark as resolved) any IOC category or any specific host, which removes the IOC tag from the relevant hosts. For example, you can delete an IOC category from the network map if you have determined that the issue is addressed and unlikely to recur.

Marking a host or IOC category resolved from the network map does not remove it from your network. A resolved host or IOC category reappears in the network map if your system newly detects information that triggers that IOC.

To view the indications of compromise network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map > Indications of Compromise.

The indications of compromise network map appears.

Step 2 Click the specific IOC category you want to investigate.

For example, if you want to view hosts on which malware was detected, click Malware Detected.

).

Step 3 Drill down to a specific IP address under the IOC category you selected. Each address or partial address is a link to the next level.

The host profile of the compromised host appears with the indications of compromise section expanded. For more information about the IOC section of the host profile, see Working with Indications of Compromise in the Host Profile.

) next to the element you want to resolve, then confirm that you want to resolve it.

The category or host is resolved (IOC tags removed). If the IOC is triggered again, it is re-added to the network map.

Working with the Mobile Devices Network Map

License: FireSIGHT

Use the mobile devices network map to view mobile devices attached to your network, and to drill down to the host profiles for those devices. This network map view also provides a count of all unique mobile devices detected by the system, regardless of whether the devices have one IP address or multiple IP addresses.

The methods the system uses to distinguish mobile devices include:

- analysis of user agent strings in HTTP traffic from the mobile device’s mobile browser

- monitoring of HTTP traffic of specific mobile applications

If you create a custom topology for your network, the labels you assign to your subnets appear in the mobile devices network map.

To view the mobile devices network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map, then select the Mobile Devices tab.

The mobile devices network map appears, displaying a count of unique mobile devices and a list of mobile device IP addresses. Each address or partial address is a link to the next level.

Step 2 Drill down to the specific IP address of the mobile device you want to investigate.

For example, to view a device with the IP address 10.11.40.11, click 10, then 10.11, then 10.11.40, then 10.11.40.11. When you click 10.11.40.11, the host profile appears. For more information on host profiles, see Using Host Profiles.

).

) next to the element you want to delete, then confirm that you want to delete the device or subnet.

The device is deleted. If the system rediscovers the device, it re-adds the device to the network map.

Working with the Applications Network Map

License: FireSIGHT

Use the applications network map to view the applications on your network, organized in a hierarchical tree by application name, vendor, version, and finally by the hosts running each application.

The applications that the system detects may change with system software and VDB updates, and also if you import any add-on detectors. The release notes or advisory text for each system or VDB update contains information on any new and updated detectors. For a comprehensive up-to-date list of detectors, see either of the following Support Sites:

- Cisco: (http://www.cisco.com/cisco/web/support/index.html )

From the applications network map, you can view the host profile of each host that runs a specific application as well as delete any application category, any application running on all hosts, or any application running on a specific host. For example, you can delete an application from the network map if you know it is disabled on the host and you want to make sure the system does not use it for impact level qualification.

Deleting an application from the network map does not remove it from your network. A deleted application reappears in the network map if your system detects a change in the application (for example, if an Apache web server is upgraded to a new version) or if you restart your system’s discovery function.

Depending on what you delete, the behavior differs:

- If you delete an application category, the application category is removed from the network map. All applications that reside beneath the category are removed from any host profile that contains the applications.

For example, if you delete http, all applications identified as http are removed from all host profiles and http no longer appears in the applications view of the network map.

- If you delete a specific application, vendor, or version, the affected application is removed from the network map and from any host profiles that contain it.

For example, if you expand the http category and delete Apache, all applications listed as Apache with any version listed beneath Apache are removed from any host profiles that contain them. Similarly, if instead of deleting Apache, you delete a specific version (1.3.17, for example), only the version you selected will be deleted from affected host profiles.

- If you delete a specific IP address, the IP address is removed from the application list and the application itself is removed from the host profile of the IP address you selected.

For example, if you expand http, Apache, 1.3.17 (Win32), and then delete 172.16.1.50:80/tcp, the Apache 1.3.17 (Win32) application is deleted from the host profile of IP address 172.16.1.50.

To view the applications network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map > Applications.

The applications network map appears.

Step 2 Drill down to the specific application you want to investigate.

For example, if you want to view a specific type of web server like Apache, click http, then click Apache, and then click the version of the Apache web server you want to view.

).

Step 3 Click a specific IP address under the application you selected.

The host profile of the host running the application appears with the applications section expanded. For more information about the applications section of the host profile, see Working with Servers in the Host Profile.

) next to the element you want to delete, then confirm that you want to delete it.

The application is deleted. If the system rediscovers the application, it is re-added to the network map.

Working with the Vulnerabilities Network Map

License: FireSIGHT

Use the vulnerabilities network map to view the vulnerabilities that the system has detected on your network, organized by legacy vulnerability ID (SVID), Bugtraq ID, CVE ID, or Snort ID. The vulnerabilities are arranged by identification number, with affected hosts listed beneath each vulnerability.

From the vulnerabilities network map, you can view the details of specific vulnerabilities; you can also view the host profile of any host subject to a specific vulnerability. This can help you evaluate the threat posed by that vulnerability to specific affected hosts.

If you deem that a specific vulnerability is not applicable to the hosts on your network (for example, you have applied a patch), you can deactivate the vulnerability. Deactivated vulnerabilities still appear on the network map, but the IP addresses of their previously affected hosts appear in gray italics. The host profiles for those hosts show deactivated vulnerabilities as invalid, though you can manually mark them as valid for individual hosts; see Setting Vulnerabilities for Individual Hosts for more information.

If there is an identity conflict for an application or operating system on a host, the system lists the vulnerabilities for both potential identities. When the identity conflict is resolved, the vulnerabilities remain associated with the current identity. For more information, see Understanding Current Identities and Understanding Identity Conflicts.

By default, the vulnerability network map displays the vulnerabilities of a detected application only if the packet contains the application’s vendor and version. However, you can configure the system to list the vulnerabilities for applications lacking vendor and version data by enabling the vulnerability mapping setting for the application in the system policy. For information on setting the vulnerability mapping for an application, see Mapping Vulnerabilities for Servers.

The numbers next to a vulnerability ID (or range of vulnerability IDs) represent two counts:

- The first number is a count of non-unique hosts that are affected by a vulnerability or vulnerabilities. If a host is affected by more than one vulnerability, it is counted multiple times. Therefore, it is possible for the count to be higher than the number of hosts on your network. Deactivating a vulnerability decrements this count by the number of hosts that are potentially affected by the vulnerability. If you have not deactivated any vulnerabilities for any of the potentially affected hosts for a vulnerability or range of vulnerabilities, this count is not displayed.

- The second number is a similar count of the total number of non-unique hosts that the system has determined are potentially affected by a vulnerability or vulnerabilities.

Deactivating a vulnerability renders it inactive only for the hosts you designate. You can deactivate a vulnerability for all hosts that have been judged vulnerable or for a specified individual vulnerable host. If the system subsequently detects the vulnerability on a host where it has not been deactivated (for example, on a new host in the network map), the system activates the vulnerability for that host. You have to explicitly deactivate the newly discovered vulnerability. Also, if the system detects an operating system or application change for a host, it may reactivate associated deactivated vulnerabilities.

To view the vulnerabilities network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map > Vulnerabilities.

The vulnerabilities network map appears.

Step 2 From the Type drop-down list, select the class of vulnerability you want to view. By default, vulnerabilities are displayed by legacy vulnerability ID (SVID).

Step 3 Drill down to the specific vulnerability you want to investigate.

).

The vulnerability details appear. For details on the information provided, see Viewing Vulnerability Details.

In addition, on the network map, the Defense Center displays the IP addresses of affected hosts. You can click any IP address to display the host profile for that host.

Step 4 Optionally, deactivate the vulnerability:

- To deactivate the vulnerability for all hosts affected by the vulnerability, click the delete icon (

) next to the vulnerability number.

- To deactivate the vulnerability for an individual host, click the delete icon (

) next to the host’s IP address.

The vulnerability is deactivated. The applicable hosts’ IP addresses appear in gray italics in the network map. In addition, host profiles for those hosts show deactivated vulnerabilities as invalid.

Tip See Setting Vulnerabilities for Individual Hosts for more information on reactivating vulnerabilities.

Working with the Host Attributes Network Map

License: FireSIGHT

Use the host attributes network map to view the hosts on your network organized by their host attributes. When you select the host attribute you want to use to organize your hosts, the Defense Center lists the possible values for that attribute in the network map and groups hosts based on their assigned values. You can also view the host profile of any host assigned a specific host attribute value.

The host attributes network map can organize hosts based on user-defined host attributes. For any of these attributes, the network map displays hosts that do not have a value assigned as Unassigned.

For more information, see Working with User-Defined Host Attributes.

In addition, the host attributes network map can organize hosts based on the host attributes that correspond to any compliance white lists you have created. Each compliance white list that you create automatically creates a host attribute with the same name as the white list.

Possible white list host attribute values are:

- Compliant , for hosts that are compliant with the white list

- Non-Compliant , for hosts that violate the white list

- Not Evaluated , for hosts that are not valid targets of the white list or have not been evaluated for any reason

For more information on compliance white lists, see Using the FireSIGHT System as a Compliance Tool.

Note You cannot organize hosts using predefined host attributes, such as host criticality, on the host attributes network map.

To view the host attributes network map:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Network Map > Host Attributes.

The host attributes network map appears.

Step 2 From the Attribute drop-down list, select a host attribute.

The Defense Center lists the values for the host attribute and indicates, in parentheses, the number of hosts assigned that value.

).

Step 3 Click any host attribute value to view hosts assigned the value.

Step 4 Click a host IP address to view the host profile for that host.

Working with Custom Network Topologies

License: FireSIGHT

Use the custom topology feature to help you organize and identify subnets in your hosts and network devices network maps.

For more information about the hosts and network devices network maps, see Working with the Hosts Network Map and Working with the Network Devices Network Map.

For more information, see the following sections:

- Creating Custom Topologies

- Managing Custom Topologies

Creating Custom Topologies

License: FireSIGHT

To create a custom topology, you must specify its networks. You can do this using any or all of three strategies:

- by importing the Cisco-discovered topology, which adds networks using a “best guess” at how your network is deployed based on the hosts and network devices the system has detected

- by importing networks from a network discovery policy, which adds the networks that you configured the FireSIGHT System to monitor in a network discovery policy

- by adding networks to your topology manually, if the other two methods create an inaccurate or incomplete representation of your deployment

You must save and activate the topology before using it with the network map.

To create a custom topology:

Access: Admin/Discovery Admin

Step 1 Select Policies > Network Discovery, then click Custom Topology.

The Custom Topology page appears.

Step 2 Click Create Topology.

The Create Topology page appears.

Step 3 Provide basic topology information, such as the topology name and description.

See Providing Basic Topology Information.

Step 4 Add networks to your topology. You can use any or all of the following strategies:

- To add networks to your topology by importing the Cisco-discovered topology, follow the procedure in Importing a Discovered Topology.

- To add networks to your topology by importing them from a network discovery policy, follow the procedure in see Importing Networks from a Network Discovery Policy.

- To add networks to your topology manually, follow the procedure in Manually Adding Networks to Your Custom Topology.

Step 5 Refine your topology:

- To remove a network from your custom topology, click Delete next to the network you want to remove.

- To rename a network, click Rename next to the network. In the pop-up window that appears, type the new name in the Name field and click Rename . This name labels the network in the network map.

Step 6 Click Save.

The topology is saved.

Note You must activate the topology before you can use it in the network map. For more information, see Managing Custom Topologies.

Providing Basic Topology Information

License: FireSIGHT

You must give each custom topology a name, and, optionally, a short description.

To provide basic topology information:

Access: Admin

Step 1 On the Edit Topology page, in the Name field, type a name for the topology.

Step 2 Optionally, in the Description field, type a description for the topology.

Step 3 Optionally, continue with the procedures in the following sections, depending on how you want to build your custom topology:

- Importing a Discovered Topology

- Importing Networks from a Network Discovery Policy

- Manually Adding Networks to Your Custom Topology

Importing a Discovered Topology

License: FireSIGHT

One way you can add networks to your custom topology is to import the topology discovered by your FireSIGHT System. This discovered topology is the system’s “best guess” at how your network is deployed based on the hosts and network devices it has detected.

To import a discovered topology:

Access: Admin

Step 1 On the Edit Topology page, click Import Discovered Topology.

Step 2 The discovered networks populate the page.

Step 3 Optionally, continue with the procedures in the following sections, depending on how you want to build your custom topology:

- Importing a Discovered Topology

- Importing Networks from a Network Discovery Policy

- Manually Adding Networks to Your Custom Topology

Importing Networks from a Network Discovery Policy

License: FireSIGHT

One way you can add networks to your custom topology is to import the networks that you configured the FireSIGHT System to monitor in a network discovery policy; see Creating a Network Discovery Policy.

To import networks from a network discovery policy:

Access: Admin

Step 1 On the Edit Topology page, click Import Policy Networks.

A pop-up window appears.

Step 2 From the drop-down list, choose the network discovery policy you want to use and click Load.

Step 3 The monitored networks in your network discovery policy populate the page.

Step 4 To add networks from a different network discovery policy, repeat steps 1 and 2.

Step 5 Optionally, follow the procedures in the following sections, depending on how you want to build your custom topology:

- Importing a Discovered Topology

- Manually Adding Networks to Your Custom Topology

Manually Adding Networks to Your Custom Topology

License: FireSIGHT

If importing the Cisco-discovered topology and importing networks from your network discovery policy creates an inaccurate or incomplete representation of your network deployment, you can add networks to your custom topology manually.

To add a network to a custom topology manually:

Access: Admin

Step 1 On the Edit Topology page, click Add Network.

A pop-up window appears.

Step 2 Optionally, name the network by typing a name in the Name field.

This name labels the networks in the hosts and network devices network maps after you activate the topology.

For more information, see Working with the Hosts Network Map and Working with the Network Devices Network Map.

Step 3 In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represent the network you want to add to your topology.

For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 4 Click Add.

The network is added to your topology.

Step 5 To add additional networks to your topology, repeat steps 1 through 4.

Tip To delete a network from your topology, click Delete next to the network you want to delete, and confirm that you want to delete the network, as well as all links to the network.

Step 6 Optionally, follow the procedures in the following sections, depending on how you want to build your custom topology:

- Importing a Discovered Topology

- Importing Networks from a Network Discovery Policy

Managing Custom Topologies

License: FireSIGHT

Use the Custom Topology page to manage custom topologies. You can create, modify, and delete topologies.

A topology’s status appears with its name. If the light bulb icon next to the policy name is lit, the topology is active and affects your network map. If it is dark, the topology is inactive. Only one custom topology can be active at any time. If you have created multiple topologies, activating one automatically deactivates the currently active topology.

Use the following procedures to either activate or deactivate a custom topology, modify a topology, or delete a topology.

If you delete the active topology, your changes take effect immediately; that is, your network map no longer displays your custom topology.

To activate or deactivate a custom topology:

Access: Admin

Step 1 Select Policies > Network Discovery > Custom Topology.

The Custom Topology page appears.

Step 2 You have two options:

- To activate a topology, click Activate next to the policy.

- To deactivate a topology, click Deactivate next to the policy.

To modify a custom topology:

Access: Admin

Step 1 Select Policies > Network Discovery > Custom Topology.

The Custom Topology page appears.

) next to the topology you want to edit.

The Edit Topology page appears. See Creating Custom Topologies for information on the various configurations you can change.

Step 3 Make changes as needed and click Save.

The topology is changed. If the topology is active, the changes you made take effect in the network map immediately.

To delete a custom topology:

Access: Admin

Step 1 Select Policies > Network Discovery > Custom Topology.

The Custom Topology page appears.

Step 2 Click Delete next to the topology you want to delete. If the topology is active, confirm that you want to delete it.

The topology is deleted.

Using Host Profiles

A host profile provides a complete view of all the information the system has gathered about a single host. You can access general host information, such as the host name and operating system, through the profile. If you need to quickly find the MAC address for a host, for example, you can look in the host profile.

Host attributes for that host are also listed in the profile. Host attributes are user-defined descriptions that you can apply to a host. For example, you might assign a host attribute that indicates the building where the host is located. From a host profile, you can view the existing host attributes applied to that host and can modify the host attribute values. As another example, you can use the host criticality attribute to designate the business criticality of a given host and to tailor correlation policies and alerts based on host criticality.

Host profiles also provide you with information about the servers, clients, and host protocols running on a particular host, including whether they are in compliance with a compliance white list. You can remove servers from the servers list, and view details for those servers. You can also view connection events for servers, log information about the session where server traffic was detected. You can also view details and connection events for clients and delete servers, clients or host protocols from the host profile.

If your FireSIGHT System deployment includes a FireSIGHT license, you can view indications of compromise (IOC) in the host profile. These indications correlate various types of data (intrusion events, Security Intelligence, connection events, and file or malware events) associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. From the host profile, you can see an overview of a host’s IOC tags, view the events associated with IOC, mark IOC tags resolved, and edit IOC rule states in the discovery policy.

If your deployment includes a Protection license, you can tailor the way the system processes traffic so it best fits the type of operating system on the host and the servers and clients the host is running. For more information, see Tuning Preprocessing in Passive Deployments.

You can also see user history information for a host if you have configured the system to track it. A graphic representation of the last twenty-four hours of user activity is then available.

You can modify the list of vulnerabilities for the host from the host profile. You can use this capability to track which vulnerabilities have been addressed for the host. You can also apply fixes for vulnerabilities, causing all vulnerabilities addressed by the fix to be automatically marked invalid.

You can work with the vulnerability information generated by the Cisco system, and also use information on vulnerabilities detected by third-party scanners, which you import onto the Defense Center using the host input feature.

Optionally, you can perform an Nmap scan from the host profile, to augment the server and operating system information in your host profile. The Nmap scanner actively probes the host to obtain information about the operating system and servers running on the host. The results of the scan are added to the list of operating system and server identities for the host.

Note that a host profile may not be available for every host on your network. Possible reasons include:

- the host was deleted from the network map because it timed out

- you have reached your FireSIGHT host license limit

- the host resides in a network segment that is not monitored by your network discovery policy

Note that the information displayed in a host profile may vary according to the type of host and the information available about the host. For example, if your system detects a host using a non-IP-based protocol like STP, SNAP, or IPX, the host is added to the network map as a MAC host and much less information is available than for an IP host.

As another example, although you can configure your network discovery policy to add hosts and server and clients to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts and servers and clients is limited. For example, no operating system data is available for these hosts, unless you provide it using a scanner or the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.

- Viewing Host Profiles explains how to access a host profile.

- Working with Basic Host Information in the Host Profile describes the information provided in the Host section of a host profile.

- Working with IP Addresses in the Host Profile describes the information provided in the IP Addresses section of a host profile.

- Working with Indications of Compromise in the Host Profile describes the information provided in the Indications of Compromise section of a host profile.

- Working with Operating Systems in the Host Profile describes the information provided in the Operating System or Operating System Conflicts section of a host profile and explains how to edit the operating system or resolve an operating system conflict.

- Working with Servers in the Host Profile describes the information provided in the Servers, Server Detail, and Server Banner sections of a host profile.

- Working with Applications in the Host Profile describes the information provided in the Clients section of a host profile.

- Working with VLAN Tags in the Host Profile describes the information provided in the VLAN Tag section of a host profile.

- Working with User History in the Host Profile describes the information provided in the User History section of a host profile.

- Working with Host Attributes in the Host Profile describes the information provided in the Attributes section of a host profile.

- Working with the Predefined Host Attributes explains how to set the host criticality attribute and how to add notes to a host profile.

- Working with User-Defined Host Attributes, which provides information about creating and using user-defined host attributes.

- Working with Host Protocols in the Host Profile describes the information provided in the Host Protocols section of a host profile.

- Working with White List Violations in the Host Profile describes the information provided in the White List Violations section of a host profile.

- Working with Malware Detections in the Host Profile describes the information provided in the Most Recent Malware Detections section of a host profile.

- Working with Vulnerabilities in the Host Profile, which describes the information provided in the Vulnerabilities and Vulnerability Detail sections of a host profile.

Viewing Host Profiles

License: FireSIGHT

You can access a host profile from any network map or from any event view that includes the IP addresses of hosts on monitored networks. For example, the table view of discovery events includes a link to the host profile next to every entry in the IP Address column. If you have any indication of compromise (IOC) rules enabled, potentially compromised hosts appear with a different host profile icon.

To view a host profile from an event view:

Access: Admin/Any Security Analyst

) next to the IP address of the host whose profile you want to view.

The host profile appears in a pop-up window.

To view a host profile from a network map:

Access: Admin/Any Security Analyst

Step 1 On any network map, drill down to the IP address of the host whose profile you want to view.

The host profile appears. See Working with the Hosts Network Map for an example of how to access a host profile from a network map.

Working with Basic Host Information in the Host Profile

License: FireSIGHT

Each host profile provides basic information about a detected host or other device.

Descriptions of each of the basic host profile fields follow.

IP Addresses

All IP addresses (both IPv4 and IPv6) associated with the host. IPv6 hosts often have at least two IPv6 addresses (local-only and globally routable), and may also have IPv4 addresses. IPv4-only hosts may have multiple IPv4 addresses. Where available, routable host IP addresses also include a flag icon and country code indicating the geolocation data associated with that address. For more information on this and other geolocation features, see Using Geolocation.

Hostname

The fully qualified domain name of the host, if known.

NetBIOS Name

The NetBIOS name of the host, if available. Microsoft Windows hosts, as well as Macintosh, Linux, or other platforms configured to use NetBIOS, can have a NetBIOS name. For example, Linux hosts configured as Samba servers have NetBIOS names.

Device (Hops)

Either:

– the reporting device for the network where the host resides, as defined in the network discovery policy, or

– the device that processed the NetFlow data that added the host to the network map

– The device and the number of network hops between the device that detected the host and the host itself follows the device name, in parentheses. If multiple devices can see the host, the reporting device is displayed in bold.

– If this field is blank, either:

– the host was added to the network map by a device that is not explicitly monitoring the network where the host resides, as defined in the network discovery policy, or

– the host was added using the host input feature and has not also been detected by the FireSIGHT System

MAC Addresses (TTL)

The host’s detected MAC address or addresses and associated NIC vendors, with the NIC’s hardware vendor and current time-to-live (TTL) value in parentheses. If the MAC address is displayed in a bold font, the MAC address is the actual MAC address of the host, detected by the system through ARP and DHCP traffic. If multiple devices detected the host, the Defense Center displays all MAC addresses and TTL values associated with the host, regardless of which device reported them.

You can click the MAC address to view a list of hosts with the same MAC address. Router host profiles typically show the hosts (IP addresses) in the network segments they route in this list, and the IP addresses of monitored routers frequently appear in this list for monitored workstations and servers. The true IP address for the MAC address is displayed in bold.

Host Type

The type of device that the system detected: host, mobile device, jailbroken mobile device, router, bridge, NAT device, or load balancer.

The methods the system uses to distinguish network devices include:

– the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their type (Cisco devices only)

– the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge

– the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router

– the detection of TTL value changes from the client side, or TTL values that change more frequently than a typical boot time, which identify NAT devices and load balancers

– The methods the system uses to distinguish mobile devices include:

– analysis of user agent strings in HTTP traffic from the mobile device’s mobile browser

– monitoring of HTTP traffic of specific mobile applications

If a device is not identified as a network device or a mobile device, it is categorized as a host.

Last Seen

The date and time that any of a host’s IP addresses was last detected.

Current User

The user most recently logged into this host.

Note that a non-authoritative user logging into a host only registers as the current user on the host if the existing current user is not an authoritative user. For more information, see Users Database.

View

Links to views of event data, using the default workflow for that event type and constrained to show events related to the host; where possible, these events include all IP addresses associated with the host. For more information, see the following sections:

– Content Explorer — for more information, see Using the Context Explorer.

– Connection Events — for more information, see Understanding Connection and Security Intelligence Data.

– Discovery Events — for more information, see Working with Discovery Events.

– Malware Events — for more information, see Working with Malware Events.

– Intrusion Events by Source — for more information, see Working with Intrusion Events.

– Intrusion Events by Destination — for more information, see Working with Intrusion Events.

Working with IP Addresses in the Host Profile

License: FireSIGHT

The system detects IP addresses associated with hosts and, where supported, groups multiple IP addresses used by the same host. IPv6 hosts usually have at least two IPv6 addresses: local-only and globally routable. They may also have one or more assigned IPv4 addresses. IPv4-only hosts may have multiple IPv4 addresses.

The host profile lists all detected IP addresses associated with that host. Where available, IP addresses also feature a small flag icon and ISO country code that indicate the associated country. You can click the flag icon or country code for further geolocation details. For more information, see Using Geolocation.

Note that only the first three addresses are shown by default. Click show all to show all addresses for a host.

Working with Indications of Compromise in the Host Profile

License: FireSIGHT

The FireSIGHT System can correlate various types of data (intrusion events, Security Intelligence, connection events, and file or malware events) associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. Certain combinations and frequencies of event data trigger indications of compromise (IOC) tags on affected hosts. The Indications of Compromise section of the host profile displays all IOC tags for a host. In this section, you can view details of the threats facing the host, jump to the events that triggered an IOC tag, edit IOC rule states, as well as resolve IOC tags that are no longer relevant.

To use the IOC feature, you must activate the feature and at least one IOC rule in your discovery policy. You can also edit IOC rule states for individual hosts from that host’s host profile page. Each IOC rule corresponds to one type of IOC tag; you can activate any or all rules depending on your organization’s needs. For more information on IOC in the discovery policy and overall, see Understanding Indications of Compromise.

In addition to its presence in the host profile, you can also analyze IOC data in the event viewer. For more information, see Working with Indications of Compromise.

Descriptions of the IOC information fields displayed in the host profile follow.

IP Address

The IP address associated with the host that triggered the IOC.

Category

Brief description of the type of compromise indicated, such as Malware Executed or Impact 1 Attack.

Event Type

Identifier associated with a specific Indication of Compromise (IOC), referring to the event that triggered it.

Description

Description of what threatens the potentially compromised host, such as This host may be under remote control or Malware has been executed on this host.

First/Last Seen

The first (or most recent) date and time that events triggering a host’s IOC occurred.

For additional information on working with IOC data in the host profile, see the following sections:

- Editing Indication of Compromise Rule States for a Single Host

- Viewing Source Events for Indications of Compromise

- Resolving Indications of Compromise

Editing Indication of Compromise Rule States for a Single Host

License: FireSIGHT

For your system to detect and tag indications of compromise (IOC), you must first activate the IOC feature in the discovery policy and activate at least one IOC rule (either policy-wide or for individual hosts). From the host profile, you can set the IOC rule states that apply to that individual host. For more information on configuring IOC in the discovery policy and setting policy-wide IOC rule states, see Setting Indications of Compromise Rules.

From the host profile, you can access and edit the list of IOC rules with the Edit Rule States link in the Indications of Compromise section. You can enable any or all rules, depending on the needs of your network and organization. For example, if hosts using software such as Microsoft Excel never appear on your monitored network, you may decide not to enable the IOC tags that pertain to Excel-based threats.

All IOC rules are predefined by Cisco; you cannot create original rules, although you can write compliance rules against triggered IOC tags. For more information, see Configuring Correlation Policies and Rules. Each IOC rule is triggered by only one type of event (such as malware or intrusion) and corresponds to one specific IOC tag. Both rule and tag have identical Category, Event Type, and Description data for easy correspondence; the Edit page for IOC rule states also lists an event data Source for each rule, to give you a clear picture of what system features you need for a rule to trigger.

To edit Indication of Compromise rule states for a host:

Access: Admin/Any Security Analyst

Step 1 In a host profile, click Edit Rule States in the Indications of Compromise section.

The Edit Indication of Compromise Rule States page appears in a new window.

Step 2 In the Enabled column for a rule, click the slider to enable or disable it.

Step 3 Click Save.

Your changes are saved.

Viewing Source Events for Indications of Compromise

License: FireSIGHT

You can use the Indications of Compromise section to navigate quickly to the events that triggered IOC tags on a host. Analyzing these events can give you the information you need to determine what, and whether, action is required to address threats to a potentially compromised host.

) next to the timestamp of an IOC tag navigates to the table view of events for the relevant event type, constrained to show only the event that triggered the IOC tag.

For more information on the types of events and features that trigger IOC tags, see the following:

- Working with Connection & Security Intelligence Data

- Working with Intrusion Events

- Understanding Malware Protection and File Control

To view source events for an Indications of Compromise tag:

Access: Admin/Any Security Analyst

column for the IOC tag you want to investigate.

The table view of events for the appropriate event that triggered the IOC appears, constrained to show only the triggering event. If you are viewing the host profile page in a separate window, the event view appears in the main window.

Resolving Indications of Compromise

License: FireSIGHT

). Note that you can still view the IOC-triggering events for the resolved IOC.

If the events that triggered a host’s IOC tag recur, the tag is set again. You can resolve individual IOC tags on a host or mark all of a host’s tags as resolved.

To resolve an Indications of Compromise tag:

Access: Admin/Any Security Analyst

Step 1 In the host profile’s Indications of Compromise section, you have two options:

- To mark an individual IOC tag resolved, click the resolve icon (

) to the right of the tag you want to resolve.

- To mark all IOC tags on a host resolved, click Mark All Resolved .

Your changes are saved and the IOC tags you selected are removed.

Working with Operating Systems in the Host Profile

License: FireSIGHT

The system passively detects the identity of the operating system running on a host by analyzing the network and application stack in traffic generated by the host or by analyzing host data reported by the User Agent. The system also collates operating system information from other sources, such as the Nmap scanner or application data imported through the host input feature. The system considers the priority assigned to each identity source when determining which identity to use. By default, user input has the highest priority, followed by application or scanner sources, followed by the Cisco-discovered identity.

Sometimes the system supplies a general operating system definition rather than a specific one because the traffic and other identity sources do not provide sufficient information for a more focused identity. The system collates information from the sources to use the most detailed definition possible.

Descriptions of the operating system information fields displayed in the host profile follow.

Hardware

The hardware platform for a mobile device.

OS Vendor/Vendor

The operating system vendor.

OS Product/Product

The operating system determined most likely to be running on the host, based on the identity data collected from all sources.

If the operating system is Pending, the system has not yet identified an operating system and no other identity data is available. If the operating system is unknown, the system cannot identify the operating system and no other identity data is available for the operating system.

If the host’s operating system is not one the system is capable of detecting, you may want to use one of the following strategies:

– create a custom fingerprint for the host, as described in Using Custom Fingerprinting

– run an Nmap scan against the host, as described in Scanning a Host from the Host Profile

– import data into the network map, using the host input feature described in the FireSIGHT System Host Input API Guide

– manually enter operating system information, as described in Working with Operating Systems in the Host Profile

OS Version/Version

The operating system version. If a host is a jailbroken mobile device, Jailbroken is indicated in parentheses after the version.

Source

One of the following values:

– User: user_name

– Application: app_name

– Scanner: scanner_type (Nmap or scanner added through system policy)

– FireSIGHT

The system may reconcile data from multiple sources to determine the identity of an operating system; see Understanding Current Identities.

Because the vulnerabilities list for the host and the event impact correlation for events targeting the host depend on the operating system, you may want to manually supply more specific operating system information. In addition, you can indicate that fixes have been applied to the operating system, such as service packs and updates, and invalidate any vulnerabilities addressed by the fixes.

For example, if the system identifies a host’s operating system as Microsoft Windows 2003, but you know that the host is actually running Microsoft Windows XP Professional with Service Pack 2, you can set the operating system identity accordingly. Setting a more specific operating system identity refines the list of vulnerabilities for the host, so your impact correlation for that host is more focused and accurate.

If the system detects operating system information for a host and that information conflicts with a current operating system identity that was supplied by an active source, an identity conflict occurs. When an identity conflict is in effect, the system uses both identities for vulnerabilities and impact correlation.

Although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, there is no operating system data available for these hosts, unless you set the operating system identity. For more information, see Differences Between NetFlow and FireSIGHT Data.

). In addition, if a jailbroken mobile device violates an active white list, the icon appears next to the operating system for the device.

You can set a custom display string for the host’s operating system identity. That display string is then used in the host profile.

Note Note that changing the operating system information for a host may change its compliance with a compliance white list.

In the host profile for a network device, the label for the Operating Systems section changes to Systems and an additional Hardware column appears. If a value for a hardware platform is listed under Systems, that system represents a mobile device or devices detected behind the network device. Note that mobile devices may or may not have hardware platform information, but hardware platform information is never detected for systems that are not mobile devices.

Viewing Operating System Identities

License: FireSIGHT

You can view the specific operating system identities discovered or added for a host. The system uses source prioritization to determine the current identity for the host. In the list of identities, the current identity is highlighted by boldface text.

For each operating system identity, the host profile may include the information described in Working with Operating Systems in the Host Profile.

Note that the View button is only available if multiple operating system identities exist for the host.

To view the list of operating system identities for a host:

Access: Admin/Any Security Analyst

Step 1 Click View in the Operating System or Operating System Conflicts section of the host profile.

The Operating System Identity Information pop-up window appears.

Editing an Operating System

License: FireSIGHT

You can set the current operating system identity for a host using the FireSIGHT System web interface. Setting the identity through the web interface overrides all other identity sources so that identity is used for vulnerability assessment and impact correlation. However, note that if the system detects a conflicting operating system identity for the host after you edit the operating system, an operating system conflict occurs.

Both operating systems are then considered current until you resolve the conflict. For more information, see Resolving Operating System Identity Conflicts.

To change the operating system identity:

Access: Admin/Any Security Analyst

Step 1 In a host profile, click Edit in the Operating System section.

A pop-up window appears where you can set the operating system identity.

Step 2 You have several options:

- Select Current Definition from the OS Definition drop-down list to confirm the current operating system identity through host input, then skip to step 6 .

- Select a variation on the current operating system identity from the OS Definition drop-down list, then skip to step 6 .

- Select User-Defined from the OS Definition drop-down list, then continue with step 3 .

Step 3 Optionally, select Use Custom Display String and modify the custom strings you want to display in the Vendor String, Product String, and Version String fields.

Step 4 Optionally, to change to an operating system from a different vendor, select the vendor and other operating system details from the Vendor and Product drop-down lists.

Step 5 Optionally, to configure the operating system product release level, select the applicable items in the Major, Minor, Revision, Build, Patch, and Extension drop-down lists.

Step 6 Optionally, if you want to indicate that fixes for the operating system have been applied, click Configure Fixes.

The list of available package fixes displays.

Step 7 Choose the applicable fixes in the drop-down list and click Add.

Step 8 Optionally, add the relevant patches and extensions using the Patch and Extension drop-down lists.

Step 9 Click Finish to complete the operating system identity configuration.

Resolving Operating System Identity Conflicts

License: FireSIGHT

An operating system identity conflict occurs when a new identity detected by the system conflicts with the current identity, if that identity was provided by an active source, such as a scanner, application, or user.

The list of operating system identities in conflict displays in bold in the host profile.

You can resolve an identity conflict and set the current operating system identity for a host through the system web interface. Setting the identity through the web interface overrides all other identity sources so that identity is used for vulnerability assessment and impact correlation.

To make one of the conflicting identities current:

Access: Admin/Any Security Analyst

Step 1 You have two options:

- Click Make Current next to the operating system identity you want to set as the operating system for the host.

- If the identity that you do not want as the current identity came from an active source, delete the unwanted identity.

To resolve an operating system identity conflict:

Access: Admin/Any Security Analyst

Step 1 In a host profile, click Resolve in the Operating System Conflicts section.

A pop-up window appears where you can set the current operating system identity.

Step 2 You have several options:

- Select Current Definition from the OS Definition drop-down list to confirm the current operating system identity through host input, then skip to step 6 .

- Select a variation on one of the conflicting operating system identities from the OS Definition drop-down list, then skip to step 6 .

- Select User-Defined from the OS Definition drop-down list, then continue with step 3 .

Step 3 Optionally, select Use Custom Display String and type the custom strings you want to display in the Vendor String, Product String, and Version String fields.

Step 4 Optionally, to change to an operating system from a different vendor, select the vendor and other operating system details.

Step 5 Optionally, to configure the operating system product release level, select the applicable items in the Major, Minor, Revision, Build, Patch, and Extension drop-down lists.

Step 6 Optionally, if you want to indicate that fixes for the operating system have been applied, click Configure Fixes.

Step 7 Add the fixes you have applied to the fixes list.

Step 8 Click Finish to complete the operating system identity configuration and return to the host profile.

Working with Servers in the Host Profile

License: FireSIGHT

If the system detects servers running on a host on your monitored network or if servers are added through the host input feature or through a scanner or other active source, the Defense Center lists them in the Servers section of the host profile.

The Defense Center lists up to 100 servers per host. After that limit is reached, new server information from any source, whether active or passive, is discarded until you delete a server from the host or a server times out. For more information, see Host Limits and Discovery Event Logging.

If you scan a host using Nmap, Nmap adds the results of previously undetected servers running on open TCP ports to the Servers list. If you perform an Nmap scan on a host or import Nmap results, an expandable Scan Results section also appears in the host profile, listing the server information detected on the host by the Nmap scan. See Working with Scan Results in a Host Profile and Setting up Nmap Scans for more information. In addition, note that if the host is deleted from the network map, the Nmap scan results for that server for the host are discarded.

Note Although you can configure your network discovery policy to add server and clients to the network map based on data exported by NetFlow-enabled devices, the available information about these applications is limited. For more information, see Differences Between NetFlow and FireSIGHT Data.

The process for working with servers in the host profile differs depending on how you accessed the profile:

- If you accessed the host profile by drilling down through the Servers network map, the details for that server appear with the server name highlighted in bold. If you want to view the details for any other server on the host, click the view icon (

) next to that server name.

- If you accessed the host profile in any other way, expand the Servers section and click the view icon (

) next to the server whose details you want to see.

You can also perform the following actions:

- To analyze the connection events associated with a particular server on the host, click the events icon next to the server.

The first page of your preferred workflow for connection events appears, showing connection events constrained by the port and protocol of the server, as well as the IP address of the host. If you do not have a preferred workflow for connection events, you must select one. For more information about connection data, see Working with Connection & Security Intelligence Data.

- To delete a server from the host profile, click the delete icon (

) next to the server.

The server is deleted from the host profile, but will appear again if the system detects traffic from the server again. Note that deleting a server from a host may bring the host into compliance with a white list.

- To resolve a server identity conflict, click the resolve icon next to the server.

You can choose one of the conflicting identities, choose a variation on one of those identities, or set a new user-defined identity.

- To edit a server identity, click the edit icon (

) next to the server.

You can choose the current identity, choose a variation on that identity, or set a new user-defined identity.

Descriptions of the columns in the Servers list follow.

Protocol

The name of the protocol the server uses.

Port

The port where the server runs.

Application Protocol

One of:

– the name of the application protocol

– pending, if the system cannot positively or negatively identify the application protocol for one of several reasons

– unknown, if the system cannot identify the application protocol based on known application protocol fingerprints or if the server was added through host input by adding a vulnerability with port information without adding a corresponding server

When you hover the mouse on an application protocol name, the tags display. For information on tags, see Understanding Application Detection.

Vendor and Version

The vendor and version identified by the FireSIGHT System, by Nmap, or by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.

).

See the following sections for more information:

- Server Detail

- Editing Server Identities

- Resolving Server Identity Conflicts

Server Detail

License: FireSIGHT

The Defense Center lists up to 16 passively detected (Cisco- or NetFlow-detected) identities per server. A server can have multiple passive identities if the system detects multiple vendors or versions of that server. For example, a load balancer between your managed device and your web server farm may cause your system to identify multiple passive identities for HTTP if your web servers are not running the same version of the server software. Note that the Defense Center does not limit the number of server identities from active sources such as user input, scanners, or other applications.

The Defense Center displays the current identity in bold. The system uses the current identity of a server for multiple purposes, including assigning vulnerabilities to a host, impact assessment, evaluating correlation rules written against host profile qualifications and compliance white lists, and so on.

Tip For information on changing the server identity and resolving identity conflicts from the server detail, see Editing Server Identities and Resolving Server Identity Conflicts.

The server detail may also display updated sub-server information known about the selected server. Finally, the server detail may display the server banner, which appears below the server details when you view a server from the host profile.

Server banners provide additional information about a server that may help you identify the server. The system cannot identify or detect a misidentified server when an attacker purposely alters the server banner string. The server banner displays the first 256 bytes of the first packet detected for the server. It is collected only once, the first time the server is detected by the system. Banner content is listed in two columns, with a hexadecimal representation on the left and a corresponding ASCII representation on the right.

Note To view server banners, you must enable the Capture Banners check box in the network discovery policy. This option is disabled by default.

Descriptions of the information provided in the server detail follow.

Protocol

The name of the protocol the server uses.

Port

The port where the server runs.

Hits

The number of times the server was detected by a Cisco managed device or Nmap. Note that the number of hits is 0 for servers imported through host input, unless the system detects traffic for that server.

Last Used

The time and date the server was last detected. Note that the last used time for host input data reflects the initial data import time, unless the system detects new traffic for that server. Note also that scanner and application data imported through the host input feature times out according to settings in the system policy, but user input through the Defense Center web interface does not time out.

Application Protocol

The name of the application protocol used by the server, if known.

Vendor

The server vendor. This field does not appear if the vendor is unknown.

Version

The server version. This field does not appear if the version is unknown.

Source

One of the following values:

– User: user_name

– Application: app_name

– Scanner: scanner_type (Nmap or scanner added through system policy)

– FireSIGHT, FireSIGHT Port Match, or FireSIGHT Pattern Match, for Cisco-detected applications

– NetFlow, for servers added to the network map based on NetFlow data

The system may reconcile data from multiple sources to determine the identity of a server; see Understanding Current Identities.

To view the server detail for a server:

Access: Admin/Any Security Analyst

section of a host profile.

The Server Detail pop-up window appears.

Editing Server Identities

License: FireSIGHT

You can manually update the identity settings for a server on a host and configure any fixes that you have applied to the host to remove the vulnerabilities addressed by the fixes. You can also delete server identities.

Note that deleting an identity does not delete the server, even if that is the only identity. Deleting an identity does remove the identity from the Server Detail pop-up window and, if applicable, updates the current identity for the server in the host profile.

You cannot edit or delete server identities added by a Cisco-managed device.

To edit the server identity:

Access: Admin/Any Security Analyst

Step 1 In the Servers section in a host profile, click View to open the Server Detail pop-up window.

Step 2 You have two options:

- To delete a server identity, click the delete icon (

) next to the server identity you want to remove.

- To modify a server identity, click the edit icon (

) next to the server in the servers list.

The Server Identity pop-up window appears.

Step 3 You have two options:

- Select the current definition from the Select Server Type drop-down list.

- Select the type of server from the Select Server Type drop-down list.

Step 4 Optionally, to only list vendors and products for that server type, select the Restrict by Server Type check box.

Step 5 Optionally, to customize the name and version of the server, select the Use Custom Display String and type a Vendor String and Version String.

Step 6 In the Product Mappings section, select the operating system, product, and versions you want to use.

For example, if you want the server to map to Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Step 7 If you want to indicate that fixes for the server have been applied, click Configure Fixes. Otherwise, skip to step 9.

The Available Package Fixes page appears.

Step 8 Add the patches you want to apply for that server to the fixes list.

Step 9 Click Finish to complete the server identity configuration.

Resolving Server Identity Conflicts

License: FireSIGHT

A server identity conflict occurs when an active source, such as an application or scanner, adds identity data for a server to a host, then the system detects traffic for that port that indicates a conflicting server identity.

To resolve a server identity conflict:

Access: Admin/Any Security Analyst

Step 1 Click the resolve icon next to the server in the Servers list.

The Server Identity pop-up window appears.

Step 2 Select the type of server from the Select Server Type drop-down list.

Step 3 Optionally, to only list vendors and products for that server type, select the Restrict by Server Type check box.

Step 4 Optionally, to customize the name and version of the server, select the Use Custom Display String and type a Vendor String and Version String.

Step 5 In the Product Mappings section, select the operating system, product, and versions you want to use.

For example, if you want the server to map to Red Hat Linux 9, select Redhat, Inc. as the vendor, Redhat Linux as the product, and 9 as the version.

Step 6 If you want to indicate that fixes for the server have been applied, click Configure Fixes. Otherwise, skip to step 9.

The Available Package Fixes page appears.

Step 7 Add the patches you want to apply for that server to the fixes list.

Step 8 Click Finish to complete the server identity configuration and return to the host profile.

Working with Applications in the Host Profile

License: FireSIGHT

You can see the applications running on a host in the host profile. If you want to remove an application from a host profile, you can delete that application.

For more information on managing applications in the host profile, see:

- Viewing Applications in the Host Profile

- Deleting Applications from the Host Profile

Viewing Applications in the Host Profile

License: FireSIGHT

The system can detect a variety of clients and web applications running on the hosts on your network.

Note Note that you must select the Applications check box in discovery rules for NetFlow devices in your network discovery policy for the system to detect applications on the hosts in your monitored network. This option is enabled by default in NetFlow rules and cannot be disabled for rules used for discovery via managed devices.

The host profile displays the product and version of the detected applications on a host, any available client or web application information, and the time that the application was last detected in use.

The Defense Center lists up to 16 clients running on the host. After that limit is reached, new client information from any source, whether active or passive, is discarded until you delete a client application from the host or the system deletes the client from the host profile due to inactivity (the client times out).

Additionally, for each detected web browser, the host profile displays the first 100 web applications accessed. After that limit is reached, new web applications associated with that browser from any source, whether active or passive, are discarded until either:

- the web browser client application times out, or

- you delete application information associated with a web application from the host profile

Descriptions of the application information that appears in a host profile follow.

Application Protocol

Displays the application protocol used by the application (HTTP browser, DNS client, and so on).

Client

Client information derived from payload if identified by the FireSIGHT System, or captured by Nmap, or by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.

Version

Displays the version of the client.

Web Application

For web browsers, the content detected by the system in the http traffic. Web application information indicates the specific type of content (for example, WMV or QuickTime) identified by the FireSIGHT System, captured by Nmap, captured by another active source, or acquired via the host input feature. The field is blank if none of the available sources provides an identification.

).

) next to the application. The first page of your preferred workflow for connection events appears, showing connection events constrained by the type, product, and version of the application, as well as the IP address(es) of the host. If you do not have a preferred workflow for connection events, you must select one. For more information about connection data, see Working with Connection & Security Intelligence Data.

Deleting Applications from the Host Profile

License: FireSIGHT

You can delete an application from a host profile to remove applications that you know are not running on the host. Note that deleting an application from a host may bring the host into compliance with a white list.

Note If the system detects the application again, it re-adds it to the network map and the host profile.

To delete an application from a host profile:

Access: Admin/Any Security Analyst

) next to the application you want to delete.

The application is deleted for that host.

Working with VLAN Tags in the Host Profile

License: FireSIGHT

The VLAN Tag section of the host profile appears if the host is a member of a Virtual LAN (VLAN).

Physical network equipment often uses VLANs to create logical network segments from different network blocks. The system detects 802.1q VLAN tags and displays the following information for each:

- VLAN ID identifies the VLAN where the host is a member. This can be any integer between zero and 4095 for 802.1q VLANs.

- Type identifies the encapsulated packet containing the VLAN tag, which can be either Ethernet or Token Ring.

- Priority identifies the priority in the VLAN tag, which can be any integer from zero to 7, where 7 is the highest priority.

If VLAN tags are nested within the packet, the system processes and the Defense Center displays the innermost VLAN tag. The system collects and the Defense Center displays VLAN tag information only for MAC addresses that it identifies through ARP and DHCP traffic.

VLAN tag information can be useful, for example, if you have a VLAN composed entirely of printers and the system detects a Microsoft Windows 2000 operating system in that VLAN. VLAN information also helps the system generate more accurate network maps.

Working with User History in the Host Profile

License: FireSIGHT

The user history portion of the host profile provides a graphic representation of the last twenty-four hours of user activity. A typical user logs off in the evening and may share the host resource with another user. Periodic login requests, such as those made to check email, are indicated by short regular bars. A list of user identities is provided with bar graphs to indicate when the user login was detected. Note that for non-authoritative logins, the bar graph is gray.

Note that the system does associate a non-authoritative user login to a host with an IP address of that host, so the user does appear in the host’s user history. However, if an authoritative user login is detected for the same host, the user associated with the authoritative user login takes over the association with the host IP address, and new non-authoritative user logins do not disrupt that user association with the host IP address. For more information on the types of users, see Users Database. If you configure capture of failed logins in the network discovery policy, the list includes users that failed to log into the host.

Working with Host Attributes in the Host Profile

License: FireSIGHT

You can use host attributes to classify hosts in ways that are important to your network environment. Host attribute values can be positive integers, strings, or URLs. You can also create a list of string values and assign them automatically based on host IP addresses. For information about creating and managing user-defined host attributes, see Working with User-Defined Host Attributes.

The FireSIGHT System includes two predefined host attributes: Host Criticality and Notes. See Working with the Predefined Host Attributes for information about working with these predefined host attributes.

In addition, each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are Compliant (for hosts that are compliant with the white list), Non-Compliant (for hosts that violate the white list), or Not Evaluated (for hosts that are not valid targets of the white list or have not been evaluated for any reason). You cannot manually change the value of a white list host attribute. For more information on white lists, see Using the FireSIGHT System as a Compliance Tool.

Assigning Host Attribute Values

License: FireSIGHT

You can specify positive integers, strings, or URLs as values for existing host attributes.

Tip You can quickly assign host attributes for a host by clicking the Edit link in the Attributes section of the host profile page. This launches a pop-up window containing fields for all the host attributes.

To assign a host attribute value:

Access: Admin/Any Security Analyst

Step 1 Open a host profile.

Step 2 Under Attributes, click the name of the host attribute to which you want to assign a value.

A pop-up window appears.

Step 3 Enter a value for the attribute or select a value from the drop-down list.

Step 4 Click Save.

The host attribute value is saved.

Working with Host Protocols in the Host Profile

License: FireSIGHT

You can view the protocols running on a host through the host profile. If needed, you can also delete host protocols for a particular host from the profile.

Each host profile contains information about the protocols detected in the network traffic associated with the host.

Descriptions of the protocol and network layer information follow.

Protocol

The name of a protocol used by the host.

Layer

The network layer where the protocol runs (Network or Transport).

).

You can delete a protocol from a host profile to remove protocols you know are not running on the host. Note that deleting a protocol from a host may bring the host into compliance with a compliance white list.

Note If the system detects the protocol again, it re-adds it to the network map and the host profile.

To delete a protocol from a host profile:

Access: Admin/Any Security Analyst

) next to the protocol you want to delete.

The protocol is deleted for that host.

Working with White List Violations in the Host Profile

License: FireSIGHT

A compliance white list (or white list) is a set of criteria that allows you to specify the operating systems, application protocols, clients, web applications, and protocols that are allowed to run on a specific subnet.

If you add a white list to an active correlation policy, when the system detects that a host is violating the white list, the Defense Center logs a white list event—which is a special kind of correlation event— to the database. Each of these white list events is associated with a white list violation, which indicates how and why a particular host is violating a white list. If a host violates one or more white lists, you can view these violations in its host profile in two ways.

First, the host profile lists all of the individual white list violations associated with the host.

Descriptions of the white list violation information in the host profile follow.

Type

The type of the violation, that is, whether the violation occurred as a result of a non-compliant operating system, application, server, or protocol.

Reason

The specific reason for the violation. For example, if you have a white list that allows only Microsoft Windows hosts, the host profile displays the current operating system running on the host (such as Linux Linux 2.4, 2.6)

White List

The name of the white list associated with the violation.

). For example, for a white list that allows only Microsoft Windows hosts, the host profile displays the white list violation icon next to the operating system information for that host.

Note that you can use a host’s profile to create a shared host profile for compliance white lists. For more information, see the next section, Creating a White List Host Profile from a Host Profile.

Creating a White List Host Profile from a Host Profile

License: FireSIGHT

Shared host profiles for compliance white lists specify which operating systems, application protocols, clients, web applications, and protocols are allowed to run on target hosts across multiple white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

You can use a host profile of any host with a known IP address to create a shared host profile that your compliance white lists can use. However, note that you cannot create a shared host profile based on an individual host's host profile if the system has not yet identified the operating system of the host.

To create a shared host profile for compliance white lists based on a host profile:

Access: Admin

Step 1 Access a host profile from any network map or any event view.

For more information, see Viewing Host Profiles.

Step 2 Click Generate White List Profile.

The Edit Shared Profiles page appears. The fields on the page are pre-populated based on the information in the host profile you accessed.

Step 3 Modify and save the shared host profile according to your specific needs.

For more information on creating shared host profiles for compliance white lists, see Working with Shared Host Profiles.

Working with Malware Detections in the Host Profile

License: FireSIGHT and Malware

The Most Recent Malware Detections section lists the most recent malware events where the host sent or received a malware file, up to 100 events. The host profile lists both network-based and endpoint-based malware events.

If the host is involved in a file event where the file is then retrospectively identified as malware, the original events where the file was transmitted appear in the malware detections list after the malware identification occurs. When a file identified as malware is retrospectively determined not to be malware, the malware events related to that file no longer appear in the list. For example, if a file has a disposition of Malware and that disposition changes to Clean, the event for that file is removed from the malware detections list on the host profile. For more information on malware events, see Working with Malware Events.

Description of the columns in the Most Recent Malware Detections sections of the host profile follow.

Time

The date and time the event was generated.

For an event where the file was retrospectively identified as malware, note that this is the time of the original event, not the time when the malware was identified.

Host Role

The host’s role in the transmission of detected malware, either sender or receiver. Note that for endpoint-based malware events, the host is always the receiver.

Threat Name

The name of the detected malware.

File Name

The name of the malware file.

File Type

The type of file; for example, PDF or MSEXE.

).

Working with Vulnerabilities in the Host Profile

License: FireSIGHT

The Vulnerabilities sections of the host profile list the vulnerabilities that affect that host.

The Sourcefire Vulnerabilities section lists vulnerabilities based on the operating system, servers, and applications that the system detected on the host.

If there is an identity conflict for either the identity of the host’s operating system or one of the application protocols on the host, the system lists vulnerabilities for both identities until the conflict is resolved.

Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot determine which vulnerabilities may affect those hosts, unless you use the host input feature to manually set the hosts’ operating system identity.

Server vendor and version information is often not included in traffic. By default, the system does not map the associated vulnerabilities for the sending and receiving hosts of such traffic. However, using the system policy, you can configure the system to map vulnerabilities for specific application protocols that do not have vendor or version information. For more information, see Mapping Vulnerabilities for Servers.

If you use the host input feature to add third-party vulnerability information for the hosts on your network, additional Vulnerabilities sections appear. For example, if you import vulnerabilities from a QualysGuard Scanner, host profiles on your include a QualysGuard Vulnerabilities section.

You can associate third-party vulnerabilities with operating systems and application protocols, but not clients. For information on importing third-party vulnerabilities, see the FireSIGHT System Host Input API Guide.

Description of the columns in the Vulnerabilities sections of the host profile follow.

Name

The name of the vulnerability.

Remote

Indicates whether the vulnerability can be remotely exploited. If this column is blank, the vulnerability definition does not include this information.

Component

The name of the operating system, application protocol, or client associated with the vulnerability.

Port

A port number, if the vulnerability is associated with an application protocol running on a specific port.

Keep in mind that for third-party vulnerabilities, the information in the corresponding Vulnerabilities section in the host profile is limited to the information that you provided when you imported the vulnerability data using the host input feature.

When viewing vulnerabilities in the host profile, you can:

- sort the columns in the Vulnerabilities sections by clicking a column heading. To reverse the sort, click again.

- view technical details about a vulnerability, including known solutions, by clicking the name of the vulnerability. See Viewing Vulnerability Details for more information. Note that you can also access vulnerability details from the vulnerability event views or the Vulnerabilities network map.

- prevent a vulnerability from being used to evaluate impact correlations. See Setting the Vulnerability Impact Qualification for more information.

- download patches to mitigate the vulnerabilities discovered on the hosts on your network. See Downloading Patches for Vulnerabilities for more information.

- mark hosts as not vulnerable to individual vulnerabilities if you know that the hosts have been patched. See Setting Vulnerabilities for Individual Hosts for more information.

Viewing Vulnerability Details

License: FireSIGHT

Vulnerability details include a technical description of the vulnerability and known solutions.

) next to the SVID. You can also access vulnerability details from the network map and the host profile.

Descriptions of the fields on the Vulnerability Detail page follow.

Cisco Vulnerability ID

The identification number (SVID) that the system uses to track vulnerabilities.

Snort ID

The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID.

Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If the vulnerability does not have an associated SID, this field does not appear.

BugTraq ID

The identification number associated with the vulnerability in the Bugtraq database (http://www.securityfocus.com/bid).

CVE ID

The identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures (CVE) database (http://www.cve.mitre.org/).

Title

The title of the vulnerability.

Impact Qualification

Use the drop-down list to enable or disable a vulnerability. The Defense Center ignores disabled vulnerabilities in its impact correlations.

The setting you specify here determines how the vulnerability is treated on a system-wide basis and is not limited to the host profile where you select the value. See Setting the Vulnerability Impact Qualification for information about using this feature to enable and disable a vulnerability.

Date Published

The date that the vulnerability was published.

Vulnerability Impact

The severity assigned to the vulnerability in the Bugtraq database on a scale of 1 to 10, with 10 being the most severe. The vulnerability impact is determined by the writer of the Bugtraq entry, who determines the vulnerability impact level based on his or her best judgment, guided by SANS Critical Vulnerability Analysis (CVA) criteria.

Remote

Indicates whether the vulnerability is remotely exploitable.

Available Exploits

Indicates whether there are known exploits for the vulnerability.

Description

Summary description of the vulnerability.

Technical Description

Detailed technical description of the vulnerability.

Solution

Information about repairing the vulnerability.

Additional Information

Click the arrow to view additional information (if available) about the vulnerability, such as known exploits and their availability, exploit scenarios, and mitigation strategies.

Fixes

Provides links to downloadable patches for the selected vulnerability.

Tip If direct links to fix or patch downloads appear, right-click the link and save it to your local computer.

Setting the Vulnerability Impact Qualification

License: FireSIGHT

If the system reports a vulnerability that is not applicable to your network, you can prevent it from being used to evaluate impact flag correlations. Note that if you deactivate a vulnerability in a host profile, it deactivates it for all hosts on your network. You can, however, reactivate it at any time.

When a conflict exists for the identity of the host’s operating system or one of the applications on the host, the system lists vulnerabilities for both conflicting identities until the conflict is resolved. For more information, see Understanding Identity Conflicts and Resolving Operating System Identity Conflicts.

Note also that the system does not recommend a rule state for an intrusion rule based on a vulnerability that you disable using the Impact Qualification feature. For more information, see Tailoring Intrusion Protection to Your Network Assets.

Tip You can also deactivate vulnerabilities from the network map and from vulnerability event views. For more information, see Working with the Vulnerabilities Network Map and Deactivating Vulnerabilities.

To change the use of a vulnerability across the system:

Access: Admin/Any Security Analyst

Step 1 Access the host profile of a host affected by the vulnerability you want to deactivate.

Step 2 Expand the Vulnerabilities section.

Step 3 Click the name of the vulnerability you want to enable or disable.

A pop-up window appears with the vulnerability details. For more information, see Viewing Vulnerability Details.

Step 4 Select Disabled or Enabled from the Impact Qualification drop-down list to specify how the vulnerability is used.

Step 5 Confirm that you want to change the Impact Qualification for all hosts on the network map.

The vulnerability is enabled or disabled.

Step 6 Click Done to close the vulnerability details pop-up window.

Downloading Patches for Vulnerabilities

License: FireSIGHT

If they are available, you can download patches to mitigate the vulnerabilities discovered on the hosts on your network.

To download a patch for a vulnerability:

Access: Admin/Any Security Analyst

Step 1 Access the host profile of a host for which you want to download a patch.

Step 2 Expand the Vulnerabilities section.

Step 3 Click the name of the vulnerability you want to patch.

The Vulnerability Detail page appears.

Step 4 Expand the Fixes section.

The list of downloadable patches for the vulnerability appears.

Step 5 Click Download next to the patch you want to download.

A download page from the patch vendor appears.

Step 6 Download the patch and apply it to your affected systems.

Setting Vulnerabilities for Individual Hosts

License: FireSIGHT

You can use the host vulnerability editor to activate or deactivate vulnerabilities on a host-by-host basis. When you deactivate a vulnerability for a host, it is still used for impact correlations for that host, but the impact level is automatically reduced one level.

To activate or deactivate a vulnerability for a single host:

Access: Admin/Security Analyst

Step 1 Open a host profile.

Step 2 Next to Vulnerabilities, click Edit.

The Host Vulnerabilities editor page appears.

Tip To view details about a vulnerability, select it and click View. For more information, see Viewing Vulnerability Details.

Step 3 You have two options:

- To deactivate a vulnerability, select it from the Valid Vulnerabilities list, then click the down arrow.

- To activate a vulnerability, select it from the Invalid Vulnerabilities list, then click the up arrow.

Tip Use Ctrl or Shift while clicking to select multiple vulnerabilities. You can click and drag to select multiple adjacent vulnerabilities; you can also double-click any vulnerability to move it from list to list.

Step 4 Click Save.

Your changes are saved.

Working with the Predefined Host Attributes

License: FireSIGHT

There are two predefined host attributes that you can assign to each host: host criticality and host-specific notes. Use the host criticality attribute to designate the business criticality of a given host and to tailor correlation policies and alerts based on host criticality. For example, if you consider your organization’s mail servers more critical to your business than a typical user workstation, you can assign a value of High to your mail servers and other business-critical devices and Medium or Low to other hosts. You can then create a correlation policy that launches different alerts based on the criticality of an affected host.

Use the Notes feature to record information about the host that you want other analysts to view. For example, if you have a computer on the network that has an older, unpatched version of an operating system that you use for testing, you can use the Notes feature to indicate that the system is intentionally unpatched.

To set pre-defined host attributes in the host profile:

Access: Admin/Security Analyst

Step 1 Open the host profile for the host for which you want to set a business criticality.

).

The Host Attributes pop-up window appears.

Step 3 Form the Host Criticality drop-down list, select the value you want to apply: None, Low, Medium, or High.

Step 4 Click Save.

Your selection is saved.

Working with User-Defined Host Attributes

License: FireSIGHT

The FireSIGHT System includes two predefined host attributes, host criticality and host notes, that you can use to indicate the business criticality of the hosts on your network. If you have other criteria that you would like to use to identify your hosts, you can create user-defined host attributes.

User-defined host attributes appear in the host profile page, where you can assign values on a per-host basis. You can then use those attributes in correlation policies and searches. You can also view the attributes on the host attribute table view of events and generate reports based on them.

Note Host attributes are defined globally rather than per policy. After you create a host attribute, it is available regardless of the policy applied.

Some examples of user-defined host attributes include:

- assigning physical location identifiers to hosts, such as a facility code, city, or room number.

- assigning a Responsible Party Identifier that indicates which system administrator is responsible for a given host. You can then craft correlation rules and policies to send alerts to the correct system administrator when problems related to a host are detected.

Host attributes can be text strings or values selected from predefined lists of text or ranges of numbers. You can also automatically assign values to hosts from a predefined list based on the hosts’ IP addresses. You can use this feature to automatically assign values to new hosts when they appear on your network for the first time.

Host attributes can be one of the following types:

Text

Allows you to manually assign a text string up to 255 characters to a host.

Integer

Allows you to specify the first and last number of a range of positive integers, then manually assign one of these numbers to a host.

List

Allows you to create a list of string values, then manually assign one of the values to a host. You can also automatically assign values to hosts based on the host’s IP addresses.

Note If you auto-assign values based on one IP address of a host with multiple IP addresses, those values will apply across all addresses associated with that host. Keep this in mind when you view the Host Attributes table.

URL

Allows you to manually assign a URL value to a host.

Note that each compliance white list that you create automatically creates a host attribute with the same name as the white list. Its possible values are Compliant (for hosts that are compliant with the white list), Non-Compliant (for hosts that violate the white list), and Not Evaluated (for hosts that are not valid targets of the white list or have not been evaluated for any reason). You cannot manually change the value of a white list host attribute. For more information on white lists, see Using the FireSIGHT System as a Compliance Tool.

See the following sections for more information:

- Creating User-Defined Host Attributes

- Editing a User-Defined Host Attribute

- Deleting a User-Defined Host Attribute

Creating User-Defined Host Attributes

License: FireSIGHT

The following procedure explains how to create a user-defined host attribute.

Note Host attributes are defined globally rather than per policy. After you create a host attribute, it is available regardless of the policy applied.

To create a new host attribute:

Access: Admin/Discovery Admin

Step 1 Select Analysis > Hosts > Host Attributes.

The Host Attributes page appears.

Step 2 Click Host Attribute Management.

The Host Attribute Management page appears.

Step 3 Click Create Attribute.

The Create Attribute page appears.

Step 4 In the Name field, type a name for the host attribute using alphanumeric characters and spaces.

Step 5 Select the type of attribute that you want to create from the Type drop-down list, as described in Working with Host Attributes in the Host Profile:

- If you are creating a Text or URL host attribute, continue with step 6 .

- If you are creating an Integer host attribute, see Creating Integer Host Attributes.

- If you are creating a List host attribute, see Creating List Host Attributes.

Step 6 Click Save.

The new user-defined host attribute is saved.

Creating Integer Host Attributes

License: FireSIGHT

When you define an integer-based host attribute, you must specify the range of numbers that the attribute accepts.

To create an integer-based host attribute:

Access: Admin/Discovery Admin

Step 1 In the Min field, enter the minimum integer value that can be assigned to a host.

Step 2 In the Max field, enter the maximum integer value that can be assigned to a host.

Step 3 Click Save.

The new integer-based host attribute is saved.

Creating List Host Attributes

License: FireSIGHT

When you define a list-based host attribute, you must supply each of the values for the list. These values can contain alphanumeric characters, spaces, and symbols.

When you create a value for the host attribute, you can also auto-assign it to a block of IP addresses so that when a new host is discovered, it is automatically assigned a value for the host attribute.

To create a list-based host attribute:

Access: Admin/Discovery Admin

Step 1 To add a value to the list, click Add Value.

The List Values section expands.

Step 2 In the Name field, enter the first value you want to add, using alphanumeric characters, symbols, and spaces.

Step 3 Optionally, to auto-assign the attribute value you just added to your hosts, click Add Networks.

The Auto-Assign Networks section expands.

Step 4 Select the value you added from the Value drop-down list.

Step 5 In the IP Address and Netmask fields, enter the IP address and network mask (in CIDR notation) that represent the IP address block where you want to auto-assign this value.

For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 6 Repeat steps 1 through 5 to add additional values to the list and assign them automatically to new hosts that fall within an IP address block.

Tip If you do not want to auto-assign list values to the hosts in specific IP blocks, you can manually assign them as described in Working with the Predefined Host Attributes.

Editing a User-Defined Host Attribute

License: FireSIGHT

When you modify an existing user-defined host attribute, you can change the definition of a value, but you cannot change the attribute type (text, list, integer, URL). In addition, you cannot modify compliance white list host attributes.

To edit an existing user-defined host attribute:

Access: Admin/Discovery Admin

Step 1 Select Analysis > Hosts > Host Attributes.

The Host Attributes page appears.

Step 2 Click Host Attribute Management.

The Host Attribute Management page appears.

) next to the host attribute you want to edit.

The host attribute page appears with the selected attribute’s settings.

Step 4 Modify any of the settings that you want and click Save.

See Creating User-Defined Host Attributes for more information about the attribute types that you can edit and the values those attributes can contain.

Deleting a User-Defined Host Attribute

License: FireSIGHT

Delete a user-defined host attribute to remove it from every host profile where it is used. Note that you cannot delete compliance white list host attributes.

To delete a host attribute:

Access: Admin/Discovery Admin

Step 1 Select Analysis > Hosts > Host Attributes.

The Host Attributes page appears.

Step 2 Click Host Attribute Management.

The Host Attribute Management page appears.

) next to the host attribute you want to delete.

The selected host attribute is removed from the system.

Working with Scan Results in a Host Profile

License: FireSIGHT

When you scan a host using Nmap, or when you import results from an Nmap scan, those results appear in the host profile for any hosts included in the scan.

The information that Nmap collects about the host operating system and any servers running on open unfiltered ports is added directly into the Operating System and Servers sections of the host profile, respectively. In addition, Nmap adds a list of the scan results for that host in the Scan Results section.

Each result indicates the source of the information, the number and type of the scanned port, the name of the server running on the port, and any additional information detected by Nmap, such as the state of the port or the vendor name for the server. If you scan for UDP ports, servers detected on those ports only appear in the Scan Results section.

Note that you can run an Nmap scan from the host profile. For more information, see the next section, Scanning a Host from the Host Profile.

Scanning a Host from the Host Profile

License: FireSIGHT

You can perform a Nmap scan against a host from the host profile. After the scan completes, server and operating system information for that host are updated in the host profile. Any additional scan results are added to the Scan Results section of the host profile.

Caution Nmap-supplied server and operating system data remains static until you run another Nmap scan or override it with higher priority host input. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep Nmap-supplied operating system and server data up to date. For more information, see Automating Nmap Scans.

To scan a host from the host profile:

Access: Admin

Step 1 In the host profile, click Scan Host.

The Scan Host pop-up window appears.

Step 2 Click Scan next to the scan remediation you want to use to scan the host.

The host is scanned and the results are added to the host profile.

Working with Discovery Events

Discovery events alert you to the activity on your network and provide you with the information you need to respond appropriately. They are triggered by the changes that your managed devices detect in the network segments they monitor. Your network discovery policy specifies the kinds of data the system collects, the monitored network segments, and the specific hardware interfaces that your system uses to monitor traffic. For more information on network discovery, see Understanding Discovery Data Collection.

As a simple example of a discovery event, you may have conference rooms or spare work spaces where visiting employees attach to your network. You would expect to see New Host events generated on these segments on a regular basis, and you would not suspect malicious intent. However, if you see a New Host event on a network segment that is locked down, then you can escalate your response accordingly.

User discovery events provide information about users logged into the hosts on your network. You can view events that catalog user activity on the network and drill down to view information on a particular user. For example, if you want to see what user is associated with a new host, you can check the host profile to find out what users have been detected in traffic going to or from that host.

Discovery events provide you with much greater depth of insight into the activity on your network and with much more granularity than this simple example shows. For each monitored host, you can configure the system to detect related application protocols, network protocols, clients, users, and potential vulnerabilities. The system can also provide information on vulnerabilities detected by third-party scanners that you import onto the Defense Center using the host input feature. Indications of compromise (IOC) use intrusion, malware, and other data to identify hosts whose security may be compromised. In addition, you can track any changes in host criticality, host attribute, or vulnerability settings that users enter via the user interface.

The system provides a set of predefined workflows that you can use to analyze the discovery events that your system generates. You can also create custom workflows that display only the information that matches your specific needs.

To collect and store network discovery data for analysis, make sure that your network discovery policy is configured to discover the appropriate data on the networks and zones where your Cisco-managed devices and NetFlow-enabled devices monitor traffic. To exclude monitored areas from discovery, configure that in the network discovery policy. Note that an access control policy must be applied to the managed device before you can apply a network discovery policy. For more information, see Creating a Network Discovery Policy.

For more information, see:

- Viewing Discovery Event Statistics

- Viewing Discovery Performance Graphs

- Understanding Discovery Event Workflows

- Working with Discovery and Host Input Events

- Working with Hosts

- Working with Host Attributes

- Working with Indications of Compromise

- Working with Servers

- Working with Applications

- Working with Application Details

- Working with Vulnerabilities

- Working with Third-Party Vulnerabilities

- Working with Users

- Working with User Activity

Viewing Discovery Event Statistics

License: FireSIGHT

The Discovery Statistics page displays a summary of the hosts, events, protocols, application protocols, and operating systems detected by the system:

- The statistics summary provides general statistics about the total events, application protocols, hosts, network devices, and information about your host limit usage; see Statistics Summary.

- The event breakdown provides statistics about the types of events occurring on the system; see Event Breakdown.

- The protocol breakdown provides statistics about the protocols that detected hosts are using. See Protocol Breakdown.

- The application protocol breakdown provides statistics about the application protocols running on the network; see Application Protocol Breakdown.

- The operating system breakdown lists the operating systems that are running on the network and how many hosts are using each operating system; see OS Breakdown.

The page lists statistics for the last hour and the total accumulated statistics. You can select statistics for a particular device, or all devices. You can also view events that match the entries on the page by clicking the event, server, operating system, or operating system vendor listed within the summary.

To view the Discovery Statistics Summary:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Summary > Discovery Statistics.

The statistics summary page appears.

Step 2 From the Select Device list, select the device whose statistics you want to view. Select All to view statistics for all devices managed by the Defense Center.

Statistics Summary

License: FireSIGHT

The statistics summary provides general statistics about the total events, application protocols, hosts, network devices, and information about your host limit usage.

Descriptions of the rows of the Statistics Summary section follow.

Total Events

Total number of discovery events stored on the Defense Center.

Total Events Last Hour

Total number of discovery events generated in the last hour.

Total Events Last Day

Total number of discovery events generated in the last day.

Total Application Protocols

Total number of application protocols from servers running on detected hosts.

Total IP Hosts

Total number of detected hosts identified by unique IP address.

Total MAC Hosts

Total number of detected hosts not identified by IP address.

Note that the Total MAC Hosts statistic remains the same whether you are viewing discovery statistics for all devices or for a specific device. This is so because managed devices discover hosts based on their IP addresses. This statistic gives the total of all hosts that are identified by other means and is independent of a given managed device.

Total Routers

Total number of detected nodes identified as routers.

Total Bridges

Total number of detected nodes identified as bridges.

Host Limit Usage

Total percentage of the host limit currently in use. The host limit is defined by your FireSIGHT license. Note that the host limit usage only appears if you are viewing statistics for all managed devices. For more information on monitoring host usage, see Configuring FireSIGHT Host Usage Monitoring.

Note If the host limit is reached and a host is deleted, the host will not reappear on the network map until you restart network discovery on all managed devices configured to perform discovery.

Last Event Received

The date and time that the most recent discovery event occurred.

Last Connection Received

The date and time that the most recent connection was completed.

Event Breakdown

License: FireSIGHT

The Event Breakdown section lists a count of each type of network discovery and host input event that occurred within the last hour, as well as a count of the total number of each event type stored in the database. For full descriptions of each event type, see Understanding Discovery Event Types and Understanding Host Input Event Types.

You can also use the Event Breakdown section to view details on discovery and host input events.

To view network discovery and host input events by type:

Access: Admin/Any Security Analyst

Step 1 Click the type of event you want to view.

The first page of the default discovery events workflow appears, constrained by the event type you picked. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

For information on working with discovery events, see Working with Discovery and Host Input Events.

Protocol Breakdown

License: FireSIGHT

The Protocol Breakdown section lists the protocols currently in use by detected hosts. It displays each detected protocol name, its “layer” in the protocol stack, and the total number of hosts that communicate using the protocol.

Application Protocol Breakdown

License: FireSIGHT

The Application Protocol Breakdown section lists the application protocols that are currently in use by detected hosts. It lists the protocol name, the total number of hosts running the application protocol in the past hour, and the total number of hosts that have been detected running the protocol at any point.

You can also use the Application Protocol Breakdown section to view details on servers using the detected protocols.

To view servers that use a listed application protocol:

Access: Admin/Any Security Analyst

Step 1 Click the name of the application protocol you want to view.

The first page of the default servers workflow appears, constrained by the application protocol you picked. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

For information on working with servers, see Working with Servers.

OS Breakdown

License: FireSIGHT

The OS Breakdown section lists the operating systems currently running on the monitored network, along with their vendors and the total number of hosts running each operating system.

A value of unknown for the operating system name or version means that the operating system or its version does not match any of the system’s fingerprints. A value of pending means that the system has not yet gathered enough information to identify the operating system or its version.

You can use the OS Breakdown section to view details on the detected operating systems.

To view hosts by operating system or vendor:

Access: Admin/Any Security Analyst

Step 1 You have two options:

- To view all hosts running a specific operating system, under OS Name , click the operating system name.

- To view all hosts running any operating system from a specific vendor, under OS Vendor , click the vendor name.

The first page of the default hosts workflow appears, constrained by the operating system or vendor you picked. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

For information on working with hosts, see Working with Hosts.

Viewing Discovery Performance Graphs

License: FireSIGHT

You can generate graphs that display performance statistics for managed devices with discovery events.

Note New data is accumulated for statistics graphs every five minutes. Therefore, if you reload a graph quickly, the data may not change until the next five-minute increment occurs.

Descriptions of the available graph types follow.

Processed Events/Sec

Displays a graph that represents the number of events that the Data Correlator processes per second

Processed Connections/Sec

Displays a graph that represents the number of connections that the Data Correlator processes per second

Generated Events/Sec

Displays a graph that represents the number of events that the system generates per second

Mbits/Sec

Displays a graph that represents the number of megabits of traffic that are analyzed by the discovery process per second

Avg Bytes/Packet

Displays a graph that represents the average number of bytes included in each packet analyzed by the discovery process

K Packets/Sec

Displays a graph that represents the number of packets analyzed by the discovery process per second, in thousands

To generate discovery performance graphs:

Access: Admin/Maint

Step 1 Select Overview > Summary > Discovery Performance.

The Discovery Performance page appears.

Step 2 From the Select Device list, select the Defense Center or managed devices you want to include.

Depending on which appliance you select, the Select Graph(s) list adjusts to display the available graphs.

Step 3 From the Select Graph(s) list, select the type of graph you want to create.

Tip You can select multiple graphs by holding down the Ctrl or Shift keys while clicking on the graph type.

Step 4 From the Select Time Range list, select the time range you would like to use for the graph. You can choose from last hour, last day, last week, or last month.

Step 5 Click Graph to graph the selected statistics.

The selected graph appears.

Understanding Discovery Event Workflows

License: FireSIGHT

The Defense Center provides a set of workflows that you can use to analyze the discovery events that are generated for your network. The workflows are, along with the network map, a key source of information about your network assets. These workflows contain tables that are populated with discovery data generated by the system.

Access network discovery workflows from the Analysis > Hosts menu. The Defense Center provides predefined workflows for discovery events, as well as for detected hosts and their host attributes, servers, applications, application details, vulnerabilities, user activities, and users. You can also create custom workflows. For more information on workflows, see Understanding and Using Workflows.

Tip Select Analysis > Custom > Custom Tables to access workflows based on custom tables.

Working with Indications of Compromise

Understanding User Details and Host History

Table 50-1 Common Discovery Event Actions

To...

You can...

view the host profile for an IP address

) that appears next to the IP address. For information on IOC, see .

view user profile information

) that appears next to the user identity. For more information, see .

sort data

click the column title. Click the column title again to reverse the sort order.

drill down to the next page in the workflow

use one of the following methods:

- To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages. Clicking a value within a row in a table view only constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some events, select the check boxes next to the events you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.
For more information, see Constraining Events.

constrain the columns that appear

. . To add a disabled column back to the view, click the expand arrow to expand the search constraints, then click the column name under Disabled Columns.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

delete items from the system, including:

- discovery and host input events from discovery event workflows

- hosts and network devices from host workflows

- host attributes from host attribute workflows

- servers from server workflows

- applications from application workflows

- third-party vulnerabilities from third-party vulnerability workflows

- users from user workflows

use one of the following methods:

- To delete some items, select the check boxes next to items you want to delete, then click Delete .

- To delete all items in the current constrained view, click Delete All , then confirm you want to delete all the items.

These items remain deleted until the system’s discovery function is restarted, when they may be detected again.

Tip See Purging Discovery Data from the Database for information on deleting all discovery events from the database and also for information on how to restart discovery.
Note that you cannot delete Cisco (as opposed to third-party) vulnerabilities; you can, however, mark them reviewed. For more information, see Working with Vulnerabilities.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

Working with Discovery and Host Input Events

License: FireSIGHT

The system generates discovery events that communicate the details of changes in your monitored network segments. New events are generated for newly discovered network features, and change events are generated for any change in previously identified network assets.

During its initial network discovery phase, the system generates new events for each host and any TCP or UDP servers discovered running on each host. Optionally, you can configure the system to use data exported by NetFlow-enabled devices to generate these new host and server events.

In addition, the system generates new events for each network, transport, and application protocol running on each discovered host. When you create a discovery rule configured to include NetFlow-enabled devices, you can disable detection of application protocols. However, you cannot disable application detection in discovery rules that do not use a configured NetFlow-enabled device. If you enable host or user discovery in non-NetFlow discovery rules, applications are automatically discovered.

After the initial network mapping is complete, the system continuously records network changes by generating change events. Change events are generated whenever the configuration of a previously discovered asset changes.

When a discovery event is generated, it is logged to the database. You can use the Defense Center web interface to view, search, and delete discovery events.You can also use discovery events in correlation rules. Based on the type of discovery event generated as well as other criteria that you specify, you can build correlation rules that, when used in a correlation policy, launch remediations and syslog, SNMP, and email alert responses when network traffic meets your criteria.

You can add data to the network map using the host input feature. You can add, modify, or delete operating system information, which causes the system to stop updating that information for that host. You can also manually add, modify, or delete application protocols, clients, servers, and host attributes or modify vulnerability information. When you do this, the system generates host input events.

See the following sections for more information:

- Understanding Discovery Event Types

- Understanding Host Input Event Types

- Viewing Discovery and Host Input Events

- Understanding the Discovery Events Table

- Searching for Discovery Events

Understanding Discovery Event Types

License: FireSIGHT

There are many types of discovery events. For example, the system generates and logs a New Host event when it detects a new host on your monitored network segment. When you view a table of discovery events, the event type is listed in the Event column. For more information, see Viewing Discovery and Host Input Events.

Contrast discovery events, which are generated when the system detects a change in your monitored network (such as detecting traffic from a previously undetected host), with host input events, which are generated when a user takes a specific action (such as manually adding a host). For more information on host input events, see Understanding Host Input Event Types.

You can configure the types of discovery events the system logs by modifying your network discovery policy. By default, the system logs all types of discovery events. For more information, see Configuring Database Event Limits.

If you understand the information the different types of discovery events provide, you can more effectively determine which events you want to log and alert on, and how to use these alerts in correlation policies. In addition, knowing the names of the event types can help you craft more effective event searches. Descriptions of the different types of discovery events follow.

Additional MAC Detected for Host

This event is generated when the system detects a new MAC address for a previously discovered host.

This event is often generated when the system detects hosts passing traffic through a router. While each host has a different IP address, they all appear to have the MAC address associated with the router. When the system detects the actual MAC address associated with the IP address, it displays the MAC address in bold text within the host profile and displays an “ARP/DHCP detected” message within the event description in the event view.

Client Timeout

This event is generated when the system drops a client from the database due to inactivity.

Client Update

This event is generated when the system detects a payload (that is, a specific type of content, such as audio, video, or webmail) in HTTP traffic.

DHCP: IP Address Changed

This event is generated when the system detects that a host IP address has changed due to DHCP address assignment.

DHCP: IP Address Reassigned

This event is generated when a host is reusing an IP address; that is, when a host obtains an IP address formerly used by another physical host due to DHCP IP address assignment.

Hops Change

This event is generated when the system detects a change in the number of network hops between a host and the device that detects the host.

This may happen if the device sees host traffic through different routers and is able to make a better determination of the host’s location. This may also happen if the device detects an ARP transmission from the host, indicating that the host is on a local segment.

Host Deleted: Host Limit Reached

This event is generated when the host limit on the Defense Center is exceeded and a monitored host is deleted from the Defense Center’s network map.

Host Dropped: Host Limit Reached

This event is generated when the host limit on the Defense Center is reached and a new host is dropped. Compare this with the previous event where old hosts are deleted from the network map when the host limit is reached.

To drop new hosts when the host limit is reached, go to Policies > Network Discovery > Advanced and set When Host Limit Reached to Drop hosts. See Configuring Data Storage for more information.

Host IOC Set

This event is generated when an IOC (Indications of Compromise) is set for a host and generates an alert.

Host Timeout

This event is generated when a host is dropped from the network map because the host has not produced traffic within the interval defined in the network discovery policy. Note that individual host IP addresses and MAC addresses time out individually; a host does not disappear from the network map unless all of its associated addresses have timed out. See Configuring Data Storage for information about configuring the host timeout value.

If you change the networks you want to monitor in your network discovery policy, you may want to manually delete old hosts from the network map so that they do not count against your FireSIGHT license. For more information, see Working with the Hosts Network Map.

Host Type Changed to Network Device

This event is generated when the system detects that a detected host is actually a network device.

Identity Conflict

This event is generated when the system detects a new server or operating system identity that conflicts with a current active identity for that server or operating system.

If you want to resolve identity conflicts by rescanning the host to obtain newer active identity data, you can use Identity Conflict events to trigger an Nmap remediation. For more information, see Configuring Nmap Remediations.

For more information, see Understanding Identity Conflicts and Configuring Identity Conflict Resolution. For information on manually resolving conflicts, see Resolving Operating System Identity Conflicts and Resolving Server Identity Conflicts.

Identity Timeout

This event is generated when identity data that was added to the network map through an active source times out.

If you want to refresh identity data by rescanning the host to obtain newer active identity data, you can use Identity Conflict events to trigger an Nmap remediation. For more information, see Configuring Nmap Remediations.

For more information, see Resolving Server Identity Conflicts.

MAC Information Change

This event is generated when the system detects a change in the information associated with a specific MAC address or TTL value.

This event often occurs when the system detects hosts passing traffic through a router. While each host has a different IP address, they will all appear to have the MAC address associated with the router. When the system detects the actual MAC address associated with the IP address, it displays the MAC address in bold text within the host profile and displays an “ARP/DHCP detected” message within the event description in the event view. The TTL may change because the traffic may pass through different routers or if the system detects the actual MAC address of the host.

NETBIOS Name Change

This event is generated when the system detects a change to a host’s NetBIOS name. This event will only be generated for hosts using the NetBIOS protocol.

New Client

This event is generated when the system detects a new client.

Note To collect and store client data for analysis, make sure that you enable application detection in your discovery rules in the network discovery policy. For more information, see Understanding Application Detection.

New Host

This event is generated when the system detects a new host running on the network.

If you select the Discover option and select Hosts in a network discovery rule where a NetFlow device is selected, this event is also generated when a device processes NetFlow data that involves a new host.

New Network Protocol

This event is generated when the system detects that a host is communicating with a new network protocol (IP, ARP, and so on).

New OS

This event is generated when the system either detects a new operating system for a host, or a change in a host’s operating system.

New TCP Port

This event is generated when the system detects a new TCP server port (for example, a port used by SMTP or web services) active on a host. Note that this event is not used to identify the application protocol or the server associated with it; that information is transmitted in the TCP Server Information Update event.

If you select the Discover option and select Applications in a network discovery rule for NetFlow data, this event is also generated when a device processes NetFlow data involving a server on your monitored networks that does not already exist in the network map.

New Transport Protocol

This event is generated when the system detects that a host is communicating with a new transport protocol, such as TCP or UDP.

New UDP Port

This event is generated when the system detects a new UDP server port running on a host.

If you select the Discover option and select Applications in a network discovery rule for NetFlow data, this event is also generated when a device processes NetFlow data involving a server on your monitored networks that does not already exist in the network map.

TCP Port Closed

This event is generated when the system detects that a TCP port has closed on a host.

TCP Port Timeout

This event is generated when the system has not detected activity from a TCP port within the interval defined in the system’s network discovery policy. See Configuring Data Storage for information about configuring the server timeout value.

TCP Server Information Update

This event is generated when the system detects a change in a discovered TCP server running on a host.

This event may be generated if a TCP server is upgraded.

UDP Port Closed

This event is generated when the system detects that a UDP port has closed on a host.

UDP Port Timeout

This event is generated when the system has not detected activity from a UDP port within the interval defined in the network discovery policy. See Configuring Data Storage for information about configuring the server timeout value.

UDP Server Information Update

This event is generated when the system detects a change in a discovered UDP server running on a host.

This event may be generated if a UDP server is upgraded.

VLAN Tag Information Update

This event is generated when the system detects a change in the VLAN tag attributed to a host. For more information about VLAN tags, see Working with VLAN Tags in the Host Profile.

Understanding Host Input Event Types

License: FireSIGHT

There are many types of host input events. For example, the system generates and logs an Add Host event when a user adds a host using the host import feature. When you view a table of discovery events, the event type is listed in the Event column. For more information, see Viewing Discovery and Host Input Events.

Contrast host input events, which are generated when a user takes a specific action (such as manually adding a host), with discovery events, which are generated when the system itself detects a change in your monitored network (such as detecting traffic from a previously undetected host). For more information on host input events, see Understanding Discovery Event Types.

You can configure the types of host input events that the system logs by modifying your network discovery policy. By default, the system logs all types of host input events. For more information, see Configuring Database Event Limits.

If you understand the information the different types of host input events provide, you can more effectively determine which events you want to log and alert on, and how to use these alerts in correlation policies. In addition, knowing the names of the event types can help you craft more effective event searches. Descriptions of the different types of host input events follow.

Add Client

This event is generated when a user adds a client.

Add Host

This event is generated when a user adds a host.

Add Protocol

This event is generated when a user adds a protocol.

Add Scan Result

This event is generated when the system adds the results of an Nmap scan to a host.

Add Port

This event is generated when a user adds a server port.

Delete Client

This event is generated when a user deletes a client from the system.

Delete Host/Network

This event is generated when a user deletes an IP address or subnet from the system.

Delete Protocol

This event is generated when a user deletes a protocol from the system.

Delete Port

This event is generated when a user deletes a server port or group of server ports from the system.

Host Attribute Add

This event is generated when a user creates a new host attribute.

Host Attribute Delete

This event is generated when a user deletes a user-defined host attribute.

Host Attribute Delete Value

This event is generated when a user deletes a value assigned to a host attribute.

Host Attribute Set Value

This event is generated when a user sets a host attribute value for a host.

Host Attribute Update

This event is generated when a user changes the definition of a user-defined host attribute.

Set Host Criticality

This event is generated when a user sets or modifies the host criticality value for a host.

Set Operating System Definition

This event is generated when a user sets the operating system for a host.

Set Server Definition

This event is generated when a user sets the vendor and version definitions for a server.

Set Vulnerability Impact Qualification

This event is generated when a vulnerability impact qualification is set.

When a vulnerability is disabled at a global level from being used for impact qualifications, or when a vulnerability is enabled at a global level, this event is generated.

Vulnerability Set Invalid

This event is generated when a user invalidates (or reviews) a vulnerability or vulnerabilities.

Vulnerability Set Valid

This event is generated when a user validates a vulnerability that was previously marked as invalid.

Viewing Discovery and Host Input Events

License: FireSIGHT

Both discovery events and host input events can be viewed using Discovery Events workflows. Discovery events record the detection of network discovery data based on the configured network discovery policy for an appliance. Host input events record the input of host data into the network map through the host input feature. For more information, see Understanding Discovery Event Types and Understanding Host Input Event Types.

You can use the Defense Center to view a table of discovery or host input events. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of discovery events and a terminating host view page. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The Discovery Event Actions table below describes some of the specific actions you can perform on a discovery events workflow page. You can also perform the tasks described in the Common Discovery Event Actions table.

Table 50-2 Discovery Event Actions

To...

You can...

modify the time and date range for displayed events

find more information in Setting Event Time Constraints.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

learn more about the contents of the columns in the table

find more information in Understanding the Discovery Events Table.

To view discovery events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Discovery Events.

The first page of the default discovery events workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Understanding the Discovery Events Table

License: FireSIGHT

The system generates discovery events that communicate the details of changes in your monitored network segments. New events are generated for newly discovered network features, and change events are generated for any change in previously identified network assets.

During its initial network discovery phase, the system generates new events for each host and any TCP or UDP servers it discovers on each host. In addition, the system generates new events for each network, transport, or application protocol running on each discovered host. For NetFlow-related traffic, you can control whether the system generates new events when it detects application protocols running on a host. After the initial network mapping is complete, the system continuously records network changes by generating change events. Change events are generated whenever the configuration of a previously discovered host, server, or client changes.

Descriptions of the fields in the discovery events table follow.

Time

The time that the system generated the event.

Event

The event type. See Understanding Discovery Event Types and Understanding Host Input Event Types for a description of each available event.

IP Address

The IP address associated with the host involved in the event.

User

The last user to log into the host involved in the event before the event was generated. If only non-authoritative users log in after an authoritative user, the authoritative user remains the current user for the host unless another authoritative user logs in.

MAC Address

The MAC address of the NIC used by the network traffic that triggered the discovery event. This MAC address can be either the actual MAC address of the host involved in the event, or the MAC address of a network device that the traffic passed through.

MAC Vendor

The MAC hardware vendor of the NIC used by the network traffic that triggered the discovery event.

Port

The port used by the traffic that triggered the event, if applicable.

Description

The text description of the event.

Device

The name of the device that generated the event. For new host and new server events based on NetFlow data, this is the device that processed the NetFlow data.

Searching for Discovery Events

License: FireSIGHT

You can search for specific discovery events. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for Discovery Events

Table 50-3 Discovery Event Search Criteria Notes

Field

Search Criteria Notes

Event

The range of event names is listed in Understanding Discovery Event Types and Understanding Host Input Event Types

MAC Vendor

To search for virtual MAC vendors, that is, for events that involve virtual machines, type virtual_mac_vendor.

To search for a vendor whose name includes a comma, enclose the entire search term in quotes. Otherwise, the Defense Center treats the term as two searches and returns events that match each search term.

Port

Note that you cannot:

- enter a port/protocol combination as you can when searching for other kinds of events

- use spaces when specifying port numbers or ranges.

To search for discovery events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Discovery Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in General Search Syntax and Special Search Syntax for Discovery Events.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default discovery events workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Hosts

License: FireSIGHT

The system generates an event when it detects a host and collects information about it to build the host profile. You can use the Defense Center web interface to view, search, and delete hosts.

While viewing hosts, you can create traffic profiles and compliance white lists based on selected hosts. You can also assign host attributes, including host criticality values (which designate business criticality) to groups of hosts. You can then use these criticality values, white lists, and traffic profiles within correlation rules and policies.

Although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.

For more information, see the following sections:

- Viewing Hosts

- Understanding the Hosts Table

- Creating a Traffic Profile for Selected Hosts

- Creating a Compliance White List Based on Selected Hosts

- Searching for Hosts

- Setting Host Attributes for Selected Hosts

Viewing Hosts

License: FireSIGHT

You can use the Defense Center to view a table of hosts that the system has detected. Then, you can manipulate the view depending on the information you are looking for.

The page you see when you access hosts differs depending on the workflow you use. Both predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

Table 50-4 Host Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Hosts Table.

assign a host attribute to selected hosts

find more information in Setting Host Attributes for Selected Hosts.

create traffic profiles for selected hosts

find more information in Creating a Traffic Profile for Selected Hosts.

create a compliance white list based on selected hosts

find more information in Creating a Compliance White List Based on Selected Hosts.

To view hosts:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Hosts.

The first page of the default hosts workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of hosts, click (switch workflow), then select Hosts.

Understanding the Hosts Table

License: FireSIGHT

When the system discovers a host, it collects data about that host. That data can include the host’s IP addresses, the operating system it is running, and more. You can view some of that information in the table view of hosts. For more information on the data that the system collects about detected hosts, see Using Host Profiles.

Descriptions of the fields in the hosts table follow below.

Although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.

Last Seen

The date and time any of the host’s IP addresses was last detected by the system. The Last Seen value is updated at least as often as the update interval you configured in the network discovery policy, as well as when the system generates a new host event for any of the host’s IP addresses.

For hosts with operating system data updated using the host input feature, the Last Seen value indicates the date and time when the data was originally added.

IP Address

The IP addresses associated with the host.

MAC Address

The host’s detected MAC address of the NIC.

The MAC Address field appears in the Table View of Hosts, which you can find in the Hosts workflow. You can also add the MAC Address field to:

– custom tables that include fields from the Hosts table

– drill-down pages in custom workflows based on the Hosts table

MAC Vendor

The host’s detected MAC hardware vendor of the NIC.

The MAC Vendor field appears in the Table View of Hosts, which you can find in the Hosts workflow. You can also add the MAC Vendor field to:

– custom tables that include fields from the Hosts table

– drill-down pages in custom workflows based on the Hosts table

Current User

The user identity (username) of the currently logged in user on the host.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Host Criticality

The user-specified criticality value assigned to the host. See the description of the Host Criticality column in Understanding the Host Attributes Table for more information about this field.

NetBIOS Name

The NetBIOS name of the host. Only hosts running the NetBIOS protocol will have a NetBIOS name.

VLAN ID

VLAN ID used by the host. For more detailed information about VLAN IDs, see Working with VLAN Tags in the Host Profile.

Hops

The number of network hops from the device that detected the host to the host.

Host Type

The type of host (host, mobile device, jailbroken mobile device, router, bridge, NAT device, or load balancer). The methods the system uses to distinguish network devices include:

– the analysis of Cisco Discovery Protocol (CDP) messages, which can identify network devices and their type (Cisco devices only)

– the detection of the Spanning Tree Protocol (STP), which identifies a device as a switch or bridge

– the detection of multiple hosts using the same MAC address, which identifies the MAC address as belonging to a router

– the detection of TTL value changes from the client side, or TTL values that change more frequently than a typical boot time, which identify NAT devices and load balancers

If a device is not identified as a network device, it is categorized as a host.

Hardware

The hardware platform for a mobile device.

OS

The detected operating system (name, vendor, and version) running on the host, or updated using Nmap or the host input feature. This field appears when you invoke the hosts event view from the Custom Analysis widget on the dashboard. It is also a field option in custom tables based on the Hosts table.

Note if the system detects multiple identities, it displays those identities in a comma-separated list.

In this field, a value of unknown means that the operating system does not match any of the known fingerprints. A value of pending means that the system has not yet gathered enough information to identify the operating system.

OS Vendor

The vendor of the operating system detected on the host or updated using Nmap or the host input feature.

Note if the system detects multiple vendors, it displays those vendors in a comma-separated list.

In this field, a value of unknown means that the operating system does not match any of the known fingerprints. A value of pending means that the system has not yet gathered enough information to identify the operating system.

OS Name

The detected operating system running on the host or updated using Nmap or the host input feature.

Note if the system detects multiple names, it displays those names in a comma-separated list.

In this field, a value of unknown means that the operating system does not match any of the known fingerprints. A value of pending means that the system has not yet gathered enough information to identify the operating system.

OS Version

The version of the operating system detected on the host or updated using Nmap or the host input feature.

Note if the system detects multiple versions, it displays those versions in a comma-separated list.

In this field, a value of unknown means that the operating system does not match any of the known fingerprints. A value of pending means that the system has not yet gathered enough information to identify the operating system.

Source Type

One of the following values for the source of the host’s operating system identity:

– User: user_name

– Application: app_name

– Scanner: scanner_type (Nmap or scanner added through network discovery configuration)

– FireSIGHT, for operating systems detected by the system

The system may reconcile data from multiple sources to determine the identity of an operating system; see Understanding Current Identities.

Confidence

One of:

– the percentage of confidence that the system has in the identity of the operating system running on the host, for hosts detected by the system

– 100%, for operating systems identified by an active source, such as the host input feature or Nmap scanner

– unknown, for hosts for which the system cannot determine an operating system identity, and for hosts added to the network map based on NetFlow data

Notes

The user-defined content of the Notes host attribute.

Device

Either the managed device that detected the traffic or the device that processed the NetFlow or host input data that added the host to the network map.

If this field is blank, either the host was added to the network map by a device that is not explicitly monitoring the network where the host resides, as defined in the network discovery policy, or the host was added using the host input feature and has not also been detected by the system.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Creating a Traffic Profile for Selected Hosts

License: FireSIGHT

A traffic profile is a profile of the traffic on your network, based on connection data collected over a timespan that you specify. After you create a traffic profile, you can detect abnormal network traffic by evaluating new traffic against your profile, which presumably represents normal network traffic.

You can use the Hosts page to create a traffic profile for a group of hosts that you specify. The traffic profile will be based on connections detected where one of the hosts you specify is the initiating host. Use the sort and search features to isolate the hosts for which you want to create a profile.

To create a traffic profile for selected hosts:

Access: Admin

Step 1 On a table view in the hosts workflow, select the check boxes next to the hosts for which you want to create a traffic profile.

Step 2 At the bottom of the page, click Create Traffic Profile.

The Create Profile page appears, populated with the IP addresses of the hosts you specified as the hosts to be monitored.

Step 3 Modify and save the traffic profile according to your specific needs.

For more information on creating traffic profiles, see Creating Traffic Profiles.

Creating a Compliance White List Based on Selected Hosts

License: FireSIGHT

Compliance white lists allow you to specify which operating systems, clients, and network, transport, or application protocols are allowed on your network.

You can use the Hosts page to create a compliance white list based on the host profiles of a group of hosts that you specify. Use the sort and search features to isolate the hosts that you want to use to create a white list.

To create a compliance white list based on selected hosts:

Access: Admin

Step 1 On a table view in the hosts workflow, select the check boxes next to the hosts for which you want to create a white list.

Step 2 At the bottom of the page, click Create White List.

The Create White List page appears, populated with the information in the host profiles of the hosts you specified.

Step 3 Modify and save the white list according to your specific needs.

For more information on creating compliance white lists, see Creating Compliance White Lists.

Searching for Hosts

License: FireSIGHT

You can search for specific hosts by using one of the predefined searches or by using your own search criteria.

When searching for hosts, you should keep in mind that although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. For more information, see Differences Between NetFlow and FireSIGHT Data.

You can search for specific discovery events. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IP addresses in the FireSIGHT System, see IP Address Conventions.

Note When you search for hosts by IP address, the results include all hosts for which at least one IP address matches your search conditions, that is, a search for an IPv6 address may return hosts whose primary address is IPv4.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Special Search Syntax for Hosts

Table 50-5 Host Search Criteria

Field

Search Criteria Notes

Host Type

To search for all network devices, type !host.

MAC Vendor

To search for virtual MAC vendors, that is, for events that involve virtual machines, type virtual_mac_vendor.

To search for a vendor whose name includes a comma, enclose the entire search term in quotes. Otherwise, the Defense Center treats the term as two searches and returns events that match each search term.

OS Vendor/Name/Version

Type unknown to search for hosts where the operating system is unknown. Type n/a to search for hosts where the operating system has not yet been identified.

Confidence

You can precede the confidence with greater than (>), greater than or equal to (>=), less than (<), less than or equal to (<=), or equal to (=) operators.

Matches to an n/a search include hosts added to the network map based on NetFlow data.

OS Conflict

Note that the OS Conflict column does not appear in search results. To determine whether you are viewing hosts with or without operating system conflicts, expand the search constraints on the workflow page. For more information on resolving operating system conflicts, see Resolving Operating System Identity Conflicts.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

To search for hosts:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Hosts from the table drop-down menu.

The page updates with the appropriate constraints.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields, as described in the Host Search Criteria table.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default hosts workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Host Attributes

License: FireSIGHT

The FireSIGHT System collects information about the hosts it detects and uses that information to build host profiles. However, there may be additional information about the hosts on your network that you want to provide to your analysts. You can add notes to a host profile, set the business criticality of a host, or provide any other information that you choose. Each piece of information is called a host attribute.

You can use host attributes in host profile qualifications, which constrain the data you collect while building a traffic profile, and also can limit the conditions under which you want to trigger a correlation rule. You can also set attribute values in response to a correlation rule.

For more information, see:

- Viewing Host Attributes

- Understanding the Host Attributes Table

- Setting Host Attributes for Selected Hosts

- Searching for Host Attributes

- Configuring Set Attribute Remediations

Viewing Host Attributes

License: FireSIGHT

You can use the Defense Center to view a table of hosts detected by the system, along with their host attributes. Then, you can manipulate the view depending on the information you are looking for.

The page you see when you access host attributes differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of host attributes that lists all detected hosts and their attributes, and terminates in a host view page, which contains a host profile for every host that meets your constraints.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

Table 50-6 Host Attribute Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Host Attributes Table.

assign a host attribute to selected hosts

find more information in Setting Host Attributes for Selected Hosts

To view host attributes:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Host Attributes.

The first page of the default host attributes workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of host attributes, click (switch workflow), then select Attributes.

Understanding the Host Attributes Table

License: FireSIGHT

The FireSIGHT System collects information about the hosts it detects and uses that information to build host profiles. However, there may be additional information about the hosts on your network that you want to provide to your analysts. You can add notes to a host profile, set the business criticality, or provide any other information that you choose. Each piece of information is called a host attribute.

You can use host attributes in host profile qualifications, which constrain the data you collect while building a traffic profile, and also can limit the conditions under which you want to trigger a correlation rule.

Note that the host attributes table does not display hosts identified only by MAC addresses.

For more information on host attributes, see Working with the Predefined Host Attributes and Working with User-Defined Host Attributes.

Descriptions of the fields in the host attributes table follow.

IP Address

The IP addresses associated with a host.

Current User

The user identity (username) of the currently logged in user on the host.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Host Criticality

The user-assigned importance of a host to your enterprise. You can use the host criticality in correlation rules and policies to tailor policy violations and their responses to the importance of a host involved in an event. You can assign a host criticality of low, medium, high, or none.

For information on setting a host’s criticality, see Working with the Predefined Host Attributes and Setting Host Attributes for Selected Hosts.

Notes

Information about the host that you want other analysts to view. For information on how to add a note, see Working with the Predefined Host Attributes.

Any user-defined host attribute, including those for compliance white lists

The value of the user-defined host attribute.

The host attributes table contains a field for each user-defined host attribute. For more information, see Working with User-Defined Host Attributes.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Setting Host Attributes for Selected Hosts

License: FireSIGHT

There are two predefined host attributes that you can assign to each host: host criticality and host-specific notes.

Use the host criticality to designate the business criticality of a given host. You can tailor correlation policies and alerts based on host criticality. For example, your organization’s mail servers are more critical to your business than a typical user workstation. You can assign a high host criticality value to your mail servers and other business-critical servers and medium or low values to other hosts. You could then create a correlation policy that launches different alerts based on the criticality of an affected host.

Use notes to record information about a host that you want other analysts to view. For example, if you have a computer on the network that has an older, unpatched version of an operating system that you use for testing, you can use the notes feature to indicate that the system is intentionally unpatched.

You can also create user-defined host attributes. For example, you could create a host attribute that assigns physical location identifiers to hosts, such as a facility code, city, or room number. For more information on created user-defined host attributes, see Creating User-Defined Host Attributes.

You can also set the host criticality of selected hosts in a host workflow, and from within a host profile, or set it through a remediation. For more information, see Working with the Predefined Host Attributes or Configuring Set Attribute Remediations.

To set host attributes for selected hosts:

Access: Admin/Any Security Analyst

Step 1 Select the check boxes next to the hosts to which you want to add a host attribute.

Tip Use the sort and search features to isolate the hosts to which you want to assign particular attributes.

Step 2 At the bottom of the page, click Set Attributes.

The Host Attributes pop-up window appears.

Step 3 Optionally, set the host criticality for the hosts you selected.

You can select None, Low, Medium, or High.

Step 4 Optionally, add notes to the host profiles of the hosts you selected by entering up to 255 alphanumeric characters, special characters, and spaces in the text box.

Step 5 Optionally, set any user-defined host attributes you have configured.

Step 6 Click Save.

The host attributes you specified are assigned to the selected hosts.

Searching for Host Attributes

License: FireSIGHT

You can search for hosts that have specific host attributes. For example, if your company has several regional offices, you could configure a host attribute that tells you which city any one host resides in. You could then search for hosts in specific regions. For more information on host attributes, see Working with User-Defined Host Attributes.

You may want to create searches customized for your network environment, then save them to reuse later. For more information on the host attribute fields, see Understanding the Host Attributes Table.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for host attributes:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 From the table drop-down list, select Host Attributes.

The page updates with the appropriate constraints.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields, as described in Understanding the Host Attributes Table.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default host attributes workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Indications of Compromise

License: FireSIGHT

); you also can write compliance rules that account for IOC-tagged hosts.

To use this feature, you must have IOC rules enabled in your network discovery policy. You can enable any or all of the predefined rules to trigger IOC tags on compromised hosts. For more information, see Setting Indications of Compromise Rules.

See the following sections for detailed information about indications of compromise:

- Viewing Indications of Compromise

- Understanding the Indications of Compromise Table

- Searching for Indications of Compromise

Viewing Indications of Compromise

License: FireSIGHT

You can use the Defense Center to view a table of triggered Indications of Compromise (IOC). Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access IOC depends on the workflow you use. Both predefined IOC workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on an IOC workflow page. You can also perform the tasks described in the Common Discovery Event Actions table.

Table 50-7 Indication of Compromise Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Indications of Compromise Table.

view the host profile for a compromised host

column.

mark selected IOC events resolved so they no longer appear in the list

select the check boxes next to the IOC events you want to edit, then click Mark Resolved. For more information, see Resolving Indications of Compromise.

view details of events that triggered the IOC

columns.

To view indications of compromise:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Indications of Compromise.

The first page of the default indications of compromise (IOC) workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the IOC table view, click (switch workflow), then select Indications of Compromise.

Understanding the Indications of Compromise Table

License: FireSIGHT

The FireSIGHT System correlates various types of event data associated with hosts to determine whether a host on your monitored network is likely to be compromised by malicious means. These correlations appear, associated with the host, as indications of compromise (IOC). You can mark a host IOC as resolved, which removes that IOC tag from the host. A host can trigger multiple IOC tags; you can view all IOC tags associated with a host in the Indications of Compromise section of the host profile. For more information on IOC data in the host profile, see Working with Indications of Compromise in the Host Profile.

Descriptions of the fields in the IOC table follow below.

IP Address

The IP address associated with the host that triggered the IOC.

Category

Brief description of the type of compromise indicated, such as Malware Executed or Impact 1 Attack.

Event Type

Identifier associated with a specific Indication of Compromise (IOC), referring to the event that triggered it.

Description

Description of what the IOC means for the potentially compromised host, such as This host may be under remote control or Malware has been executed on this host.

First/Last Seen

The first (or most recent) date and time that events triggering a host’s IOC occurred.

Searching for Indications of Compromise

License: FireSIGHT

You can search for specific indications of compromise (IOC) tags triggered on monitored hosts by using one of the predefined searches or by using your own search criteria. The predefined searches serve as examples and can provide quick access to important information about your network.

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. The fields you can use to retrieve data are described in Understanding the Indications of Compromise Table.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for indications of compromise:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Indications of Compromise from the table drop-down list.

The page updates with the appropriate constraints.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields, as described in Understanding the Indications of Compromise Table.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default IOC workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Servers

License: FireSIGHT

The FireSIGHT System collects information about all servers running on hosts on monitored network segments. The information that the system collects includes the name of the server, the application and network protocols used by the server, the vendor and version of the server, the IP address associated with the host running a server, and the port on which the server communicates.

When the system detects a server, it generates a discovery event unless the associated host has already reached its maximum number of servers. For more information, see Host Limits and Discovery Event Logging. You can use the Defense Center web interface to view, search, and delete server events.

You can also base correlation rules on server events. For example, you could trigger a correlation rule when the system detects a chat server, such as ircd, running on one of your hosts.

Although you can configure the network discovery policy to add servers to the network map based on application data exported by NetFlow-enabled devices, the available information about these servers is limited. For more information, see Differences Between NetFlow and FireSIGHT Data.

See the following sections for more information:

- Viewing Servers

- Understanding the Servers Table

- Searching for Servers

- Editing Server Identities

Viewing Servers

License: FireSIGHT

You can use the Defense Center to view a table of detected servers. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access servers differs depending on the workflow you use. All the predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

The Server Actions table below describes some of the specific actions you can perform on an servers workflow page. You can also perform the tasks described in the Common Discovery Event Actions table.

Table 50-8 Server Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Servers Table.

edit server identities

select the check boxes next to the events for servers you want to edit, then click Set Server Identity. For more information, see Editing Server Identities.

To view servers:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Servers.

The first page of the default servers workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of servers, click (switch workflow), then select Servers.

Understanding the Servers Table

License: FireSIGHT

The FireSIGHT System collects information about servers running on hosts on monitored network segments.

Descriptions of the fields in the servers table follow below.

Although you can configure the network discovery policy to add servers to the network map based on data exported by NetFlow-enabled devices, the available information about these servers is limited. For more information, see Differences Between NetFlow and FireSIGHT Data.

Last Used

The date and time the server was last used on the network or the date and time that the server was originally updated using the host input feature. The Last Used value is updated at least as often as the update interval you configured in the network discovery policy, as well as when the system detects a server information update. For information on setting the update interval, see Configuring Data Storage.

IP Address

The IP address associated with the host running the server.

Port

The port where the server is running.

Protocol

The network or transport protocol used by the server.

Application Protocol

The application protocol, as indicated by one of the following:

– the name of the application protocol for the server

– pending, if the system cannot positively or negatively identify the server for one of several reasons

– unknown, if the system cannot identify the server based on known server fingerprints or if the server was added through host input and did not include the application protocol

Category, Tags, Risk, or Business Relevance for Application Protocols

The categories, tags, risk level, and business relevance assigned to the application protocol. These filters can be used to focus on a specific set of data. For more information, see Table 45-2.

Vendor

One of:

– the server vendor as identified by the system, Nmap or another active source, or that you specified using the host input feature

– blank, if the system cannot identify its vendor based on known server fingerprints, or if the server was added to the network map using NetFlow data

Version

One of:

– the server version as identified by the system, Nmap or another active source, or that you specified using the host input feature

– blank, if the system cannot identify its version based on known server fingerprints, or if the server was added to the network map using NetFlow data

Web Application

The web application based on the payload content detected by the system in the http traffic. Note that if the system detects an application protocol of HTTP but cannot detect a specific web application, the system supplies a generic web browsing designation.

Category, Tags, Risk, or Business Relevance for Web Applications

The categories, tags, risk level, and business relevance assigned to the web application. These filters can be used to focus on a specific set of data. For more information, see Table 45-2.

Hits

The number of times the server was accessed. For servers added using the host input feature, this value is always 0.

Source Type

One of the following values:

– User: user_name

– Application: app_name

– Scanner: scanner_type (Nmap or scanner added through network discovery configuration)

– FireSIGHT, FireSIGHT Port Match, or FireSIGHT Pattern Match, for servers detected by the FireSIGHT System

– NetFlow, for servers added to the network map based on NetFlow data

The system may reconcile data from multiple sources to determine the identity of a server; see Understanding Current Identities.

Device

The name of the device that either detected the server or processed the NetFlow or host input data that added the server to the network map.

Current User

The user identity (username) of the currently logged in user on the host.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for Servers

License: FireSIGHT

You can search for specific servers that are running on monitored hosts by using one of the predefined searches or by using your own search criteria. The predefined searches serve as examples and can provide quick access to important information about your network.

You may want to modify specific fields within the default searches to customize them for your network environment, then save them to reuse later. The fields you can use to retrieve data are described in Understanding the Servers Table.

When searching for servers, you should keep in mind that although you can configure the network discovery policy to add applications, including servers, to the network map based on data exported by NetFlow-enabled devices, the available information about these servers is limited. For more information, see Differences Between NetFlow and FireSIGHT Data.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for servers:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 From the table drop-down list, select Servers.

The page updates with the appropriate constraints.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default servers workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Applications

License: FireSIGHT

When a monitored host connects to another host, the system can, in many cases, determine what application was used. The FireSIGHT System detects the use of many email, instant messaging, peer to peer, web applications, as well as other types of applications.

For each detected application, the system logs the IP address that used the application, the product, the version, and the number of times its use was detected. You can use the web interface to view, search, and delete application events. You can also update application data on a host or hosts using the host input feature.

If you know which applications are running on which hosts, you can use that knowledge to create host profile qualifications, which constrain the data you collect while building a traffic profile, and also can limit the conditions under which you want to trigger a correlation rule. You can also base correlation rules on the detection of application. For example, if you want your employees to use a specific mail client, you could trigger a correlation rule when the system detects a different mail client running on one of your hosts.

You should carefully read the release notes for each FireSIGHT System update as well as the advisories for each VDB update for information on updated detectors.

To collect and store application data for analysis, make sure that you enable application detection in your network discovery policy. For more information, see Understanding Discovery Data Collection.

See the following sections for more information:

- Viewing Application Details

- Understanding the Application Detail Table

- Searching for Application Details

Viewing Applications

License: FireSIGHT

You can use the Defense Center to view a table of detected applications. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access applications differs depending on the workflow you use. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

Table 50-9 Application Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Applications Table.

open the Application Detail View for a specific application

) next to a client, application protocol, or web application.

To view applications:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Application Details.

The first page of the default application details workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of application details, click (switch workflow), then select Clients.

Understanding the Applications Table

License: FireSIGHT

When a monitored host connects to another host, the FireSIGHT System can, in many cases, determine what application was used. The system detects various web browsers or servers, email clients or servers, instant messengers, peer-to-peer applications, and so on. When the system detects traffic for a known client, application protocol, or web application, it logs information about the application and the host running it.

The FireSIGHT System classifies application data into three types: client, web application, and application protocol. The applications table provides a list combining all three types of detected applications on the appliance.

Descriptions of the fields in the applications table follow.

Application

The name of the detected application.

IP Address

The IP address associated with the host using the application.

Category

A general classification for the application that describes its most essential function. Each application belongs to at least one category.

Tag

Additional information about the application. Applications can have any number of tags, including none.

Risk

How likely the application is to be used for purposes that might be against your organization’s security policy. An application’s risk can range from Very Low to Very High.

Of Application Protocol Risk, Client Risk, and Web Application Risk, the highest of the three detected, when available, in the traffic that triggered the intrusion event.

Business Relevance

The likelihood that the application is used within the context of your organization’s business operations, as opposed to recreationally. An application’s business relevance can range from Very Low to Very High.

Of Application Protocol Business Relevance, Client Business Relevance, and Web Application Business Relevance, the lowest of the three detected, when available, in the traffic that triggered the intrusion event.

Current User

The user identity (username) of the currently logged in user on the host.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Type

The type of application:

– Application Protocols represent communications between hosts.

– Client Applications represent software running on a host.

– Web Applications represent the content or requested URL for HTTP traffic.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for Applications

License: FireSIGHT

You can search for hosts that are running specific clients, application protocols, or web applications. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for applications:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Applications from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default clients workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Application Details

License: FireSIGHT

When a monitored host connects to another host, the system can, in many cases, determine what application was used. The FireSIGHT System detects the use of many email, instant messaging, peer to peer, web applications, as well as other types of applications.

For each detected application, the system logs the IP address that used the application, the product, the version, and the number of times its use was detected. You can use the web interface to view, search, and delete application events. You can also update application data on a host or hosts using the host input feature.

If you know which applications are running on which hosts, you can use that knowledge to create host profile qualifications, which constrain the data you collect while building a traffic profile, and also can limit the conditions under which you want to trigger a correlation rule. You can also base correlation rules on the detection of application. For example, if you want your employees to use a specific mail client, you could trigger a correlation rule when the system detects a different mail client running on one of your hosts.

You should carefully read the release notes for each FireSIGHT System update as well as the advisories for each VDB update for information on updated detectors.

To collect and store application data for analysis, make sure that you enable application detection in your network discovery policy. For more information, see Understanding Application Detection.

See the following sections for more information:

- Viewing Application Details

- Understanding the Application Detail Table

- Searching for Application Details

Viewing Application Details

License: FireSIGHT

You can use the Defense Center to view a table of detected application details. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access application details differs depending on the workflow you use. There are two predefined workflows. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

Table 50-10 Application Details Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Application Detail Table.

open the Application Detail View for a specific application

) next to a client.

To view application details:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Hosts > Application Details.

The first page of the default application details workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of application details, click (switch workflow), then select Clients.

Understanding the Application Detail Table

License: FireSIGHT

When a monitored host connects to another host, the FireSIGHT System can, in many cases, determine what application was used. The system detects various web browsers, email clients, instant messengers, peer-to-peer applications, and so on.

When the system detects traffic for a known client, application protocol, or web application, it logs information about the application and the host running it. Descriptions of the fields in the application details table follow.

Last Used

The time that the application was last used or the time that the application data was updated using the host input feature. The Last Used value is updated at least as often as the update interval you configured in the network discovery policy, as well as when the system detects an application information update. For information on setting the update interval, see Configuring Data Storage.

IP Address

The IP address associated with the host using the application.

Client

The name of the application. Note that if the system detected an application protocol but could not detect a specific client, client is appended to the application protocol name to provide a generic name.

Version

The version of the application.

Category, Tags, Risk, or Business Relevance for Clients, Application Protocols, and Web Applications

The categories, tags, risk level, and business relevance assigned to the application. These filters can be used to focus on a specific set of data. For more information, see Table 45-2.

Application Protocol

The application protocol used by the application. Note that if the system detected an application protocol but could not detect a specific client, client is appended to the application protocol name to provide a generic name.

Web Application

The web application based on the payload content or URL detected by the system in the http traffic. Note that if the system detects an application protocol of HTTP but cannot detect a specific web application, the system supplies a generic web browsing designation here.

Hits

The number of times the system detected the application in use. For applications added using the host input feature, this value is always 0.

Device

The device that generated the discovery event containing the application detail.

Current User

The user identity (username) of the currently logged in user on the host.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for Application Details

License: FireSIGHT

You can search for hosts that are running specific clients, application protocols, or web applications. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for application details:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Application Details from the table drop-down list.

The page updates with the appropriate constraints.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default application details workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Vulnerabilities

License: FireSIGHT

The FireSIGHT System includes its own vulnerability tracking database which is used, in conjunction with the system’s fingerprinting capability, to identify the vulnerabilities associated with the hosts on your network.

The operating systems, servers, and clients running on your hosts have different sets of associated vulnerabilities. You can deactivate vulnerabilities for a host after you patch the host or otherwise judge it immune to a vulnerability. You can use the Defense Center to track and review the vulnerabilities for each host.

Note that vulnerabilities for vendorless and versionless servers are not mapped unless the applications protocols used by the servers are mapped in the system policy. Vulnerabilities for vendorless and versionless clients cannot be mapped. For more information, see Mapping Vulnerabilities for Servers.

For more information, see:

- Viewing Vulnerabilities

- Understanding the Vulnerabilities Table

- Deactivating Vulnerabilities

- Searching for Vulnerabilities

Viewing Vulnerabilities

License: FireSIGHT

You can use the Defense Center to view a table of vulnerabilities. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access vulnerabilities differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of vulnerabilities. The table view contains a row for each vulnerability in the database, regardless of whether any of your detected hosts exhibit the vulnerabilities. The second page of the predefined workflow contains a row for each vulnerability (that you have not deactivated) that applies to detected hosts on your network. The predefined workflow terminates in a vulnerability detail view, which contains a detailed description for every vulnerability that meets your constraints.

Tip If you want to see the vulnerabilities that apply to a single host or set of hosts, perform a search for vulnerabilities, specifying an IP address or range of IP addresses for the hosts. For more information on searching for vulnerabilities, see Searching for Vulnerabilities.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on an vulnerabilities workflow page. You can also perform the tasks described in the Common Discovery Event Actions table.

Viewing Vulnerability Details

Table 50-11 Vulnerability Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Vulnerabilities Table.

view the vulnerability details for a vulnerability

) in the SVID column. Alternatively, constrain on the vulnerability ID and drill down to the vulnerability details page. For more information, see .

deactivate selected vulnerabilities so they are no longer used for intrusion impact correlation for currently vulnerable hosts

find more information in Deactivating Vulnerabilities.

view the full text of a vulnerability title

right-click the title and select Show Full Text.

To view vulnerabilities:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Vulnerabilities > Vulnerabilities.

The first page of the default vulnerabilities workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of vulnerabilities, click (switch workflow), then select Vulnerabilities.

Understanding the Vulnerabilities Table

License: FireSIGHT

The FireSIGHT System includes its own vulnerability tracking database which is used, in conjunction with the system’s fingerprinting capability, to identify the vulnerabilities associated with the hosts on your network.

The operating systems, servers, and clients running on your hosts have different sets of associated vulnerabilities. You can deactivate vulnerabilities for a host after you patch the host or otherwise judge it immune to a vulnerability. You can use the Defense Center to track and review the vulnerabilities for each host.

For more information on vulnerabilities, see Working with the Vulnerabilities Network Map and Working with Vulnerabilities in the Host Profile.

Descriptions of the fields in the vulnerabilities table follow.

SVID

The Cisco vulnerability identification number that the system uses to track vulnerabilities.

) to access the vulnerability details for the SVID. See Viewing Vulnerability Details for more information.

Bugtraq ID

The identification number associated with the vulnerability in the Bugtraq database. (http://www.securityfocus.com/bid/)

Snort ID

The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID.

Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If a vulnerability is associated with more than one SID, the vulnerabilities table includes a row for each SID.

Title

The title of the vulnerability.

IP Address

The IP address associated with the host affected by the vulnerability.

Date Published

The date the vulnerability was published.

Vulnerability Impact

Displays the severity assigned to the vulnerability in the Bugtraq database on a scale of 0 to 10, with 10 being the most severe. The vulnerability impact is determined by the writer of the Bugtraq entry based on his or her best judgment and guided by SANS Critical Vulnerability Analysis (CVA) criteria.

Remote

Indicates whether the vulnerability is remotely exploitable.

Available Exploits

Indicates whether there are known exploits for the vulnerability.

Description

A brief description of the vulnerability.

Technical Description

A detailed technical description of the vulnerability.

Solution

Information about repairing the vulnerability.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Deactivating Vulnerabilities

License: FireSIGHT

Deactivate a vulnerability after you patch the hosts on your network or otherwise judge them immune. Deactivated vulnerabilities are not used for intrusion impact correlation. Note that if the system discovers a new host that is affected by that vulnerability, the vulnerability is considered valid (and is not automatically deactivated) for that host.

You can deactivate vulnerabilities within the vulnerabilities workflow only on a workflow page that shows vulnerabilities for specific hosts on your network, that is:

- on the second page of the default vulnerabilities workflow, Vulnerabilities on the Network , which shows only the vulnerabilities that apply to the hosts on your network

- on any page in a vulnerabilities workflow, custom or predefined, that you constrained based on IP address using a search.

Deactivating a vulnerability within a vulnerabilities workflow that is not constrained on IP addresses deactivates the vulnerability for all detected hosts on your network. To deactivate a vulnerability for a single host, you have three options:

- Use the network map.

For more information, see Working with the Vulnerabilities Network Map.

- Use the host’s host profile.

For more information, see Setting Vulnerabilities for Individual Hosts.

- Constrain the vulnerabilities workflow based on the IP addresses of the host or hosts for which you want to deactivate vulnerabilities. For hosts with multiple associated IP addresses, this function applies only to the single, selected IP address of that host.

To constrain the view based on IP address, perform a search for vulnerabilities, specifying an IP address or range of IP addresses for the hosts for which you want to deactivate vulnerabilities. For more information on searching for vulnerabilities, see Searching for Vulnerabilities.

To deactivate vulnerabilities:

Access: Admin/Any Security Analyst

Step 1 On the Vulnerabilities on the Network page, select the check boxes next to vulnerabilities you want to deactivate, then click Review.

Searching for Vulnerabilities

License: FireSIGHT

You can search for vulnerabilities that affect the hosts on your network. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Specific Search Criteria for Vulnerabilities

Note the following information specific to searching for vulnerabilities:

- Find Bugtraq ID numbers at http://www.securityfocus.com/bid .

- Enter TRUE to search for vulnerabilities that are exploited, or FALSE to exclude such vulnerabilities.

To search for vulnerabilities:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Vulnerabilities from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default vulnerabilities workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Third-Party Vulnerabilities

License: FireSIGHT

The FireSIGHT System includes its own vulnerability tracking database which is used, in conjunction with the system’s fingerprinting capability, to identify the vulnerabilities associated with the hosts on your network.

If your organization can write scripts or create command line import files to import network map data from third-party applications, you can import third-party vulnerability data to augment the system’s vulnerability data. For more information, see the FireSIGHT System Host Input API Guide.

To include imported data in impact correlations, you must map third-party vulnerability information to the operating system and application definitions in the database. You cannot map third-party vulnerability information to client definitions.

For more information, see:

- Viewing Third-Party Vulnerabilities

- Understanding the Third-Party Vulnerabilities Table

- Searching for Third-Party Vulnerabilities

Viewing Third-Party Vulnerabilities

License: FireSIGHT

After you use the host input feature to import third-party vulnerability data, you can use the Defense Center to view a table of third-party vulnerabilities. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access third-party vulnerabilities differs depending on the workflow you use. There are two predefined workflows. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

Viewing Vulnerability Details

Table 50-12 Third-Party Vulnerability Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Third-Party Vulnerabilities Table.

view the vulnerability details for a third-party vulnerability

) in the SVID column. Alternatively, constrain on the vulnerability ID and drill down to the vulnerability details page. For more information, see .

To view third-party vulnerabilities:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Vulnerabilities > Third-Party Vulnerabilities.

The first page of the default third-party vulnerabilities workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of third-party vulnerabilities, click (switch workflow), then select Vulnerabilities by Source or Vulnerabilities by IP Address.

Understanding the Third-Party Vulnerabilities Table

License: FireSIGHT

When you import third-party vulnerability information using the host input feature, the system stores that information in its database. The fields in the third-party vulnerabilities table are described in the following table.

Vulnerability Source

The source of the third-party vulnerabilities, for example, QualysGuard or NeXpose.

Vulnerability ID

The ID number associated with the vulnerability for its source.

IP Address

The IP address associated with the host affected by the vulnerability.

Port

A port number, if the vulnerability is associated with a server running on a specific port.

Bugtraq ID

The identification number associated with the vulnerability in the Bugtraq database. (http://www.securityfocus.com/bid/)

CVE ID

The identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures (CVE) database (http://www.cve.mitre.org/).

SVID

The legacy vulnerability identification number that the system uses to track vulnerabilities

) to access the vulnerability details for the SVID. See Viewing Vulnerability Details for more information.

Snort ID

The identification number associated with the vulnerability in the Snort ID (SID) database. That is, if an intrusion rule can detect network traffic that exploits a particular vulnerability, that vulnerability is associated with the intrusion rule’s SID.

Note that a vulnerability can be associated with more than one SID (or no SIDs at all). If a vulnerability is associated with more than one SID, the vulnerabilities table includes a row for each SID.

Title

The title of the vulnerability.

Description

A brief description of the vulnerability.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for Third-Party Vulnerabilities

License: FireSIGHT

You can search for third-party vulnerabilities that affect the hosts on your network. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Specific Search Criteria for Vulnerabilities

Note the following information specific to searching for vulnerabilities:

- Find Bugtraq ID numbers at http://www.securityfocus.com/bid .

- Enter TRUE to search for vulnerabilities that are exploited, or FALSE to exclude such vulnerabilities.

To search for third-party vulnerabilities:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Third-Party Vulnerabilities from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default third-party vulnerabilities workflow. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with Users

License: FireSIGHT

When either an Active Directory Agent or a managed device detects a user login for a user who is not already in the database, the user is added to the database, unless you have specifically restricted that login type (see Restricting User Logging).

Note Although the system detects SMTP logins, the system does not record them unless there is already a user with a matching email address in the database; users are not added to the database based on SMTP logins.

Table 50-13 Login Types and User Data Stored

Login Type

User Data Stored

LDAP

AIM

Oracle

SIP

HTTP

FTP

MDNS

- username

- current IP address

- login type ( aim , ldap , oracle , sip , http , ftp , or mdns )

POP3

IMAP

- username

- current IP address

- email address

- login type ( pop3 or imap )

If you configured Defense Center-LDAP server connections, the Defense Center queries the LDAP servers every five minutes and obtains metadata for the new users in the user database. At the same time, the Defense Center also queries the LDAP servers for updated information on users whose records in the Defense Center database are more than 12 hours old. It may take five to ten minutes for the Defense Center database to update with user metadata after the system detects a new user login. From the LDAP servers, the Defense Center obtains the following information and metadata about each user:

- LDAP username

- first and last names

- email address

- department

- telephone number

The number of users the Defense Center can store in its database depends on your FireSIGHT license. Note that AIM, Oracle, and SIP logins create duplicate user records because they are not associated with any of the user metadata that the system obtains from LDAP servers. To prevent overuse of user count because of duplicate user records from these protocols, disable logging of the protocols in the network discovery policy. For more information, see Restricting User Logging.

You can search, view, and delete users from the database; you can also purge all users from the database. For more information, see the following sections:

- Viewing Users

- Understanding the Users Table

- Understanding User Details and Host History

- Searching for Users

Viewing Users

License: FireSIGHT

You can view a table of users, and then manipulate the event view depending on the information you are looking for.

The page you see when you access users differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of users that lists all detected users, and terminates in a user details page. The user details page provides information on every user that meets your constraints.

You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

For more information about the contents of the columns in the table, see Understanding the Users Table.The following table, see describes some of the specific actions you can perform on an users workflow page. You can also perform the actions in the Common Discovery Event Actions table.

To view users:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Users > Users.

The first page of the default users workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Tip If you are using a custom workflow that does not include the table view of users, click (switch workflow), then select Users.

Understanding the Users Table

License: FireSIGHT

When the system discovers a user, it collects data about that user and stores it in the database. Descriptions of the fields in the users table follow.

User

One of:

– the first name, last name, and username of the user as collected via the optional Defense Center-LDAP server connections

– the username only, if you have not configured Defense Center-LDAP server connections, or for users that the Defense Center cannot correlate with an LDAP record

The Defense Center also displays the protocol used to detect the user.

Note that because unsuccessful AIM login attempts are recorded, the Defense Center can store invalid AIM users (for example, if a user misspelled his or her username).

Current IP

The IP address associated with the host that the user is logged into. This field is blank if another authoritative user logs into the host with the same IP address after the user’s login, unless the user is an authoritative user and the new user is a non-authoritative user. (The system associates the IP address with the last authoritative user that logged in with the host.) For more information on authoritative vs. non-authoritative users, see Users Database.

First Name

The user’s first name, as obtained from the optional Defense Center-LDAP server connections. This field is blank if:

– you have not configured a Defense Center-LDAP server connection

– the Defense Center cannot correlate the user in the Defense Center database with an LDAP record (for example, for users added to the database via an AIM, Oracle, or SIP login)

– there is no first name associated with the user on your LDAP servers

Last Name

The user’s last name, as obtained from the optional Defense Center-LDAP server connections. This field is blank if:

– you have not configured a Defense Center-LDAP server connection

– the Defense Center cannot correlate the user in the Defense Center database with an LDAP record (for example, for users added to the database via an AIM, Oracle, or SIP login)

– there is no last name associated with the user on your LDAP servers

E-Mail

The user’s email address. This field is blank if:

– the user was added to the database via an AIM login

– the user was added to the database via an LDAP login and there is no email address associated with the user on your LDAP servers

Department

The user’s department, as obtained from the optional Defense Center-LDAP server connections. If there is no department explicitly associated with the user on your LDAP servers, the department is listed as whatever default group the server assigns. For example, on Active Directory, this is Users (ad). This field is blank if:

– you have not configured a Defense Center-LDAP server connection

– the Defense Center cannot correlate the user in the Defense Center database with an LDAP record (for example, for users added to the database via an AIM, Oracle, or SIP login)

Phone

The user’s telephone number, as obtained from the optional Defense Center-LDAP server connections. This field is blank if:

– you have not configured a Defense Center-LDAP server connection

– the Defense Center cannot correlate the user in the Defense Center database with an LDAP record (for example, for users added to the database via an AIM, Oracle, or SIP login)

– there is no telephone number associated with the user on your LDAP servers

User Type

The protocol used to detect the user. For example, for users added to the database when detects a POP3 login, the user type is pop3.

Count

The number of users that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Understanding User Details and Host History

License: FireSIGHT

From any event view that associates user identity data with other kinds of events, as well as from a table view of users, you can display the User Identity pop-up window to learn more about a specific user. User information also appears in the terminating page for users workflows.

The user data you see is the same as you would see in the table view of users; for more information, see Understanding the Users Table.

The host history provides a graphic representation of the last twenty-four hours of the user’s activity. A list of IP addresses of the hosts that the user logged into and logged off of approximates login and logout times with bar graphs. A typical user might log on to and off of multiple hosts in the course of a day. For example, periodic automated logins to a mail server would display as multiple short sessions, while longer logins (such as during working hours) display longer sessions.

Note that when a non-authoritative user login to a host is detected, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user login is detected for that host, only another authoritative user login changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control. If you configure capture of failed logins in the network discovery policy, the host history also includes hosts where the user failed to log in.

The data used to generate the host history is stored in the user history database, which by default stores 10 million user login events. If you do not see any data in the host history for a particular user, either that user is inactive, or you may need to increase the database limit. For more information, see Configuring Database Event Limits.

To view user details and host history:

Access: Admin/Any Security Analyst

Step 1 You have two options:

- In any event view that lists users, click the user icon (

) that appears next to a user identity.

- In any users workflow, click the Users terminating page.

User details appear.

Searching for Users

License: FireSIGHT

You can search for specific users. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

Specific User Search Criteria

For User Type, valid search criteria are ldap, pop3, imap, oracle, sip, http, ftp, mdns, and aim; because users are not added to the database based on SMTP logins, entering smtp will not return any results.

To search for users:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Users from the table drop-down list.

The Users search page appears.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields.

If you enter criteria for multiple fields, the search returns only the records that match search criteria specified for all fields.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default users workflow. To use a different workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Working with User Activity

License: FireSIGHT

The FireSIGHT System generates events that communicate the details of user activity on your network. Descriptions of the four types of user activity follow.

New User Identity

This event is generated when the system detects a user login for a user that is not in the database.

User Login

This event is generated when any of the following occur:

– an Active Directory Agent that you installed on an Active Directory server detects an LDAP login

– a managed device detects an LDAP, POP3, IMAP, SMTP, AIM, Oracle, FTP, HTTP, MDNS or SIP login

– There are several points to keep in mind regarding user login events:

– SMTP logins are not recorded unless there is already a user with a matching email address in the database.

– Failed logins are only for LDAP, IMAP, FTP, and POP3, and only when detected in traffic. Users are not added to the detected users database as a result of a failed login, but the activity is optionally recorded in the user activity database, based on the user logging configuration in the network discovery policy.

– A user login is not recorded if you have specifically restricted its login type; see Restricting User Logging.

Note that when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user. In addition, when a non-authoritative user is the current user on a host, that user still cannot be used for user control.

Delete User Identity

This event is generated when you manually delete a user from the database.

User Identity Dropped: User Limit Reached

This event is generated when the system detects a user that is not in the database, but cannot add the user because you have reached the maximum number of users in the database as determined by your FireSIGHT license.

The total number of detected users the Defense Center can store depends on your FireSIGHT license. After you reach the licensed limit, in most cases the system stops adding new users to the database. To add new users, you must either manually delete old or inactive users from the database, or purge all users from the database.

However, the system favors authoritative users. If you have reached the limit and the system detects a login for a previously undetected authoritative user, the system deletes the non-authoritative user who has remained inactive for the longest time, and replaces it with the new authoritative user.

When the system detects user activity, it is logged to the database. You can view, search, and delete user activity; you can also purge all user activity from the database.

Whenever possible the FireSIGHT System correlates user activity with other types of events. For example, intrusion events can tell you the users who were logged into the source and destination hosts at the time of the event. This can tell you who owns the host that was targeted by an attack, or who initiated an internal attack or portscan.

You can also use user activity in correlation rules. Based on the type of user activity as well as other criteria that you specify, you can build correlation rules that, when used in a correlation policy, launch remediations and alert responses when network traffic meets your criteria. For more information on user activity, see Understanding User Data Collection.

For more information, see the following sections:

- Viewing User Activity Events

- Understanding the User Activity Table

- Searching for User Activity

Viewing User Activity Events

License: FireSIGHT

You can view a table of user activity, and then manipulate the event view depending on the information you are looking for.

The page you see when you access user activity differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of user activity and terminates in a user details page, which contains user details for every user that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

For more information about the contents of the columns in the table, see Understanding the User Activity Table.The following table, see describes some of the specific actions you can perform on an user activity workflow page. You can also perform the actions in the Common Discovery Event Actions table.

To view user activity:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Users > User Activity.

The first page of the default user activity workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of user activity, click (switch workflow), then select User Activity.

Understanding the User Activity Table

License: FireSIGHT

When the system detects user activity, it is logged to the database. Descriptions of the fields in the users table follow.

Time

The time that the system detected the user activity.

Event

The user activity type. For more information, see Working with User Activity.

User

The user associated with the activity. At a minimum, this field contains a username and the protocol used to detect the user. If there is LDAP metadata on the user, this field may also contain the first name and last name of the user.

User Type

The protocol used to detect the user. For example, for users added to the database when the system detects a POP3 login, the user type is pop3.

IP Address

For User Login activity, the IP address involved in the login, which can be an IP address of the user’s host (for LDAP, POP3, IMAP, FTP, HTTP, MDNS, and AIM logins), the server (for SMTP and Oracle logins), or the session originator (for SIP logins).

Note that an associated IP address does not mean the user is the current user for that IP address; when a non-authoritative user logs into a host, that login is recorded in the user and host history. If no authoritative user is associated with the host, a non-authoritative user can be the current user for the host. However, after an authoritative user logs into the host, only a login by another authoritative user changes the current user.

For other types of user activity, this field is blank.

Description

For Delete User Identity and User Identity Dropped activity, the username of the user who was deleted from the database or failed to be added to the database. For logins to network resources, network login is displayed. For other types of user activity, this field is blank.

Device

For user activity detected by a managed device, the name of the device. For other types of user activity, the managing Defense Center.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for User Activity

License: FireSIGHT

You can search for specific user activity. You may want to create searches customized for your network environment, then save them to reuse later.

General Search Syntax

The system displays examples of valid syntax next to each search field. When entering search criteria, keep the following points in mind:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- For some fields, you can specify n/a or blank in the field to identify events where information is not available for that field; use !n/a or !blank to identify the events where that field is populated.

- Most fields are case-insensitive.

- IP addresses may be specified using CIDR notation. For information on entering IPv4 and IPv6 addresses in the FireSIGHT System, see IP Address Conventions.

- Use the device field to search for specific devices as well as devices in groups, stacks, or clusters. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For detailed information on search syntax, including using objects in searches, see Searching for Events.

To search for user activity:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select User Activity from the table drop-down menu.

The User Activity search page appears.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields.

) that appears next to a search field to use an object as a search criterion.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for custom user roles with restricted privileges, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default user activity workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Configuring Correlation Policies and Rules

You can use the FireSIGHT System’s correlation feature to build correlation policies, which are populated with correlation rules and compliance white lists, and that let you respond in real time to threats to your network. A correlation policy violation occurs when the activity on your network triggers either a correlation rule or white list.

A correlation rule triggers when a specific event generated by the FireSIGHT System either meets criteria that you specify, or when your network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile.

Compliance white lists, on the other hand, trigger when the system determines that a host on your network is running a prohibited operating system, client application (or client), application protocol, or protocol.

You can configure the FireSIGHT System to initiate responses to policy violations. Responses include simple alerts as well as various remediations (such as scanning a host). You can group responses so that the system launches multiple responses for each policy violation.

This chapter focuses on creating correlation rules, using those rules in policies, associating responses and response groups with those rules, and analyzing correlation events. For more information, see:

- Creating Rules for Correlation Policies

- Managing Rules for Correlation Policies

- Grouping Correlation Responses

- Creating Correlation Policies

- Managing Correlation Policies

- Working with Correlation Events

For information on creating compliance white lists and correlation responses (alerts and remediations), see:

- Using the FireSIGHT System as a Compliance Tool

- Working with Alert Responses.

- Configuring Correlation Policies and Rules.

Creating Rules for Correlation Policies

License: FireSIGHT, Protection, URL Filtering, or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Before you create a correlation policy, you should create correlation rules or compliance white lists (or both) to populate it.

Note This section describes how to create correlation rules. For information on creating compliance white lists, see Creating Compliance White Lists.

A correlation rule triggers (and generates a correlation event) when your network traffic meets criteria that you specify. When you create correlation rules, you can use simple conditions or you can create more elaborate constructs by combining and nesting conditions and constraints.

You can further add to correlation rules in the following ways:

- Add a host profile qualification to constrain the rule using information from the host profile of a host involved in the triggering event.

- Add a connection tracker to a correlation rule so that after the rule’s initial criteria are met, the system begins tracking certain connections. Then, a correlation event is generated only if the tracked connections meet additional criteria.

- Add a user qualification to a correlation rule to track certain users or groups of users. For example, you could constrain a correlation rule so that it triggers only when the identity of the source or destination user is a certain user or, for example, one from the marketing department.

- Add snooze periods and inactive periods . When a correlation rule triggers once, a snooze period causes that rule not to trigger again for a specified interval, even if the rule is violated again during the interval. After the snooze period has elapsed, the rule can trigger again (and start a new snooze period). During inactive periods, the correlation rule does not trigger.

Caution Evaluating complex correlation rules that trigger on frequently occurring events can degrade Defense Center performance. For example, a multi-condition rule that the Defense Center must evaluate against every connection logged by the system can cause resource overload.

To...

You need this license...

trigger a correlation rule on an intrusion event or Security Intelligence event

Protection

trigger a correlation rule on a discovery event, host input event, geolocation data, or user activity, or to add a host profile or user qualification to a correlation rule

FireSIGHT

trigger a correlation rule on a connection event or endpoint-based malware event, or to add a connection tracker to a rule

Any

trigger a correlation rule on a connection event with URL data, or build a connection tracker using URL data

Note that neither Series 2 devices nor the DC500 Defense Center support URL filtering by category or reputation, and Series 2 devices do not support URL filtering by literal URL or URL group.

URL Filtering

trigger a correlation rule on a malware event based on network-based malware data or retrospective network-based malware data

Note that Series 2 and Cisco NGIPS for Blue Coat X-Series devices and the DC500 Defense Center do not support network-based malware protection.

Malware

Due to memory limitations, some device models perform URL filtering with a smaller, less granular, set of categories and reputations. For example, if a parent domain's subsites have different URL categories and reputations, some devices may use the parent site's data for all subsites. These devices include the 7100 Family and the following ASA FirePOWER models: ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, ASA 5516-X, and the ASA 5525-X.

For virtual devices, see the installation guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.

When you create either correlation rule trigger criteria, host profile qualifications, user qualifications, or connection trackers, the syntax varies but the mechanics remain consistent. For more information, See Understanding Rule Building Mechanics.

To create a correlation rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 Provide basic rule information, such as the rule name, description, and group.

See Providing Basic Rule Information.

Step 4 Specify the basic criteria on which you want the rule to trigger.

See Specifying Correlation Rule Trigger Criteria.

Step 5 Optionally, add a host profile qualification to the rule.

See Adding a Host Profile Qualification.

Step 6 Optionally, add a connection tracker to the rule.

See Constraining Correlation Rules Using Connection Data Over Time.

Step 7 Optionally, add a user qualification to the rule.

See Adding a User Qualification.

Step 8 Optionally, add an inactive period or snooze period (or both) to the rule.

See Adding Snooze and Inactive Periods.

Step 9 Click Save Rule.

The rule is saved. You can now use the rule within correlation policies or within other correlation rules that trigger on the same event type.

Providing Basic Rule Information

License: Any

You must give each correlation rule a name and, optionally, a short description. You can also place the rule in a rule group.

To provide basic rule information:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 On the Create Rule page, in the Rule Name field, type a name for the rule.

Step 4 In the Rule Description field, type a description for the rule.

Step 5 Optionally, select a group for the rule from the Rule Group drop-down list.

For more information on rule groups, see Managing Rules for Correlation Policies.

Step 6 Continue with the procedure in the next section, Specifying Correlation Rule Trigger Criteria.

Specifying Correlation Rule Trigger Criteria

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

A simple correlation rule requires only that an event of a certain type occurs; you do not need to provide more specific conditions. For example, correlation rules based on traffic profile changes do not require any conditions at all. In contrast, correlation rules may be complex, with multiple nested conditions. For example, the rule shown in the following graphic comprises criteria that direct the rule to trigger if an IP address that is not in the 10.x.x.x subnet transmits an IGMP message.

Note When building a condition based on events, you can add a correlation rule trigger criterion only if your device can collect the information required for the condition, and your Defense Center can manage that information. For example, because neither Series 2 devices nor the DC500 Defense Center support SSL inspection, URL filtering by category or reputation, or Security Intelligence, you cannot configure event conditions on those appliances based on those features. For more information, see Creating Rules for Correlation Policies.

To specify correlation rule trigger criteria:

Access: Admin/Discovery Admin

Step 1 Select the type of event on which you want to base your rule.

When you build a correlation rule, you must first select the type of event on which you want to base your rule. You have a few options under Select the type of event for this rule:

- Select an intrusion event occurs to trigger your rule when a specific intrusion event occurs.

- Select a Malware event occurs to trigger the rule when a specific malware event occurs.

- Select a discovery event occurs to trigger the rule when a specific discovery event occurs. When triggering a correlation rule on a discovery event, you must also choose the type of event you want to use. You can choose from a subset of the discovery events described in Understanding Discovery Event Types; you cannot, for example, trigger a correlation rule on a hops change. You can, however, choose there is any type of event to trigger the rule when any kind of discovery event occurs.

- Select user activity is detected to trigger the rule when a new user is detected or a user logs in to a host.

- Select a host input event occurs to trigger the rule when a specific host input event occurs. When triggering a correlation rule on a host input event, you must also choose the type of event you want to use. You can choose from a subset of the events described in Understanding Host Input Event Types.

- Select a connection event occurs to trigger the rule when connection data meets specific criteria. When triggering a correlation rule on a connection event, you must also choose whether you want to use connection events that represent the beginning or the ending of the connection, or either.

- Select a traffic profile changes to trigger the correlation rule when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile.

Step 2 Specify the rule’s conditions.

The syntax you can use within correlation rule trigger criteria conditions varies depending on the base event you chose in step 1, but the mechanics are the same. For more information, see Understanding Rule Building Mechanics.

The syntax you can use to build conditions is described in the following sections:

- Syntax for Intrusion Events

- Syntax for Malware Events

- Syntax for Discovery Events

- Syntax for User Activity Events

- Syntax for Host Input Events

- Syntax for Connection Events

- Syntax for Traffic Profile Changes

Tip You can nest rules that share the base event type you specified in step 1. For example, if you create a new rule based on the detection of an open TCP port, the trigger criteria for the new rule could include rule “MyDoom Worm” is true and rule “Kazaa (TCP) P2P” is true.

Step 3 Optionally, continue with the procedures in the following sections:

- Adding a Host Profile Qualification

- Constraining Correlation Rules Using Connection Data Over Time

- Adding a User Qualification

- Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Intrusion Events

License: Protection

The following table describes how to build a correlation rule condition when you choose an intrusion event as the base event.

If you specify...

Select an operator, then...

Access Control Policy

Select one or more access control policies that use the intrusion policy that generated the intrusion event.

Access Control Rule Name

Type all or part of the name of the access control rule that uses the intrusion policy that generated the intrusion event.

Application Protocol

Select one or more application protocols associated with the intrusion event.

Application Protocol Category

Select one or more category of application protocol.

Classification

Select one or more classifications.

Client

Select one or more clients associated with the intrusion event.

Client Category

Select one or more category of client.

Destination Country or Source Country

Select one or more countries associated with the source or destination IP address in the intrusion event.

Destination IP, Source IP, or

Source/Destination IP

Specify a single IP address or an address block. For information on using IP address notation and prefix lengths in the FireSIGHT System, see IP Address Conventions.

Destination Port/ICMP Code or Source Port/ICMP Type

Type the port number or ICMP type for source traffic or the port number or ICMP type for destination traffic.

Device

Select one or more devices that may have generated the event.

Egress Interface or

Ingress Interface

Select one or more interfaces.

Egress Security Zone or Ingress Security Zone

Select one or more security zones.

Generator ID

Select one or more preprocessors. See Configuring Preprocessors in a Network Analysis Policy for more information about available preprocessors.

Impact Flag

Select the impact level assigned to the intrusion event. You select any of the following along with operators that specify is, is not, is greater than, and so on:

- 0 — gray (Unknown)

- 1 — red (Vulnerable)

- 2 — orange (Potentially Vulnerable)

- 3 — yellow (Currently Not Vulnerable)

- 4 — blue (Unknown Target)

Note Because there is no operating system information available for hosts added to the network map based on NetFlow data, the Defense Center cannot assign Vulnerable (level 1: red) impact levels for intrusion events involving those hosts, unless you use the host input feature to manually set the host operating system identity.

For more information, see Using Impact Levels to Evaluate Events.

Inline Result

Select either:

- dropped , to specify whether the packet was dropped in an inline, switched, or routed deployment

- would have dropped , to specify whether the packet would have dropped if the intrusion policy had been set to drop packets in an inline, switched, or routed deployment

Note that the system does not drop packets in a passive deployment, including when an inline set is in tap mode, regardless of the rule state or the drop behavior of the intrusion policy.

Intrusion Policy

Select one or more intrusion policies that generated the intrusion event.

IOC Tag

Select whether an IOC tag is or is not set as a result of the intrusion event.

Priority

Select the rule priority: low, medium, or high.

For rule-based intrusion events, the priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor.

Protocol

Type the name or number of the transport protocol as listed in

http://www.iana.org/assignments/protocol-numbers.

Rule Message

Type all or part of the rule message.

Rule SID

Type a single Snort ID number (SID) or multiple SIDs separated by commas.

as the operator, you cannot use the multi-selection pop-up window. You must type a comma-separated list of SIDs.

Rule Type

Specify whether the rule is or is not local. Local rules include custom standard text intrusion rules, standard text rules that you modified, and any new instances of shared object rules created when you saved the rule with modified header information. For more information, see Modifying Existing Rules.

SSL Actual Action

Select the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Type the fingerprint of the certificate used to encrypt the traffic, or select a subject common name associated with the fingerprint.

SSL Certificate Subject Common Name (CN)

Type all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Select one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Type all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Type all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Flow Status

Select one or more statuses based on the result of the system’s attempt to decrypt the traffic.

Username

Type the username of the user logged into the source host in the intrusion event.

VLAN ID

Type the innermost VLAN ID associated with the packet that triggered the intrusion event

Web Application

Select one or more web applications associated with the intrusion event.

Web Application Category

Select one or more category of web application.

Syntax for Malware Events

License: Any or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The syntax for correlation rule conditions based on malware events depends on whether the event is reported by an endpoint-based malware agent, detected by a managed device, or detected by a managed device and retrospectively identified as malware.

Note that because Series 2 and Cisco NGIPS for Blue Coat X-Series devices and the DC500 Defense Center do not support network-based malware protection, these appliances do not support triggering a correlation rule on a malware event based on network-based malware data or retrospective network-based malware data.

When you build rule conditions, you should make sure that your network traffic can trigger the rules. The information available for any individual connection or connection summary event depends on several factors, including the detection method, the logging method, and event type. For more information, see Understanding the Malware Events Table.

If you specify...

Select an operator, then...

Application Protocol

Select one or more application protocols associated with the malware event.

Application Protocol Category

Select one or more category of application protocol.

Client

Select one or more clients associated with the malware event.

Client Category

Select one or more category of client.

Destination Country or Source Country

Select one or more countries associated with the source or destination IP address in the malware event.

Destination IP, Host IP, or Source IP

Specify a single IP address or address block. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Destination Port/ICMP Code

Type the port number or ICMP code for destination traffic.

Disposition

Select either or both Malware or Custom Detection.

Event Type

Select one or more endpoint-based event types associated with the malware event. For more information, see Malware Event Types.

File Name

Type the name of the file.

File Type

Select the type of file, for example, PDF or MSEXE.

File Type Category

Select one or more file type categories, for example, Office Documents or Executables.

IOC Tag

Select whether an IOC tag is or is not set as a result of the malware event.

SHA-256

Type or paste the SHA-256 hash value of the file.

SSL Actual Action

Select the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Type the fingerprint of the certificate used to encrypt the traffic, or select a subject common name associated with the fingerprint.

SSL Certificate Subject Common Name (CN)

Type all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Select one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Type all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Type all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Flow Status

Select one or more statuses based on the result of the system’s attempt to decrypt the traffic.

Source Port/ICMP Type

Type the port number or ICMP type for source traffic.

Web Application

Select one or more web applications associated with the malware event.

Web Application Category

Select one or more category of web application.

Syntax for Discovery Events

License: FireSIGHT

If you base your correlation rule on a discovery event, you must first choose the type of event you want to use from a drop-down list. The following table lists the events you can choose as trigger criteria from the drop-down list, cross-referenced with their corresponding event types. For detailed descriptions of discovery event types, see Understanding Discovery Event Types.

Table 51-4 Correlation Rule Trigger Criteria vs. Discovery Event Types

Select this option...

To trigger the rule on this event type...

a client has changed

Client Update

a client timed out

Client Timeout

a host IP address is reused

DHCP: IP Address Reassigned

a host is deleted because the host limit was reached

Host Deleted: Host Limit Reached

a host is identified as a network device

Host Type Changed to Network Device

a host timed out

Host Timeout

a host’s IP address has changed

DHCP: IP Address Changed

a NETBIOS name change is detected

NETBIOS Name Change

a new client is detected

New Client

a new IP host is detected

New Host

a new MAC address is detected

Additional MAC Detected for Host

a new MAC host is detected

New Host

a new network protocol is detected

New Network Protocol

a new transport protocol is detected

New Transport Protocol

a TCP port closed

TCP Port Closed

a TCP port timed out

TCP Port Timeout

a UDP port closed

UDP Port Closed

a UDP port timed out

UDP Port Timeout

a VLAN tag was updated

VLAN Tag Information Update

an IOC was set

Indication of Compromise

an open TCP port is detected

New TCP Port

an open UDP port is detected

New UDP Port

the OS information for a host has changed

New OS

the OS or server identity for a host has a conflict

Identity Conflict

the OS or server identity for a host has timed out

Identity Timeout

there is any kind of event

any event type

there is new information about a MAC address

MAC Information Change

there is new information about a TCP server

TCP Server Information Update

there is new information about a UDP server

UDP Server Information Update

Note that you cannot trigger a correlation rule on hops changes, or when the system drops a new host due to reaching the licensed host limit. You can, however, choose there is any type of event to trigger the rule when any type of discovery event occurs.

If you specify...

Select an operator, then...

Application Protocol

Select one or more application protocols.

Application Protocol Category

Select one or more category of application protocol.

Application Port

Type the application protocol port number.

Client

Select one or more clients.

Client Category

Select one or more category of client.

Client Version

Type the version number of the client.

Device

Select one or more devices that may have generated the discovery event.

Hardware

Type the hardware model for the mobile device. For example, to match all Apple iPhones, type iPhone.

Host Type

Select one or more host types from the drop-down list. You can choose between a host or one of several types of network device.

IP Address or

New IP Address

Type a single IP address or address block. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Jailbroken

Select Yes to indicate that the host in the event is a jailbroken mobile device or No to indicate that it is not.

MAC Address

Type all or part of the MAC address of the host.

For example, if you know that devices from a certain hardware manufacturer have MAC addresses that begin with 0A:12:34, you could choose begins with as the operator, then type 0A:12:34 as the value.

MAC Type

Select whether the MAC address was ARP/DHCP Detected.

That is, select whether the system positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), or whether the system is seeing many hosts with that MAC address because, for example, there is a router between the managed device and the host (is not ARP/DHCP Detected).

MAC Vendor

Type all or part of the name of the MAC hardware vendor of the NIC used by the network traffic that triggered the discovery event.

Mobile

Select Yes to indicate that the host in the event is a mobile device or No to indicate that it is not.

NETBIOS Name

Type the NetBIOS name of the host.

Network Protocol

Type the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

OS Name

Select one or more operating system names.

OS Vendor

Select one or more operating system vendors.

OS Version

Select one or more operating system versions.

Protocol or

Transport Protocol

Type the name or number of the transport protocol as listed in

http://www.iana.org/assignments/protocol-numbers.

Source

Select the source of the host input data (for operating system and server identity changes and timeouts).

Source Type

Select the type of the source for the host input data (for operating system and server identity changes and timeouts).

VLAN ID

Type the VLAN ID of the host involved in the event.

Web Application

Select a web application.

Syntax for User Activity Events

License: FireSIGHT

If you base your correlation rule on user activity, you must first choose the type of user activity you want to use from a drop-down list, either:

- a user logged into a host, or

- a new user identity was detected

If you specify...

Select an operator, then...

Device

Select one or more devices that may have detected the user activity.

IP Address

Type a single IP address or address block. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Username

Type a username.

Syntax for Host Input Events

License: FireSIGHT

If you base your correlation rule on a host input event, you must first choose the type of host input event you want to use from a drop-down list. The following table lists the events you can choose as trigger criteria from the drop-down list, cross-referenced with their corresponding host input event types. For detailed descriptions of host input event types, see Understanding Host Input Event Types.

Table 51-7 Correlation Rule Trigger Criteria vs. Host Input Event Types

Select this option...

To trigger the rule on this event type...

a client is added

Add Client

a client is deleted

Delete Client

a host is added

Add Host

a protocol is added

Add Protocol

a protocol is deleted

Delete Protocol

a scan result is added

Add Scan Result

a server definition is set

Set Server Definition

a server is added

Add Port

a server is deleted

Delete Port

a vulnerability is marked invalid

Vulnerability Set Invalid

a vulnerability is marked valid

Vulnerability Set Valid

an address is deleted

Delete Host/Network

an attribute value is deleted

Host Attribute Delete Value

an attribute value is set

Host Attribute Set Value

an OS definition is set

Set Operating System Definition

host criticality is set

Set Host Criticality

You cannot trigger a correlation rule when you add, delete, or change the definition of a user-defined host attribute, or set a vulnerability impact qualification.

If you specify...

Select an operator, then...

IP Address

Type a single IP address or address block. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Source

Select the source for the host input data.

Source Type

Select the type of the source for the host input data.

Syntax for Connection Events

License: Any

If you base your correlation rule on a connection event, you must first choose whether you want to evaluate events that represent the beginning or ending of the connection, or either the beginning or the end. After you choose the connection event type, you can build correlation rule conditions as described in the Syntax for Connection Events table.

If you specify...

Select an operator, then...

Access Control Policy

Select one or more access control policies that logged the connection.

Access Control Rule Action

Select one or more actions associated with the access control rule that logged the connection.

to trigger correlation events when network traffic matches the conditions of any Monitor rule, regardless of the rule or default action that later handles the connection.

Access Control Rule Name

Type all or part of the name of the access control rule that logged the connection.

Note You can type the name of any Monitor rule whose conditions were matched by a connection, regardless of the rule or default action that later handled the connection.

Application Protocol

Select one or more application protocols associated with the connection.

Application Protocol Category

Select one or more category of application protocol.

Client

Select one or more clients.

Client Category

Select one or more category of client.

Client Version

Type the version number of the client.

Connection Duration

Type the duration of the connection event, in seconds.

Connection Type

Select whether you want to trigger the correlation rule based on whether the connection was detected by a Cisco managed device (FireSIGHT) or was exported by a NetFlow-enabled device (NetFlow).

Destination Country or Source Country

Select one or more countries associated with the source or destination IP address in the connection event.

Device

Select one or more devices that either detected the connection, or that processed the connection (for connection data exported by a NetFlow-enabled device).

Egress Interface or

Ingress Interface

Select one or more interfaces.

Egress Security Zone or

Ingress Security Zone

Select one or more security zones.

Initiator Bytes,

Responder Bytes, or

Total Bytes

Type one of:

- the number of bytes transmitted ( Initiator Bytes ).

- the number of bytes received ( Responder Bytes ).

- the number of bytes both transmitted and received ( Total Bytes ).

Initiator IP,

Responder IP, or

Initiator/Responder IP

Specify a single IP address or an address block. For information on using IP address notation and prefix lengths in the FireSIGHT System, see IP Address Conventions.

Initiator Packets,

Responder Packets, or

Total Packets

Type one of:

- the number of packets transmitted ( Initiator Packets ).

- the number of packets received ( Responder Packets ).

- the number of packets both transmitted and received ( Total Packets )

Initiator Port/ICMP Type or Responder Port/ICMP Code

Type the port number or ICMP type for initiator traffic or the port number or ICMP code for responder traffic.

IOC Tag

Select whether an IOC tag is or is not set as a result of the connection event.

NETBIOS Name

Type the NetBIOS name of the monitored host in the connection.

NetFlow Device

Select the IP address of the NetFlow-enabled device that exported the connection data you want to use to trigger the correlation rule. If you did not add any NetFlow-enabled devices to your deployment, the NetFlow Device drop-down list is blank.

Reason

Select one or more reasons associated with the connection event.

Security Intelligence Category

Select one or more Security Intelligence categories associated with the connection event.

in the Security Intelligence section of your access control policy. For more information, see Building the Security Intelligence Whitelist and Blacklist.

SSL Actual Action

Select the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Type the fingerprint of the certificate used to encrypt the traffic, or select a subject common name associated with the fingerprint.

SSL Certificate Status

Select one or more statuses associated with the certificate used to encrypt the session.

SSL Certificate Subject Common Name (CN)

Type all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Select one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Type all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Type all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Cipher Suite

Select one or more cipher suites used to encrypt the session.

SSL Encrypted Session

Select Successfully Decrypted.

SSL Flow Status

Select one or more statuses based on the result of the system’s attempt to decrypt the traffic.

SSL Policy

Select one or more SSL policies that logged the encrypted connection.

SSL Rule Name

Type all or part of the name of the SSL rule that logged the encrypted connection.

SSL Server Name

Type all or part of the name of the server with which the client established an encrypted connection.

SSL URL Category

Select one or more URL categories for the URL visited in the encrypted connection.

SSL Version

Select one or more SSL or TLS versions used to encrypt the session.

TCP Flags

Select a TCP flag that a connection event must contain in order to trigger the correlation rule.

Note Only connection data exported by NetFlow-enabled devices contain TCP flags.

Transport Protocol

Type the transport protocol used by the connection: TCP or UDP.

URL

Type all or part of the URL visited in the connection.

URL Category

Select one or more URL categories for the URL visited in the connection.

URL Reputation

Select one or more URL reputation values for the URL visited in the connection.

Username

Type the username of the user logged into either host in the connection.

Web Application

Select one or more web applications associated with the connection.

Web Application Category

Select one or more category of web application.

Syntax for Traffic Profile Changes

License: Any

If you base your correlation rule on a traffic profile change, the rule triggers when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. For information on how to build a traffic profile, see Creating Traffic Profiles.

You can trigger the rule based on either raw data or on the statistics calculated from the data. For example, you could write a rule that triggers if the amount of data traversing your network (measured in bytes) suddenly spikes, which could indicate an attack or other security policy violation. You could specify that the rule trigger if either:

- the number of bytes traversing your network spikes above a certain number of standard deviations above or below the mean amount of traffic

Note that to create a rule that triggers when the number of bytes traversing your network falls outside a certain number of standard deviations (whether above or below), you must specify upper and lower bounds, as shown in the following graphic.

To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations above the mean, use only the first condition shown in the graphic.

To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations below the mean, use only the second condition.

- the number of bytes traversing your network spikes above a certain number of bytes

You can select the use velocity data check box (see Changing the Graph Type), to trigger the correlation rule based on rates of change between data points. If you wanted to use velocity data in the above example, you could specify that the rule triggers if either:

- the change in the number of bytes traversing your network spikes above or below a certain number of standard deviations above the mean rate of change

- the change in the number of bytes traversing your network spikes above a certain number of bytes

The following table describes how to build a condition in a correlation rule when you choose a traffic profile change as the base event. If your traffic profile uses connection data exported by NetFlow-enabled devices, see Differences Between NetFlow and FireSIGHT Data to learn about how the detection method can affect the data used to create your traffic profile.

Table 51-10 Syntax for Traffic Profile Changes

If you specify...

Select an operator, then type...

And then choose one of the following...

Number of Connections

the total number of connections detected

or

the number of standard deviations either above or below the mean that the number of connections detected must be in to trigger the rule

connections

standard deviation(s)

Total Bytes,

Initiator Bytes, or

Responder Bytes

one of:

- the total bytes transmitted ( Total Bytes )

- the number of bytes transmitted ( Initiator Bytes )

- the number of bytes received ( Responder Bytes )

or

the number of standard deviations either above or below the mean that one of the above criteria must be in to trigger the rule

bytes

standard deviation(s)

Total Packets,

Initiator Packets, or

Responder Packets

one of:

- the total packets transmitted ( Total Packets )

- the number of packets transmitted ( Initiator Packets )

- the number of packets received ( Responder Packets )

or

the number of standard deviations either above or below the mean that one of the above criteria must be in trigger the rule

packets

standard deviation(s)

Unique Initiators

the number of unique hosts that initiated sessions

or

the number of standard deviations either above or below the mean that the number of unique initiators detected must be to trigger the rule

initiators

standard deviation(s)

Unique Responders

the number of unique hosts that responded to sessions

or

the number of standard deviations either above or below the mean that the number of unique responders detected must be to trigger the rule

responders

standard deviation(s)

Adding a Host Profile Qualification

License: FireSIGHT

If you are using a connection, intrusion, discovery, user activity, or host input event to trigger your correlation rule, you can constrain the rule based on the host profile of a host involved in the event. This constraint is called a host profile qualification.

Note You cannot add a host profile qualification to a correlation rule that triggers on a malware event, traffic profile change, or on the detection of a new IP host.

For example, you could constrain a correlation rule so that it triggers only when a Microsoft Windows host is the target of the offending traffic, because only Microsoft Windows computers are vulnerable to the vulnerability the rule is written for. As another example, you could constrain a correlation rule so that it triggers only when the host is out of compliance with a white list.

To match against implied or generic clients, create a host profile qualification based on the application protocol used by the server responding to the client. When the client list on a host that acts as the initiator or source of a connection includes an application protocol name followed by client, that client may actually be an implied client. In other words, the system reports that client based on server response traffic that uses the application protocol for that client, not on detected client traffic.

For example, if the system reports HTTPS client as a client on a host, create a host profile qualification for Responder Host or Destination Host where Application Protocol is set to HTTPS, because HTTPS client is reported as a generic client based on the HTTPS server response traffic sent by the responder or destination host.

Note that to use a host profile qualification, the host must exist in the network map and the host profile property you want to use as a qualification must already be included in the host profile. For example, if you configure a correlation rule to trigger when an intrusion event is generated for a host running Windows, the rule only triggers if the host is already identified as Windows when the intrusion event is generated.

To add a host profile qualification:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 On the Create Rule page, click Add Host Profile Qualification.

The Host Profile Qualification section appears.

Tip To remove a host profile qualification, click Remove Host Profile Qualification.

Step 4 Build the host profile qualification’s conditions.

You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions.

The syntax you can use to build conditions is described in Syntax for Host Profile Qualifications.

Step 5 Optionally, continue with the procedures in the following sections:

- Constraining Correlation Rules Using Connection Data Over Time

- Adding a User Qualification

- Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Host Profile Qualifications

License: FireSIGHT

When you build a host profile qualification condition, you must first select the host you want to use to constrain your correlation rule. The host you can choose depends on the type of event you are using to trigger the rule, as follows:

- If you are using a connection event, select Responder Host or Initiator Host .

- If you are using an intrusion event, select Destination Host or Source Host .

- If you are using a discovery event, host input event, or user activity, select Host .

After you select the host type, you continue building your host profile qualification condition, as described in the following table.

Note that although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. In addition, if you use connection data exported by NetFlow-enabled devices, keep in mind that NetFlow records do not contain information about which host is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

Table 51-11 Syntax for Host Profile Qualifications

If you specify...

Select an operator, then...

Host Type

Select one or more host types. You can choose between a host or one of several types of network device.

NETBIOS Name

Type the NetBIOS name of the host.

Operating System > OS Name

Select one or more operating system names.

Operating System > OS Vendor

Select one or more operating system vendor names.

Operating System > OS Version

Select one or more operating system versions.

Hardware

Type the hardware model for the mobile device. For example, to match all Apple iPhones, type iPhone.

IOC Tag

Select one or more IOC tags. For more information on IOC tag types, see Understanding Indications of Compromise Types.

Jailbroken

Select Yes to indicate that the host in the event is a jailbroken mobile device or No to indicate that it is not.

Mobile

Select Yes to indicate that the host in the event is a mobile device or No to indicate that it is not.

Network Protocol

Type the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

Transport Protocol

Type the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

Host Criticality

Select the host criticality: None, Low, Medium, or High. For more information on host criticality, see Working with the Predefined Host Attributes.

VLAN ID

Type the VLAN ID associated with the host.

Application Protocol >

Application Protocol

Select one or more application protocols.

Application Protocol >

Application Port

Type the application protocol port number.

If you are using an intrusion event to trigger the correlation rule, depending on the host you chose for the host profile qualification, this field is pre-populated with a port in the event: dst_port (for Destination Host) or src_port (for Source Host).

Application Protocol >

Protocol

Select one or more protocols.

Application Protocol Category

Select a category.

Client > Client

Select one or more clients.

Client > Client Version

Type the client version.

Client Category

Select a category.

Web Application

Select a web application.

Web Application Category

Select a category.

MAC Address > MAC Address

Type all or part of the MAC address of the host.

For example, if you know that devices from a certain hardware have MAC addresses that begin with 0A:12:34, you could choose begins with as the operator, then type 0A:12:34 as the value.

MAC Address > MAC Type

Select whether the MAC type is ARP/DHCP Detected.

That is, select whether the system positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), whether the system is seeing many hosts with that MAC address because, for example, there is a router between the managed device and the host (is not ARP/DHCP Detected), or whether the MAC type is irrelevant (is any).

MAC Vendor >

MAC Vendor

Type all or part of the name of the MAC hardware vendor of the host.

any available host attribute, including the default compliance white list host attribute

Specify the appropriate value, which depends on the type of host attribute you select:

- If the host attribute type is Integer , enter an integer value in the range defined for the attribute.

- If the host attribute type is Text , enter a text value.

- If the host attribute type is List , select a valid list string.

- If the host attribute type is URL , enter a URL value.

For more information on host attributes, see Working with User-Defined Host Attributes.

Note that you can often use event data when constructing a host profile qualification. For example, assume your correlation rule triggers when the system detects the use of Internet Explorer on one of your monitored hosts. Further assume that when you detect this use, you want to generate an event if the version of the browser is not the latest (for this example, assume the latest version is 9.0).

You could add a host profile qualification to this correlation rule so that the rule triggers only if the Client is the Event Client (that is, Internet Explorer), but the Client Version is not 9.0.

Constraining Correlation Rules Using Connection Data Over Time

License: FireSIGHT

A connection tracker constrains a correlation rule so that after the rule’s initial criteria are met (including host profile and user qualifications), the system begins tracking certain connections. The Defense Center generates a correlation event for the rule if the tracked connections meet additional criteria gathered over a time period that you specify.

If you are using a connection, intrusion, discovery, user activity, or host input event to trigger your correlation rule, you can add a connection tracker to the rule. You cannot add a connection tracker to a rule that triggers on a malware event or traffic profile change.

Tip Connection trackers typically monitor very specific traffic and, when triggered, run only for a finite, specified time. Compare connection trackers with traffic profiles, which typically monitor a broad range of network traffic and run persistently; see Creating Traffic Profiles.

There are two ways a connection tracker can generate an event, depending on how you construct the tracker:

Connection Trackers That Fire Immediately When Conditions Are Met

You can configure a connection tracker so that the correlation rule fires as soon as network traffic meets the tracker’s conditions. When this happens, the system stops tracking connections for this connection tracker instance, even if the timeout period has not expired. If the same type of policy violation that triggered the correlation rule occurs again, the system creates a new connection tracker.

If, on the other hand time expires before network traffic meets the conditions in the connection tracker, the Defense Center does not generate a correlation event, and also stops tracking connections for that rule instance.

For example, a connection tracker can serve as a kind of event threshold by generating a correlation event only if a certain type of connection occurs more than a specific number of times within a specific time period. Or, you can generate a correlation event only if the system detects excessive data transfer after an initial connection.

Connection Trackers That Fire at The End of The Timeout Period

You can configure a connection tracker so that it relies on data collected over the entire timeout period, and therefore cannot fire until the end of the timeout period.

For example, if you configure a connection tracker to fire if you detect fewer than a certain number of bytes being transferred during a certain time period, the system waits until that time period passes and then generates an event if network traffic met that condition.

For more information, see the following sections:

- Adding a Connection Tracker

- Syntax for Connection Trackers

- Syntax for Connection Tracker Events

- Example: Excessive Connections From External Hosts

- Example: Excessive BitTorrent Data Transfers

Adding a Connection Tracker

License: FireSIGHT

A connection tracker constrains a correlation rule so that after its initial criteria are met (including host profile and user qualifications), the system begins tracking certain connections. The Defense Center generates a correlation event for the rule if the tracked connections meet additional criteria gathered over a time period that you specify.

When you configure a connection tracker, you must specify:

- which connections you want to track

- the conditions that the connections you are tracking must meet for the Defense Center to generate a correlation event

- the maximum duration of the connection tracker, that is, the time period during which the conditions you specify must be met to generate a correlation event

Tip You can add a connection tracker to a simple correlation rule that requires only that any connection, intrusion, discovery, user identity, or host input event occurs.

To add a connection tracker:

Access: Admin/Discovery Admin

Step 1 On the Create Rule page, click Add Connection Tracker.

The Connection Tracker section appears.

Tip To remove a connection tracker, click Remove Connection Tracker.

Step 2 Specify which connections you want to track by setting connection tracker criteria.

You can set connection tracker criteria by creating a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions.

See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions. The syntax you can use to build connection tracker conditions is described in Syntax for Connection Trackers.

Step 3 Based on the connections you decided to track in step 2, describe when you want to generate a correlation event.

You can create a single, simple condition that describes when you want to generate an event, or you can create more elaborate constructs by combining and nesting conditions.

You must also specify the interval (in seconds, minutes, or hours) during which the conditions you specify must be met to generate a correlation event.

See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions. The syntax you can use to build connection tracker conditions is described in Syntax for Connection Tracker Events.

Step 4 Optionally, continue with the procedures in the following sections:

- Adding a User Qualification

- Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Connection Trackers

License: Any

The following table describes how to build a connection tracker condition that specifies the kind of connections you want to track.

You should keep in mind that connections detected by Cisco managed devices and connection data exported by NetFlow-enabled devices contain different information. For example, connections detected by managed devices do not contain TCP flag information. Therefore, if you want to specify that a connection event have a certain TCP flag to trigger a correlation rule, none of the connections detected by managed devices will trigger the rule.

As another example, NetFlow records do not contain information about which host in the connection is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

Table 51-12 Syntax for Connection Trackers

If you specify...

Select an operator, then...

Access Control Policy

Select one or more access control policies that logged the connections you want to track.

Access Control Rule Action

Select one or more access control rule actions associated with the access control rule that logged the connections you want to track.
to track connections that match the conditions of any Monitor rule, regardless of the rule or default action that later handles the connections.

Access Control Rule Name

Type all or part of the name of the access control rule that logged the connections you want to track.

Note To track connections that match Monitor rules, type the name of the Monitor rule. The system tracks the connections, regardless of the rule or default action that later handles them.

Application Protocol

Select one or more application protocols.

Application Protocol Category

Select one or more application protocol categories.

Client

Select one or more clients.

Client Category

Select one or more client categories.

Client Version

Type the version of the client.

Connection Duration

Type the connection duration, in seconds.

Connection Type

Select whether you want to track connections based on how they were detected: by a Cisco managed device (FireSIGHT) or exported by a NetFlow-enabled device (NetFlow).

Destination Country or Source Country

Select one or more countries.

Device

Select one or more devices whose detected connections you want to track. If you want to track NetFlow connections, select the devices that process the connection data exported by your NetFlow-enabled devices.

Ingress Interface or

Egress Interface

Select one or more interfaces.

Ingress Security Zone or

Egress Security Zone

Select one or more security zones.

Initiator IP,

Responder IP, or

Initiator/Responder IP

Type a single IP address or address block. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Initiator Bytes,

Responder Bytes, or

Total Bytes

Type one of:

- the number of bytes transmitted ( Initiator Bytes )

- the number of bytes received ( Responder Bytes )

- the number of bytes both transmitted and received ( Total Bytes )

Initiator Packets,

Responder Packets, or

Total Packets

Type one of:

- the number of packets transmitted ( Initiator Packets )

- the number of packets received ( Responder Packets )

- the number of packets both transmitted and received ( Total Packets )

Initiator Port/ICMP Type or Responder Port/ICMP Code

Type the port number or ICMP type for initiator traffic or the port number or ICMP code for responder traffic.

IOC Tag

Select whether an IOC tag is or is not set.

NETBIOS Name

Type the NetBIOS name of the monitored host in the connection.

NetFlow Device

Select the IP address of the NetFlow-enabled device that exported the connections you want to track. If you did not add any NetFlow-enabled devices to your deployment, the NetFlow Device drop-down list is blank.

Reason

Select one or more reasons associated with the connections you want to track.

Security Intelligence Category

Select one or more Security Intelligence categories associated with the connections you want to track.

TCP Flags

Select the TCP flag that connections must contain in order to track them.

Note Only connections exported by NetFlow-enabled devices contain TCP flag data.

Transport Protocol

Type the transport protocol used by the connection: TCP or UDP.

URL

Type all or part of the URL visited in the connections you want to track.

URL Category

Select one or more URL categories for the URL visited in the connections you want to track.

URL Reputation

Select one or more URL reputation values for the URL visited in the connections you want to track

Username

Type the username of the user logged into either host in the connections you want to track.

Web Application

Select one or more web applications.

Web Application Category

Select one or more web application categories.

Syntax for Connection Tracker Events

License: Any

The following table describes how to how to build a connection tracker condition that specifies when you want to generate a correlation event based on the connections you are tracking.

Table 51-13 Syntax for Connection Tracker Events

If you specify...

Select an operator, then...

Number of Connections

Type the total number of connections detected.

Number of SSL Encrypted Sessions

Type the total number of SSL- or TLS-encrypted sessions detected.

Total Bytes,

Initiator Bytes, or

Responder Bytes

Type one of:

- the total bytes transmitted ( Total Bytes )

- the number of bytes transmitted ( Initiator Bytes )

- the number of bytes received ( Responder Bytes )

Total Packets,

Initiator Packets, or

Responder Packets

Type one of:

- the total packets transmitted ( Total Packets )

- the number of packets transmitted ( Initiator Packets )

- the number of packets received ( Responder Packets )

Unique Initiators or

Unique Responders

Type one of:

- the number of unique hosts that initiated sessions that were detected ( Unique Initiators )

- the number of unique hosts that responded to connections that were detected ( Unique Responders )

Example: Excessive Connections From External Hosts

Consider a scenario where you archive sensitive files on network 10.1.0.0/16, and where hosts outside this network typically do not initiate connections to hosts inside the network. An occasional connection initiated from outside the network might occur, but you have determined that when four or more connections are initiated within two minutes, there is cause for concern.

In this example, the system detected a connection that met the basic conditions of the correlation rule, that is, the system detected a connection from a host outside the 10.1.0.0/16 network to a host inside the network. This created a connection tracker.

The connection tracker is processed in the following stages:

Step 1 The system starts tracking connections when it detects a connection from Host A outside the network to Host 1 inside the network.

Step 2 The system detects two more connections that match the connection tracker signature: Host B to Host 2 and Host C to Host 1.

Step 3 The system detects a fourth qualifying connection when Host A connects to Host 3 within the two-minute time limit. The rule conditions are met.

Step 4 The Defense Center generates a correlation event and the system stops tracking connections.

Example: Excessive BitTorrent Data Transfers

Consider a scenario where you want to generate a correlation event if the system detects excessive BitTorrent data transfers after an initial connection to any host on your monitored network.

The following graphic shows a correlation rule that triggers when the system detects the BitTorrent application protocol on your monitored network. The rule has a connection tracker that constrains the rule so that the rule triggers only if hosts on your monitored network (in this example, 10.1.0.0/16) collectively transfer more than 7MB of data (7340032 bytes) via BitTorrent in the five minutes following the initial policy violation.

In this example, the system detected the BitTorrent TCP application protocol on two different hosts: Host 1 and Host 2. These two hosts transmitted data via BitTorrent to four other hosts: Host A, Host B, Host C, and Host D.

This connection tracker is processed in the following stages:

Step 1 The system starts tracking connections at the 0-second marker when the system detects the BitTorrent application protocol on Host 1.

Note that the connection tracker will expire if the system does not detect 7MB of BitTorrent TCP data being transmitted in the next 5 minutes (by the 300-second marker).

Step 2 At 5 seconds, Host 1 has transmitted 3MB of data that matches the signature:

- 1MB from Host 1 to Host A, at the 1-second marker (1MB total BitTorrent traffic counted towards fulfilling the connection tracker)

- 2MB from Host 1 to Host B, at the 5-second marker (3MB total)

Step 3 At 7 seconds, the system detects the BitTorrent application protocol on Host 2 and starts tracking BitTorrent connections for that host as well.

Step 4 At 20 seconds, the system has detected additional data matching the signature being transmitted from both Host 1 and Host 2:

- 1MB from Host 2 to Host A, at the 10-second marker (4MB total)

- 2MB from Host 1 to Host C, at the 15-second marker (6MB total)

- 1MB from Host 2 to Host B, at the 20-second marker (7MB total)

Although Host 1 and Host 2 have now transmitted a combined 7MB of BitTorrent data, the rule does not trigger because the total number of bytes transmitted must be more than 7MB (Responder Bytes are greater than 7340032).

At this point, if the system were to detect no additional BitTorrent transfers for the remaining 280 seconds in the tracker’s timeout period, the tracker would expire and the Defense Center would not generate a correlation event.

Step 5 However, at 30 seconds, the system detects another BitTorrent transfer:

- 2MB from Host 1 to Host D at the 30-second marker (9MB total)

The rule conditions are met.

Step 6 The Defense Center generates a correlation event.

The Defense Center also stops tracking connections for this connection tracker instance, even though the 5-minute period has not expired. If the system detects a new connection using the BitTorrent TCP application protocol at this point, it will create a new connection tracker.

Note that the Defense Center generates the correlation event after Host 1 transmits the entire 2MB to Host D, because it does not tally connection data until the session terminates.

Adding a User Qualification

License: FireSIGHT

If you are using a connection, intrusion, discovery, or host input event to trigger your correlation rule, you can constrain the rule based on the identity of a user involved in the event. This constraint is called a user qualification. You cannot add a user qualification to a correlation rule that triggers on a traffic profile change or on the detection of user activity.

For example, you could constrain a correlation rule so that it triggers only when the identity of the source or destination user is one from the sales department.

To add a user identity qualification:

Access: Admin/Discovery Admin

Step 1 On the Create Rule page, click Add User Qualification.

The User Identity Qualification section appears.

Tip To remove a user qualification, click Remove User Qualification.

Step 2 Build the user qualification’s conditions.

You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions.

The syntax you can use to build conditions is described in Syntax for User Qualifications.

Step 3 Optionally, continue with Adding Snooze and Inactive Periods.

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for User Qualifications

License: FireSIGHT

When you build a user qualification condition, you must first select the identity you want to use to constrain your correlation rule. The identity you can choose depends on the type of event you are using to trigger the rule, as follows:

- If you are using a connection event, select Identity on Initiator or Identity on Responder .

- If you are using an intrusion event, select Identity on Destination or Identity on Source .

- If you are using a discovery event, select Identity on Host .

- If you are using a host input event, select Identity on Host .

After you select the user type, you continue building your user qualification condition, as described in the following table.

The Defense Center obtains certain information about users, including first and last names, department, telephone number, and email address, from an optional Defense Center-LDAP server connection; see Using User Agents to Report Active Directory Logins. This information may not be available for all users in the database.

Table 51-14 Syntax for User Qualifications

If you specify...

Select an operator, then...

Username

Type the username of the user you want to use to constrain the correlation rule.

Authentication Protocol

Select an authentication protocol (or user type) protocol. This is the protocol that was used to detect the user.

First Name

Type the first name of the user you want to use to constrain the correlation rule.

Last Name

Type the last name of the user you want to use to constrain the correlation rule.

Department

Type the department of the user you want to use to constrain the correlation rule.

Phone

Type the telephone number of the user you want to use to constrain the correlation rule.

Email

Type the email address of the user you want to use to constrain the correlation rule.

Adding Snooze and Inactive Periods

License: Any

You can configure snooze periods in correlation rules. When a correlation rule triggers, a snooze period instructs the Defense Center to stop firing that rule for a specified interval, even if the rule is violated again during the interval. When the snooze period has elapsed, the rule can trigger again (and start a new snooze period).

For example, you may have a host on your network that should never generate traffic. A simple correlation rule that triggers whenever the system detects a connection involving that host may create multiple correlation events in a short period of time, depending on the network traffic to and from the host. To limit the number of correlation events exposing your policy violation, you can add a snooze period so that the Defense Center generates a correlation event only for the first connection (within a time period that you specify) that the system detects involving that host.

You can also set up inactive periods in correlation rules. During inactive periods, the correlation rule will not trigger. You can set up inactive periods to recur daily, weekly, or monthly. For example, you might perform a nightly Nmap scan on your internal network to look for host operating system changes. In that case, you could set a daily inactive period on the affected correlation rules for the time and duration of your scan so that those rules do not trigger erroneously.

The following graphic shows a portion of a correlation rule that is configured with a snooze period and an inactive period.

To add a snooze period:

Access: Admin/Discovery Admin

Step 1 On the Create Profile page, under Rule Options, specify the interval that the Defense Center should wait to trigger a rule again, after the rule triggers.

Tip To remove a snooze period, specify an interval of 0 (seconds, minutes, or hours).

To add an inactive period:

Access: Admin/Discovery Admin

Step 1 On the Create Profile page, under Rule Options, click Add Inactive Period.

Step 2 Using the drop-down lists and text field, specify when and how often you want the Defense Center to refrain from evaluating network traffic against the correlation rule.

When you are finished adding snooze and inactive periods, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Understanding Rule Building Mechanics

License: Any

You build correlation rules, connection trackers, user qualifications, and host profile qualifications by specifying the conditions under which they trigger. You can create simple conditions, or you can create more elaborate constructs by combining and nesting conditions.

Caution Evaluating complex correlation rules that trigger on frequently occurring events can degrade Defense Center performance. For example, a multi-condition rule that the Defense Center must evaluate against every connection logged by the system can cause resource overload.

For more information on condition building, see:

- Building a Single Condition

- Adding and Linking Conditions

- Using Multiple Values in a Condition

Building a Single Condition

License: Any

Most conditions have three parts: a category, an operator, and a value; some conditions are more complex and contain several categories, each of which may have their own operators and values.

For example, the following correlation rule triggers if a new host is detected on the 10.4.x.x network. The category of the condition is IP Address, the operator is is in, and the value is 10.4.0.0/16.

To build the correlation rule trigger criteria in the example above:

Access: Admin/Discovery Admin

Step 1 Begin building a correlation rule.

For more information, see Creating Rules for Correlation Policies.

Step 2 On the Create Rule page, under Select the type of event for this rule, select a discovery event occurs, then select a new IP host is detected from the drop-down list.

Step 3 Start building the rule’s single condition by selecting IP Address from the first (or category) drop-down list.

Step 4 Select is in from the operator drop-down list that appears.

Tip When the category represents an IP address, choosing is in or is not in as the operator allows you to specify whether the IP address is in or is not in a block of IP addresses, as expressed in special notation such as CIDR. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Step 5 Type 10.4.0.0/16 in the text field.

To build the host profile qualification in the example above:

Access: Admin/Discovery Admin

Step 1 Build a correlation rule that triggers on an discovery event.

For more information, see Creating Rules for Correlation Policies.

Step 2 On the Create Rule page, click Add Host Profile Qualification.

The Host Profile Qualification section appears.

Step 3 Under Host Profile Qualification, in the first condition, specify the host whose host profile you want to use to constrain your correlation rule.

Because this host profile qualification is part of a correlation rule based on an discovery event, the only available category is Host.

Step 4 Begin specifying the details of the operating system of the host by choosing the Operating System category.

Three subcategories appear: OS Vendor, OS Name, and OS Version.

Step 5 To specify that the host can be running any version of Microsoft Windows, use the same operator for all three subcategories: is.

Step 6 Finally, specify the values for the subcategories.

Select Microsoft as the value for OS Vendor, Windows as the value for OS Name, and leave any as the value for OS Version.

Note that the categories you can choose from depend on whether you are building correlation rule triggers, a host profile qualification, a connection tracker, or a user qualification. Within correlation rule triggers, the categories further depend on what kind of event is the basis for your correlation rule.

In addition, a condition’s available operators depend on the category you choose. Finally, the syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you must type the value in a text field. Other times, you can pick a value from a drop-down list.

Note Where the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For more information, see Using Multiple Values in a Condition.

For more information on the syntax for building correlation rule trigger criteria, see:

- Syntax for Intrusion Events

- Syntax for Malware Events

- Syntax for Discovery Events

- Syntax for User Activity Events

- Syntax for Host Input Events

- Syntax for Connection Events

- Syntax for Traffic Profile Changes

For more information on the syntax for building host profile qualifications, user qualifications, and connection trackers, see:

- Syntax for Host Profile Qualifications

- Syntax for Connection Trackers

- Syntax for Connection Tracker Events

- Syntax for User Qualifications

Adding and Linking Conditions

License: Any

You can create simple correlation rule triggers, connection trackers, host profile qualifications, and user qualifications, or you can create more elaborate constructs by combining and nesting conditions.

When your construct includes more than one condition, you must link them with an AND or an OR operator. Conditions on the same level are evaluated together:

- The AND operator requires that all conditions on the level it controls must be met.

- The OR operator requires that at least one of the conditions on the level it controls must be met.

For example, the following correlation rule trigger criteria contains two conditions, linked by OR. This means that the rule triggers if either condition is true, that is, if a host with an IP address is not in the 10.x.x.x subnet or if a host transmits an IGMP message.

This rule triggers if SSH is detected on a non-standard port; the first two conditions demand that the application protocol name is SSH and the port is not 22. The rule further requires that the IP address of the host involved in the event is in either the 10.4.x.x network or the 192.168.x.x network.

Logically, the rule is evaluated as follows:

(A and B and (C or D))

Table 51-15 Rule Evaluation

Where...

Is the condition that states...

A

Application Protocol is SSH

B

Application Port is not 22

C

IP Address is in 10.4.0.0/8

D

IP Address is in 196.168.0.0/16

To add a single condition:

Access: Admin/Discovery Admin

Step 1 To add a single condition, click Add condition above the current condition.

A new condition is added below the current set of conditions, on the same level as the current set of conditions. By default, it is linked to the conditions on the same level with the OR operator, though you can change the operator to AND.

For example, if you add a simple condition to the following rule:

To add a complex condition:

Access: Admin/Discovery Admin

Step 1 Click Add complex condition above the current condition.

A complex condition is added below the current set of conditions. The complex condition comprises two subconditions, which are linked to each other with the opposite operator from the one used to link the conditions on the level above it.

For example, if you add a complex condition to the following rule:

To link conditions:

Access: Admin/Discovery Admin

Step 1 Use the drop-down list to the left of a set of conditions. Choose:

- the AND operator to require that all conditions on the level it controls be met

- the OR operator to require that only one of the conditions on the level it controls be met

Using Multiple Values in a Condition

License: Any

When you are building a condition, and the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For example, if you want to add a host profile qualification to a rule that requires that a host be running some flavor of UNIX, instead of constructing multiple conditions linked with the OR operator, use the following procedure.

To include multiple values in one condition:

Access: Admin/Discovery Admin

Step 1 Build a condition, choosing is in or is not in as the operator.

The drop-down list changes to a text field.

Step 2 Click anywhere in the text field or on the Edit link.

A pop-up window appears.

Step 3 Under Available, use Ctrl or Shift while clicking to select multiple values. You can also click and drag to select multiple adjacent values.

Step 4 Click the right arrow (>) to move the selected entries to Selected.

Step 5 Click OK.

The Create Rule page appears again. Your selections appear in the value field of your condition.

Managing Rules for Correlation Policies

License: Any

Use the Rule Management page to manage correlation rules used within correlation policies. You can create, modify, and delete rules. You can also create rule groups to help you organize correlation rules. For more information on modifying rules, deleting rules, and creating rule groups, see:

- Modifying a Rule

- Deleting a Rule

- Creating a Rule Group

For more information on creating rules, see Creating Rules for Correlation Policies.

Modifying a Rule

License: Any

Use the following procedure to modify an existing correlation rule.

To modify an existing rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 If the rule is in a rule group, click the group name to expand the group.

).

The Create Rule page appears.

Step 4 Make modifications as necessary and click Save.

The rule is updated.

Deleting a Rule

License: Any

You cannot delete correlation rules that you are using in one or more correlation policies; you must first delete the rule from all policies in which it is included. For information on deleting a rule from a policy, see Editing a Correlation Policy.

To delete an existing rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 If the rule is in a rule group, click the group name to expand the group.

).

Step 4 Confirm that you want to delete the rule.

The rule is deleted.

Creating a Rule Group

License: Any

Create rule groups to help you organize correlation rules. The FireSIGHT System ships with many default rules, which are grouped according to function. For example, the Worms rule group comprises rules that detect activity by common worms. Note that rule groups exist only to help you organize correlation rules; you cannot assign a group of rules to a correlation policy. Instead, add each rule individually.

You can add a rule to an existing group when you create the rule. You can also modify an existing rule to add it to a group. For more information, see the following sections:

- Creating Rules for Correlation Policies

- Modifying a Rule

To create a rule group:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Group.

The Create Group page appears.

Step 3 In the Group Name field, type a name for the group.

Step 4 Click Add Group.

The group is added.

Grouping Correlation Responses

License: Any

After you create alert responses and remediations, (see Working with Alert Responses and Creating Remediations), you can group them so that a policy violation triggers all of the responses within the group. Before you can assign response groups to correlation rules, you must create the groups on the Groups page.

The slider next to the group indicates whether the group is active. If you want to assign a response group to a rule within a correlation policy, you must activate it. You can sort response groups by state (active versus inactive) or alphabetically by name using the Sort by drop-down list.

See the following sections for more information:

- Creating a Response Group

- Modifying a Response Group

- Deleting a Response Group

- Activating and Deactivating Response Groups

Creating a Response Group

License: Any

You can place individual alerts and remediations in response groups, which can then be assigned to rules within correlation policies so that a group of alerts and remediations can be launched when a policy is violated. After a group has been assigned to rules in active policies, changes to the group and to alerts or remediations within the group are automatically applied to active policies.

To create a response group:

Access: Admin

Step 1 Select Policies > Correlation, then click Groups.

The Groups page appears.

Step 2 Click Create Group.

The Response Group page appears.

Step 3 In the Name field, type a name for the new group.

Step 4 Select Active to activate the group so that you can use it in response to a correlation policy violation.

Step 5 From the Available Responses list, select the alerts and remediations you want to include in the group.

Tip Hold down the Ctrl key while clicking to select multiple responses.

Step 6 Click > to move alerts and remediations into the group.

Conversely, you can select alerts and remediations from the Responses in Group list and click < to move the alerts out of the response group.

Step 7 Click Save.

The group is created.

Modifying a Response Group

License: Any

Use the following procedure to modify a response group.

To modify a response group:

Access: Admin

Step 1 Select Policies > Correlation, then click Groups.

The Groups page appears.

) next to the group you want to modify.

The Response Group page appears.

Step 3 Make changes as needed and click Save.

If the group is active and in use, the changes you made take effect immediately.

Deleting a Response Group

License: Any

You can delete a response group if it is not used in a correlation policy. Deleting a response group does not delete the responses in the group, just their association with each other.

To delete a response group:

Access: Admin

Step 1 Select Policies > Correlation, then click Groups.

The Groups page appears.

) next to the group you want to delete.

Step 3 Confirm that you want to delete the group.

The group is deleted.

Activating and Deactivating Response Groups

License: Any

You can temporarily deactivate a response group without deleting it. This leaves the group on the system but does not launch it when a policy to which the group is assigned is violated. Note that if a response group is used in a correlation policy when you deactivate it, it is still considered in use even though it is deactivated; you cannot delete in-use response groups.

To activate or deactivate a response group:

Access: Admin

Step 1 Select Policies > Correlation, then click Groups.

The Groups page appears.

Step 2 Next to the response group you want to activate or deactivate, click the slider.

If the group was activated, it is deactivated. If it was deactivated, it is activated.

Creating Correlation Policies

License: Any

After you create correlation rules or compliance white lists (or both), and, optionally, alert responses and remediations, you can use them to build correlation policies.

When your network traffic meets the criteria specified in a correlation rule or white list in an active policy, the Defense Center generates either a correlation event or white list event. It also launches any responses you assigned to the rule or white list. You can map each rule or white list to a single response or to a group of responses. If the network traffic triggers multiple rules or white lists, the Defense Center launches all the responses associated with each rule and white list.

For more information on creating the correlation rules, compliance white lists, and responses you can use to build a correlation policy, see the following sections:

- Creating Rules for Correlation Policies

- Creating Compliance White Lists

- Configuring External Alerting

- Configuring Remediations

Tip Optionally, create a skeleton policy and modify it later to add rules and responses.

To create a correlation policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation.

The Policy Management page appears.

Step 2 Click Create Policy.

The Create Policy page appears.

Step 3 Provide basic policy information, such as the name and description.

See Providing Basic Policy Information.

Step 4 Add one or more rules or white lists to the correlation policy.

See Adding Rules and White Lists to a Correlation Policy.

Step 5 Optionally, set rule and white list priorities.

See Setting Rule and White List Priorities.

Step 6 Optionally, add responses to the rules or white lists you added.

See Adding Responses to Rules and White Lists.

Step 7 Click Save.

The policy is saved.

Note You must activate the policy before it can generate correlation and white list events and launch responses to policy violations. For more information, see Managing Correlation Policies.

Providing Basic Policy Information

License: Any

You must give each policy an identifying name. Optionally, you can add a short description to the policy.

You can also assign a user-defined priority to your policy. If your correlation policy is violated, the resultant correlation events display the priority value you assign to the policy (unless the rule that was triggered has its own priority).

Note Rule and white list priorities override policy priorities. For more information, see Adding Rules and White Lists to a Correlation Policy.

To provide basic policy information:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, in the Policy Name field, type a name for the policy.

Step 2 In the Policy Description field, type a description for the policy.

Step 3 From the Default Priority drop-down list, select a priority for the policy.

You can select a priority value from 1 to 5, where 1 is highest and 5 is lowest. Or, you can select None to only use the priorities assigned to specific rules.

Step 4 Continue with the procedure in the next section, Adding Rules and White Lists to a Correlation Policy.

Adding Rules and White Lists to a Correlation Policy

License: Any

A correlation policy contains one or more correlation rules or white lists. When any rule or white list in a policy is violated, the system logs an event to the database. If you assigned one or more responses to the rule or white list, those responses are launched.

The following graphic shows a correlation policy composed of a compliance white list and a set of correlation rules, configured with a variety of responses.

z

To add rules or white lists to a correlation policy:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, click Add Rules.

The Available Rules pop-up appears.

Step 2 Click the appropriate folder name to expand it.

Step 3 Select the rules and white lists that you want to use in the policy and click Add.

The Create Policy page appears again. The rules and white lists you selected populate the policy.

Step 4 Continue with the procedure in the next section, Setting Rule and White List Priorities.

Setting Rule and White List Priorities

License: Any

You can assign a user-defined priority to each correlation rule or compliance white list in your correlation policy. If a rule or white list triggers, the resulting event displays the priority you assign to the rule or white list. On the other hand, if you do not assign a priority value and the rule or white list triggers, the resulting event displays the priority value of the policy.

For example, consider a policy where the policy itself has a priority of 1 and its rules or white lists are set with the default priority, with the exception of one rule given a priority of 3. If the priority 3 rule triggers, the resulting correlation event shows 3 as its priority value. If other rules or white lists in the policy trigger, the resulting events show 1 as their priority values, retained from the policy’s priority.

To set rule or white list priorities:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, from the Priority list for each rule or white list, select a default priority. You can select:

- a priority value from 1 to 5, where 1 is highest and 5 is lowest

- None

- Default to use the policy’s default priority

Step 2 Continue with the procedure in the next section, Adding Responses to Rules and White Lists.

Adding Responses to Rules and White Lists

License: Any

Within a correlation policy, you can map each rule or white list to a single response or to a group of responses. When any one of the rules or white lists in a policy is violated, the system logs an associated event to the database and launches the responses assigned to that rule or white list. If multiple rules or white lists within a policy trigger, the Defense Center launches the responses associated with each rule or white list.

For more information on creating responses and response groups, see:

- Configuring External Alerting

- Configuring Remediations

- Grouping Correlation Responses

Note Do not assign an Nmap remediation as a response to a correlation rule that triggers on a traffic profile change. The remediation will not launch.

The following graphic shows a correlation policy composed of a compliance white list and a set of correlation rules, configured with a variety of responses.

z

To add responses to rules and white lists:

Access: Admin/Discovery Admin

).

A pop-up window appears.

Step 2 Under Unassigned Responses, select the response, multiple responses, or response group you want to launch when the rule or white list triggers, and click the up arrow.

Tip Hold down the Ctrl key while clicking to select multiple responses.

Step 3 Click Update.

The Create Policy page appears again. The responses you specified are added to the rule or white list.

Managing Correlation Policies

License: Any

You manage correlation policies on the Policy Management page. You can create, modify, sort, activate, deactivate, and delete policies.

The slider next to the policy indicates whether the group is active. If you want the policy to generate correlation events and white list events, you must activate it. You can sort policies by state (active versus inactive) or alphabetically by name using the Sort by drop-down list.

If an active correlation policy contains a compliance white list, the following actions do not delete the host attribute associated with the white list, nor do they change that host attribute’s values:

- deactivating the policy

- modifying the policy to remove the white list

- deleting the policy

That is, hosts that were compliant when you performed the action still appear as compliant on the host attributes network map, and so on. To delete the host attribute, you must delete its corresponding white list.

To update the white list compliance of the hosts on your network, you must either reactivate the correlation policy (if you deactivated it) or add the white list to another active correlation policy (if you deleted the white list from a correlation policy or deleted the policy itself). Note that the reevaluation of the white list that occurs when you do this does not generate white list events and therefore does not trigger any responses you associated with the white list. For more information on compliance white lists, see Using the FireSIGHT System as a Compliance Tool.

For more information on managing correlation policies, see:

- Activating and Deactivating Correlation Policies

- Editing a Correlation Policy

- Deleting a Correlation Policy

For information on creating new policies, see Creating Correlation Policies.

Activating and Deactivating Correlation Policies

License: Any

Use the following procedure to either activate or deactivate a correlation policy.

To activate or deactivate a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation.

The Policy Management page appears.

Step 2 Next to the policy you want to activate or deactivate, click the slider.

If the policy was active, it is deactivated. If it was deactivated, it is activated.

Editing a Correlation Policy

License: Any

Use the following procedure to modify a correlation policy.

To edit a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation.

The Policy Management page appears.

) next to the policy.

) next to the rule or white list you want to remove.

Step 3 Make changes as needed and click Save.

The policy is changed. If the policy is active, the changes you made take effect immediately.

Deleting a Correlation Policy

License: Any

Use the following procedure to delete a correlation policy.

To delete a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation.

The Policy Management page appears.

) next to the policy you want to delete.

The policy is deleted.

Working with Correlation Events

License: Any

When a correlation rule within an active correlation policy triggers, the Defense Center generates a correlation event and logs it to the database. For information on configuring the number of correlation events saved in the database, see Configuring Database Event Limits.

Note When a compliance white list within an active correlation policy triggers, the Defense Center generates a white list event. For more information, see Working with White List Events.

For more information, see the following sections:

- Viewing Correlation Events

- Understanding the Correlation Events Table

- Searching for Correlation Events

Viewing Correlation Events

License: Any

You can view a table of correlation events, then manipulate the event view depending on the information you are looking for.

The page you see when you access correlation events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of correlation events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

To...

You can...

view the host profile for an IP address

click the host profile icon that appears next to the IP address.

view user profile information

) that appears next to the user identity. For more information, see Understanding User Details and Host History.

sort and constrain events on the current workflow page

find more information in Sorting Drill-Down Workflow Pages.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

learn more about the columns that appear

find more information in Understanding the Correlation Events Table.

modify the time and date range for displayed events

find more information in see Setting Event Time Constraints.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

drill down to the next page in the workflow, constraining on a specific value

use one of the following methods:

- on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some users, select the check boxes next to the users you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.

For more information, see Constraining Events.

delete correlation events from the system

use one of the following methods:

- To delete some events, select the check boxes next to the events you want to delete, then click Delete .

- To delete all events in the current constrained view, click Delete All , then confirm you want to delete all the events.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

To view correlation events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Correlation > Correlation Events.

The first page of the default correlation events workflow appears. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of correlation events, click (switch workflow), then select Correlation Events.

Understanding the Correlation Events Table

License: Any

When a correlation rule triggers, the Defense Center generates a correlation event. The fields in the correlation events table are described in the following table.

Table 51-17 Correlation Event Fields

Field

Description

Time

The date and time that the correlation event was generated.

Impact

The impact level assigned to the correlation event based on the correlation between intrusion data, discovery data, and vulnerability information. For more information, see Using Impact Levels to Evaluate Events.

Inline Result

One of:

- a black down arrow, indicating that the system dropped the packet that triggered the intrusion rule

- a gray down arrow, indicating that the system would have dropped the packet in an inline, switched, or routed deployment if you enabled the Drop when Inline intrusion policy option

- blank, indicating that the triggered intrusion rule was not set to Drop and Generate Events

Note that the system does not drop packets in a passive deployment, including when an inline set is in tap mode, regardless of the rule state or the drop behavior of the intrusion policy.

Source IP or

Destination IP

The IP address of the source or destination host in the event that triggered the policy violation.

Source Country or Destination Country

The country associated with the source or destination IP address in the event that triggered the policy violation.

Security Intelligence Category

The name of the blacklisted object that represents or contains the blacklisted IP address in the event that triggered the policy violation.

Source User or

Destination User

The name of the user logged in to the source or destination host in the event that triggered the policy violation.

Source Port/ICMP Type or Destination Port/ICMP Code

The source port or ICMP type for the source traffic or the destination port or ICMP code for destination traffic associated with the event that triggered the policy violation.

Description

The description of the correlation event. The information in the description depends on how the rule was triggered.

For example, if the rule was triggered by an operating system information update event, the new operating system name and confidence level appears.

Policy

The name of the policy that was violated.

Rule

The name of the rule that triggered the policy violation.

Priority

The priority specified by the policy or rule that triggered the policy violation.

Source Host Criticality or Destination Host Criticality

The user-assigned host criticality of the source or destination host involved in the correlation event: None, Low, Medium, or High.

Note that only correlation events generated by rules based on discovery events, host input events, or connection events contain a source host criticality. For more information on host criticality, see Working with the Predefined Host Attributes.

Ingress Security Zone or

Egress Security Zone

The ingress or egress security zone in the intrusion or connection event that triggered the policy violation.

Device

The name of the device that generated the event that triggered the policy violation.

Ingress Interface or

Egress Interface

The ingress or egress interface in the intrusion or connection event that triggered the policy violation.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

For more information on displaying the correlation events table, see the following:

- Viewing Correlation Events

- Searching for Correlation Events

Searching for Correlation Events

License: Any

Field

Search Criteria Rules

Policy

Type the name of the correlation policy you want to search for.

Rule

Type the name of the correlation rule you want to search for.

Description

Type all or part of the correlation event description. The information in the description depends on the event that caused the rule to trigger.

Priority

Specify the priority of the correlation event, which is determined by the priority of either the triggered rule or the violated correlation policy. Enter none for no priority. For information on setting correlation rule and policy priorities, see Providing Basic Policy Information and Setting Rule and White List Priorities.

Source Country,

Destination Country, or

Source/Destination Country

Specify the country associated with the source, destination, or source or destination host IP addresses in the event that triggered the policy violation.

Source Continent,

Destination Continent, or

Source/Destination Continent

Specify the continent associated with the source, destination, or source or destination host IP addresses in the event that triggered the policy violation.

Security Intelligence Category

Specify the Security Intelligence category associated with the correlation event that triggered the policy violation. The Security Intelligence category can be the name of a Security Intelligence object, the global blacklist, a custom Security Intelligence list or feed, or one of the categories in the Intelligence Feed. For more information, see Blacklisting Using Security Intelligence IP Address Reputation.

Source IP,

Destination IP, or

Source/Destination IP

Specify the IP address of the source, destination, or source or destination hosts in the event that triggered the policy violation. You can specify a single IP address or address block, or a comma-separated list of either or both. You can also use negation. See Specifying IP Addresses in Searches for more information.

Source User or

Destination User

Specify the user logged in to the source or destination host in the event that triggered the policy violation.

Source Port/ICMP Type or

Destination Port/ICMP Code

Specify the source port or ICMP type for source traffic or destination port or ICMP code for destination traffic associated with the event that triggered the policy violation.

Impact

Specify the impact assigned to the correlation event. Valid case-insensitive values are Impact 0, Impact Level 0, Impact 1, Impact Level 1, Impact 2, Impact Level 2, Impact 3, Impact Level 3, Impact 4, and Impact Level 4. Do not use impact icon colors or partial strings (for example, do not use blue, level 1, or 0). For more information, see Using Impact Levels to Evaluate Events.

Inline Result

For policy violations triggered by intrusion events, type either:

- dropped , to specify whether the packet was dropped in an inline, switched, or routed deployment

- would have dropped , to specify whether the packet would have dropped if the intrusion policy had been set to drop packets in an inline, switched, or routed deployment

Note that the system does not drop packets in a passive deployment, including when an inline set is in tap mode, regardless of the rule state or the drop behavior of the intrusion policy.

Source Host Criticality or

Destination Host Criticality

Specify the host criticality of the source or destination host involved in the policy violation: None, Low, Medium, or High. Note that only correlation events generated by rules based on discovery events, host input events, or connection events contain a source host criticality. For more information on host criticality, see Working with the Predefined Host Attributes.

Ingress Security Zone,

Egress Security Zone, or

Ingress/Egress Security Zone

Specify the ingress, egress, or ingress or egress security zone in the intrusion or connection event that triggered the policy violation.

Device

Type the device name or IP address, or a device group, stack, or cluster name to restrict the search to specific devices that generated events that triggered a policy violation. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

Ingress Interface or

Egress Interface

Specify the ingress or egress interface in the intrusion or connection event that triggered the policy violation.

To search for correlation events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Correlation Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in the Correlation Event Search Criteria table:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For more information on search syntax, including using objects in searches, see Searching for Events.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default correlation events workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Using the FireSIGHT System as a Compliance Tool

A compliance white list (or white list) is a set of criteria that allows you to specify the operating systems, applications, and protocols that are allowed to run on a specific subnet, and automatically generate an event if a host on the subnet violates the white list. For example, your security policy might state that while your web servers are allowed to run HTTP, none of the other hosts on your network are. You could create a white list that evaluates your entire network, excluding your web farm, to determine which hosts are running HTTP.

Note that you could create a correlation rule that performs this function by configuring the rule so that it triggers when:

- the system discovers new information about an application protocol

- the application protocol name is http

- the IP address of the host involved in the event is not in your web farm

However, correlation rules, which provide you with a more flexible way of alerting you and responding to policy violations on your network, are more complex to configure and maintain than white lists. Correlation rules are also wider in scope, allowing you to generate a correlation event when one of many types of event meets any criteria that you specify. On the other hand, white lists are specifically meant to help you evaluate the operating systems, application protocols, clients, web applications, and protocols that are running on your network and whether that violates your organization’s policies.

You can create custom white lists that meet your specific needs, or you can use the default white list created by the Cisco Vulnerability Research Team (VRT) that contains recommended settings for allowed operating systems, application protocols, clients, web applications, and protocols. You may also want to customize the default white list for your network environment.

If you add a white list to an active correlation policy, when the system detects that a host is violating the white list, the system logs a white list event — which is a special kind of correlation event — to the database. Further, you can configure the system to trigger responses (remediations and alerts) automatically when it detects a white list violation.

Note Although you can configure the network discovery policy to add hosts and application protocols to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts and application protocols is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. This may affect the way you build compliance white lists. For more information, see Differences Between NetFlow and FireSIGHT Data.

Because the system creates a host attribute for each host that indicates whether it is in compliance with any white lists you create, you can obtain an at-a-glance summary of the compliance of your network. In just a few seconds, you can determine exactly which hosts in your organization are running HTTP in violation of your policy, and take appropriate action.

Then, using the correlation feature, you can configure the system to alert you whenever a host that is not in your web farm starts running HTTP.

In addition, the system allows you to use host profiles to determine whether an individual host is violating any of the white lists you have configured, and in which way it is violating the white list. The FireSIGHT System also includes workflows that allow you to view each of the individual white list violations, as well as the number of violations per host.

Finally, you can use the dashboard to monitor recent system-wide compliance activity, including white list events and summary views of the overall white list compliance of your network.

For more information on creating and managing compliance white lists and on interpreting white list events and violations, see the following sections:

- Understanding Compliance White Lists

- Creating Compliance White Lists

- Managing Compliance White Lists

- Working with Shared Host Profiles

- Working with White List Events

- Working with White List Violations

In addition, see the following chapters and sections for more information:

- Creating Correlation Policies explains how to create and configure correlation policies that include compliance white lists, and explains how to assign responses and priorities to the white lists.

- Using Host Profiles explains how to use a host’s profile to determine whether it is violating any white lists.

- Using Dashboards explains how to obtain an at-a-glance view of your current system status, including white list compliance activity.

Understanding Compliance White Lists

License: FireSIGHT

A compliance white list is a set of criteria that specify the operating systems, clients, application protocols, web applications, and protocols that are allowed to run on your network. You can create custom white lists that meet your specific needs, or you can use the default white list created by the VRT that contains recommended settings.

Custom white list criteria can be simple; you can specify that only hosts running a certain operating system are allowed. Your criteria can also be complex; you can specify that while all operating systems are allowed, only hosts running a certain operating system are allowed to run a certain application protocol on a specific port.

White lists comprise two main parts: targets and host profiles. The targets are the specific hosts that are evaluated by the white list, while the host profiles specify the operating systems, clients, application protocols, web applications, and protocols that are allowed to run on the targets.

After you create a white list and add it to an active correlation policy, the system evaluates the white list’s targets against its host profiles to determine whether the targets are in compliance with the white list. After this initial evaluation, the system generates a white list event when it detects that a valid target is violating the white list.

For more information, see the following sections:

- Understanding White List Targets explains how white lists only target the hosts that you specify.

- Understanding White List Host Profiles explains the different kinds of profiles that describe which clients, application protocols, web applications, and protocols are allowed to run on your network.

- Understanding White List Evaluations explains how the system evaluates the hosts on your network against white lists, and how you can tell which hosts are in compliance and which are not.

- Understanding White List Violations explains how the system detects and notifies you of white list violations.

Understanding White List Targets

License: FireSIGHT

When you create a white list, you first specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual hosts. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a valid target (or target). A valid target:

- must be in one of the IP address blocks you specify. You can also exclude blocks of IP addresses.

- must have at least one of the host attributes you specify.

For example, you could configure a white list to evaluate only hosts that have a high host criticality. For information on host attributes, including host criticality, see Working with User-Defined Host Attributes and Working with the Predefined Host Attributes.

- must belong to one of the VLANs you specify.

If a host does not meet all of these criteria, it is not evaluated against the white list, regardless of whether its host profile is in violation of the white list.

If your white list contains more than one target, a host must meet the criteria specified in only one of them to be considered valid. For example, if you create a target that includes the 10.10.x.x network and one that excludes the 10.10.x.x network, a host in that network is considered a valid target. Note that if your white list does not contain any targets, none of the hosts on your network will be evaluated against the white list.

The target networks for your white list are listed on the left of the Create White List page. Note that the default white list uses targets of 0.0.0.0/0 and ::/0, which represent the entire monitored network. If you choose to use this white list, you can leave the target network as-is or modify it to reflect your network environment.

For information on creating white list targets, see Configuring Compliance White List Targets.

Understanding White List Host Profiles

License: FireSIGHT

After you specify which targets the white list evaluates, the next step is to configure host profiles. Host profiles in a white list specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts.

There are three kinds of host profiles you can configure in a white list: global host profiles, host profiles for specific operating systems, and shared host profiles. Each type of host profile appears differently when you are creating a white list.

To view...

Under Allowed Host Profiles, click...

the global host profile for the white list

Any Operating System

a host profile for a specific operating system

a host profile name that is listed in plain text rather than italics

a shared host profile used by the white list

a host profile name that is listed in italics

For more information, see the following sections:

- Understanding the Global Host Profile

- Understanding Host Profiles for Specific Operating Systems

- Understanding Shared Host Profiles

Understanding the Global Host Profile

License: FireSIGHT

Every white list contains a global host profile, which specifies the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system.

For example, instead of editing multiple Microsoft Windows and Linux host profiles to allow Internet Explorer, you can configure the global host profile to allow it regardless of the operating system on which it was detected. Note that the ARP, IP, TCP, and UDP protocols are always allowed to run on every host; you cannot disallow them. For more information, see Configuring the Global Host Profile.

Understanding Host Profiles for Specific Operating Systems

License: FireSIGHT

You must create one host profile for each operating system you want to allow on your network. To disallow an operating system on your network, do not create a host profile for that operating system. For example, to make sure that all the hosts on your network are running Microsoft Windows, configure the white list to only contain host profiles for that operating system.

When you create a host profile for an operating system, you can also require that it have a particular version. For example, you could require that compliant hosts run Windows 7 or Server 2008 R2.

After you create a host profile for a particular operating system, you can specify the application protocols, clients, web applications, and protocols that are allowed to run on target hosts running that operating system. For example, you could allow SSH to run on Linux hosts on port 22. You could also restrict the particular vendor and version to OpenSSH 4.2.

Note that unidentified hosts remain in compliance with all white lists until they are identified. You can, however, create a white list host profile for unknown hosts.

Note Unidentified hosts are not the same as unknown hosts. Unidentified hosts are hosts about which the system has not yet gathered enough information to identify their operating systems. Unknown hosts are hosts whose traffic has been analyzed by the system, but whose operating systems do not match any of the known fingerprints.

For more information, see Creating Host Profiles for Specific Operating Systems.

Understanding Shared Host Profiles

License: FireSIGHT

Shared host profiles are tied to specific operating systems, but you can use each shared host profile in more than one white list. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

For example, if you have offices worldwide and you want to create a separate white list for each location, but always want to use the same profile for all hosts running Apple Mac OS X, you can create a shared profile for that operating system and use it in all your white lists.

).

Built-in host profiles use built-in application protocols, protocols, and clients. You can use these elements as-is in both the default white list and in any custom white list that you create or you can modify them to suit your needs. They are displayed in italics within the built-in host profile and in any other host profile that uses them.

Keep in mind that like all shared host profiles, if you modify a built-in host profile, it affects every white list that uses it. Likewise, if you modify a built-in application protocol, protocol, or client, it affects every white list that uses it.

For more information on shared host profiles, Working with Shared Host Profiles.

Understanding White List Evaluations

License: FireSIGHT

After you create white list host profiles and save the white list, you can add the white list to a correlation policy, just as you would a correlation rule. For more information, see Configuring Correlation Policies and Rules.

After you activate the correlation policy, the system evaluates the targets of the white list against the white list criteria.You can then use the host attributes network map to gain an overall view of the white list compliance of the hosts on your network.

Every host on the network is assigned a host attribute that has the same name as the white list. This host attribute has one of the following values:

- Compliant , for valid targets that are compliant with the white list

- Non-Compliant , for valid targets that violate the white list

- Not Evaluated , for invalid targets and hosts that have not yet been evaluated for any reason

Note that if your network is large and the system is in the process of evaluating all the valid targets in the network map against the white list, targets that have not yet been evaluated are marked as Not Evaluated. As the system completes its processing, more hosts move from Not Evaluated to either Compliant or Non-Compliant. The system can evaluate approximately 100 hosts per second.

Additionally, a host may be marked as Not Evaluated if the system has insufficient information to determine whether the host is in compliance. For example, this may occur if the system has detected a new host but has not yet gathered relevant information on the operating system, clients, application protocols, web applications, or protocols running on the host.

Note If you change or delete a host attribute from a host and that change or deletion means that the host is no longer a valid target, the host changes from either Compliant or Non-Compliant to Not Evaluated.

For more information on host attributes, see Working with the Host Attributes Network Map.

Understanding White List Violations

License: FireSIGHT

After the initial white list evaluation, the system generates a white list event when it detects that a valid target is violating the white list. White list events are a special kind of correlation event, and are logged to the Defense Center correlation event database. You can view white list events in a workflow, or search for specific white list events. For more information, see Working with White List Events.

White list violations occur when the system generates an event that indicates that a host is out of compliance. Similarly, discovery events may indicate that a previously non-compliant host is now compliant, although the system does not generate a white list event when this occurs.

The following events can change the compliance of a host:

- the system detects a change in a host’s operating system

- the system detects an identity conflict for a host’s operating system or an application protocol on the host

- the system detects a new TCP server port (for example, a port used by SMTP or web servers) active on a host, or a new UDP server running on a host

- the system detects a change in a discovered TCP or UDP server running on a host, for example, a version change due to an upgrade

- the system detects a new client running on a host

- the system drops a client from its database due to inactivity

- the system detects a new web application running on a host

- the system drops a web application from a host profile due to inactivity

- the system detects that a host is communicating with a new network protocol, such as Novell Netware or IPv6, or a new transport protocol, such as ICMP or EGP

- the system detects a new mobile device that is jailbroken

- the system detects that a TCP or UDP port has closed or timed out on a host

In addition, you can trigger a compliance change for a host by using the host input feature or the host profile to:

- add a client, protocol, or server to a host

- delete a client, protocol, or server from a host

- set the operating system definition for a host

- change a host attribute for a host so that the host is no longer a valid target

For example, if your white list specifies that only Microsoft Windows hosts are allowed on your network, and the system detects that the host is now running Mac OS X, the system generates a white list event. In addition, the host attribute associated with the white list changes its value from Compliant to Non-Compliant for that host.

For the host in this example to come back into compliance, one of the following must occur:

- you edit the white list so that the Mac OS X operating system is allowed

- you manually change the operating system definition of the host to Microsoft Windows

- the system detects that the operating system has changed back to Microsoft Windows

In any case, the host attribute associated with the white list changes its value from Non-Compliant to Compliant for that host.

As another example, if your compliance white list disallows the use of FTP, and you then delete FTP from the application protocols network map or from an event view, hosts running FTP become compliant. However, if the system detects the application protocol again, the system generates a white list event and the hosts become non-compliant.

Note that if the system generates an event that contains insufficient information for the white list, the white list does not trigger. For example, consider a scenario where your white list specifies that you allow only TCP FTP traffic on port 21. Then, the system detects that port 21, using the TCP protocol, has become active on one of the white list targets, but the system is unable to determine whether the traffic is FTP. In this scenario, the white list does not trigger until either the system identifies the traffic as something other than FTP traffic or you use the host input feature to designate the traffic as non-FTP traffic.

Note During the initial evaluation of a white list, the system does not generate white list events for non-compliant hosts. If you want to generate white list events for all non-compliant targets, you must purge the Defense Center database. This causes the hosts on your network and their associated clients, application protocols, web applications, and protocols to be rediscovered, which may trigger white list events. For more information, see Purging Discovery Data from the Database.

Finally, you can configure the system to trigger responses automatically when it detects a white list violation. Responses include remediations (such as running an Nmap scan), alerts (email, SNMP, and syslog alerts), or combination of alerts and remediations. For more information, see Adding Responses to Rules and White Lists.

Creating Compliance White Lists

License: FireSIGHT

When you create a white list, you can survey either your entire network or a specific network segment. Surveying the network populates the white list with one host profile for each operating system that the system has detected on the network segment. By default, these host profiles allow all of the clients, application protocols, web applications, and protocols that the system has detected on the applicable operating systems.

Then, you must specify the targets of the white list. You can configure a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual hosts. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. If you surveyed your network, by default the network segment that you surveyed represents the white list targets. You can edit or delete the surveyed network, or you can add new targets.

Next, create host profiles that represent compliant hosts. Host profiles in a white list specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts. You can configure the global host profile, edit the host profiles created by any network survey your performed, as well as add new host profiles, and add and edit shared host profiles.

Finally, save the white list and add it to an active correlation policy. The system begins evaluating the target hosts for compliance, generating white list events when a host violates the white list, and triggering any responses you have configured to white list violations. For a more detailed introduction to compliance white lists, see Understanding Compliance White Lists.

Tip You can also create a white list from a table view of hosts. For more information, see Creating a Compliance White List Based on Selected Hosts.

To create a compliance white list:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click New White List.

The Survey Network page appears.

Step 3 Optionally, survey your network:

- To survey your network, see Surveying Your Network.

- To create a white list without surveying your network, click Skip and continue with the next step.

The Create White List page appears.

Step 4 In the Name field, type a name for the new white list.

Step 5 In the Description field, type a short description of the white list.

Step 6 To allow jailbroken mobile devices on your network, enable Allow Jailbroken Mobile Devices. To cause all jailbroken devices evaluated by the white list to generate a white list violation, disable the option.

Step 7 Specify the targets for the white list. You can edit or delete the targets created by a network survey as well as add new targets. Optionally, further restrict targets based on host attributes or VLAN ID. For more information, see Configuring Compliance White List Targets.

Step 8 Create host profiles that represent compliant hosts. You can configure the global host profile, edit the host profiles created by a network survey, as well as add new host profiles and add and edit shared host profiles. For more information, see Configuring Compliance White List Host Profiles.

Step 9 Click Save White List to save your white list.

The white list is saved. You can now add it to an active correlation policy to begin evaluating the target hosts for compliance, generating white list events when a host violated the white list, and, optionally triggering responses to white list violations. For more information, see Creating Correlation Policies.

Surveying Your Network

License: FireSIGHT

When you begin creating a compliance white list, you can survey either your entire network or a specific network segment.

Surveying your network gathers data from the database about the application protocols, clients, web applications, and protocols running on the different detected operating systems. Then, the system creates one host profile within the white list for each detected operating system. By default, these host profiles allow all of the detected clients, application protocols, web applications, and protocols that the system has detected on each applicable operating systems.

This creates a baseline white list so that you do not have to manually create and configure multiple host profiles. After you survey your network, you can then edit or delete the host profiles that the survey created to suit your needs; you can also add any other host profiles you might need.

Note that you can survey your network at any time during the white list creation process. This can add additional allowed clients, application protocols, web applications, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. If you resurvey your network within a white list that is used within an active correlation policy, and the survey changes either your targets or host profiles, the target hosts are re-evaluated when you save the white list. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

To begin creating a compliance white list by surveying your network:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click New White List.

The Survey Network page appears.

Step 3 Do you want to survey your network?

- If yes , continue with the next step.

- If no , click Skip .

The Create White List page appears and displays a blank white list. Continue with the procedure in the next section, Providing Basic White List Information.

Step 4 In the IP Address and Netmask fields, enter the IP address and network mask (in special notation such as CIDR) that represent the hosts you want to survey.

Make sure to specify a network that you configured the system to monitor in the network discovery policy. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Tip To survey the entire monitored network, use the default values of 0.0.0.0/0 and ::/0.

Step 5 Click OK.

The Create White List page appears.

The white list is pre-populated; its targets are the hosts in the network you surveyed and its allowed host profiles are those of the targets.

Step 6 To survey additional networks, click Target Network and repeat steps 4 and 5 for each additional network you want to survey.

Surveying an additional network can add additional allowed clients, application protocols, web applications, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during the initial survey. Surveying an additional network also adds a target to the white list that represents the hosts in the network segment that you surveyed. You can then edit or delete this target.

Step 7 Continue with the next section, Providing Basic White List Information.

Providing Basic White List Information

License: FireSIGHT

You must give each white list a name, and, optionally, a short description. In addition, you can choose whether jailbroken mobile devices should cause a white list violation.

To provide basic white list information:

Access: Admin

Step 1 In the Name field, type a name for the new white list.

Step 2 In the Description field, type a short description of the white list.

Step 3 To allow jailbroken mobile devices on your network, enable Allow Jailbroken Mobile Devices. To cause all jailbroken devices evaluated by the white list to generate a white list violation, disable the option.

Step 4 Continue with the next section, Configuring Compliance White List Targets.

Configuring Compliance White List Targets

License: FireSIGHT

When you create a compliance white list, you must specify the portions of your network it applies to. You can use a white list to evaluate all the hosts on your monitored network, or you can restrict the white list to evaluate only certain network segments or even individual hosts. You can further restrict the white list so that it evaluates only hosts that have a certain host attribute or that belong to a certain VLAN. A host that is eligible to be evaluated by a white list is called a target. For a more detailed introduction to white list targets, see Understanding White List Targets.

When you are finished creating compliance white list targets, continue with Configuring Compliance White List Host Profiles.

Note If you change or delete a host attribute from a host and that modification means that the host is no longer a valid target, the host is no longer evaluated by the white list and is considered neither compliant nor non-compliant.

For information on how to modify and delete targets, see:

- Modifying Existing Targets

- Deleting Existing Targets

When you create a target for a compliance white list, you specify the criteria a host must meet to be evaluated against the white list. A valid target:

- must be in one of the IP address blocks you specify. You can also exclude blocks of IP addresses.

- must have at least one of the host attributes you specify.

- must belong to one of the VLANs you specify.

Note that if you add a target to a white list that is used by an active correlation policy, after you save the white list, the new target hosts are evaluated for compliance. However, this evaluation does not generate white list events.

To create a compliance white list target:

Access: Admin

).

The settings for the new target appear.

Tip You can also create a new target by surveying a network segment. On the Create White List page, click Target Network, then follow steps 4 and 5 in Surveying Your Network. The new target is created and is named according to the IP addresses you specified. Click the target you just created and continue with the rest of this procedure to rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions.

Step 2 In the Name field, type a name for the new target.

.

Step 4 In the IP Address and Netmask fields, enter the IP address and network mask (in special notation, such as CIDR) that represent the hosts you want to target or exclude from targeting.

You should make sure that you specify a network that you configured the system to monitor in your network discovery policy. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

Tip To target the entire monitored network, use 0.0.0.0/0 and ::/0.

Step 5 If you want to exclude the network from monitoring, select Exclude.

Step 6 To add additional networks, repeat steps 4 and 5.

Step 7 Target hosts that have a specific host attribute by clicking Add next to Targeted Host Attributes.

Step 8 From the Attribute and Value drop-down lists, specify the host attribute.

Step 9 To add additional host attributes, repeat steps 7 and 8.

A host must have at least one of the host attributes you specify to be evaluated against the white list.

Step 10 Target hosts that belong to a specific VLAN by clicking Add next to Targeted VLANs.

Step 11 In the VLAN ID field, specify the VLAN IDs of the hosts you want to evaluate against the white list. This can be any integer between 0 and 4095 for 802.1q VLANs.

Step 12 To add additional VLAN IDs, repeat steps 10 and 11.

The host must be a member of one of the VLANs you specify to be evaluated against the white list.

Modifying Existing Targets

License: FireSIGHT

After you modify a target, you must save the white list for your changes to take effect. Note that if you modify a target in a white list that is used by an active correlation policy, after you save the white list, any new target hosts are evaluated for compliance. However, this evaluation does not generate white list events. In addition, the system changes the white list host attribute of previously valid targets to Not Evaluated.

To modify an existing target:

Access: Admin

Step 1 On the Create White List page, under Targets, click the target you want to modify.

The settings for the target appear.

Step 2 Make changes as needed.

You can rename the target, add or exclude additional networks, and add host attribute or VLAN restrictions. For more information, see Configuring Compliance White List Targets.

Deleting Existing Targets

License: FireSIGHT

After you delete a target, you must save the white list for your changes to take effect. Note that if you delete a target from a white list that is used by an active correlation policy, the system changes the white list host attribute of previously valid targets to Not Evaluated.

To delete a white list target:

Access: Admin

).

Step 2 When prompted, confirm that you want to delete the target.

The target is deleted.

Configuring Compliance White List Host Profiles

License: FireSIGHT

Host profiles in a compliance white list specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on the target hosts. There are three kinds of host profiles you can configure in a white list:

- global host profiles, which specify the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system

- host profiles for specific operating systems, which specify not only which operating systems are allowed to run on your network, but also the application protocols, clients, web applications, and protocols that are allowed to run on those operating systems

- shared host profiles, which function exactly like the host profiles for specific operating systems, except they are not tied to a single white list; you can use them across multiple white lists

For a more detailed introduction to compliance white list host profiles, see Understanding White List Host Profiles.

When you are finished creating compliance white list host profiles, you can add the white list to an active correlation policy to begin evaluating the target hosts for compliance, generating white list events when a host violated the white list, and optionally, triggering responses based on white list violations.

For information on how to create, modify, and delete compliance white list host profiles, see:

- Configuring the Global Host Profile

- Creating Host Profiles for Specific Operating Systems

- Adding a Shared Host Profile to a Compliance White List

- Modifying Existing Host Profiles

- Deleting Existing Host Profiles

Configuring the Global Host Profile

License: FireSIGHT

Every white list contains a global host profile, which specifies the application protocols, clients, web applications, and protocols that are allowed to run on target hosts, regardless of the host’s operating system. For a more detailed introduction to the global host profile, see Understanding the Global Host Profile.

To configure the global host profile:

Access: Admin

Step 1 On the Create White List page, under Allowed Host Profiles, click Any Operating System.

The settings for the global host profile appear.

Step 2 To specify the application protocols you want to allow, follow the directions in Adding an Application Protocol to a Host Profile.

Step 3 To specify the clients you want to allow, follow the directions in Adding a Client to a Host Profile.

Step 4 To specify the web applications you want to allow, follow the directions in Adding a Web Application to a Host Profile.

Step 5 To specify the protocols you want to allow, follow the directions in Adding a Protocol to a Host Profile.

Note that ARP, IP, TCP, and UDP are always allowed.

Creating Host Profiles for Specific Operating Systems

License: FireSIGHT

Host profiles for specific operating systems indicate not only which operating systems are allowed to run on your network, but also the application protocols, clients, web applications, and protocols that are allowed to run on those operating systems. For a more detailed introduction, see Understanding Host Profiles for Specific Operating Systems.

To create a new compliance white list host profile for a specific operating system:

Access: Admin

).

The settings for the new host profile appear.

Step 2 In the Name field, type a descriptive name for the host profile.

Step 3 From the OS Vendor, OS Name, and Version drop-down lists, pick the operating system and version for which you want to create a host profile.

Step 4 Specify the application protocols you want to allow. You have three options:

- To allow all application protocols, leave the Allow all Application Protocols check box selected.

- To allow no application protocols, clear the Allow all Application Protocols check box.

- To allow specific application protocols, follow the directions in Adding an Application Protocol to a Host Profile.

Step 5 Specify the clients you want to allow. You have three options:

- To allow all clients, leave the Allow all Clients check box selected.

- To allow no clients, clear the Allow all Clients check box.

- To allow specific clients, follow the directions in Adding a Client to a Host Profile.

Step 6 Specify the web applications you want to allow. You have three options:

- To allow all web applications, leave the Allow all Web Applications check box selected.

- To allow no web applications, clear the Allow all Web Applications check box.

- To allow specific web applications, follow the directions in Adding a Web Application to a Host Profile.

Step 7 Specify the protocols you want to allow.

To add a protocol, next to Allowed Protocols, follow the directions in Adding a Protocol to a Host Profile. Note that ARP, IP, TCP, and UDP are always allowed.

Adding an Application Protocol to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain application protocols to run on specific operating systems. You can also configure a white list to allow certain application protocols to run on any valid target; these are called globally allowed application protocols.

For any allowed application protocol, you can either specify the type of application protocol that you want to allow — FTP and SSH are examples of application protocol types — or you can allow a custom application protocol by specifying an application protocol type of any. You must also specify the protocol the allowed application protocol uses (TCP or UDP). You can allow the application protocol on any port, or restrict it to a port that you specify.

Optionally, you can require that the application protocol server have a specific vendor or version. For example, you could allow SSH to run on Linux hosts on port 22. You could also restrict the particular vendor and version to OpenSSH 4.2.

To add an application protocol to a compliance white list host profile:

Access: Admin

if you are modifying the Any Operating System host profile).

A pop-up window appears. The application protocols listed are:

- application protocols that you created within the white list

- application protocols that existed in the network map when you surveyed your networks as described in Surveying Your Network

- application protocols that are used by other host profiles in the white list, which may include built-in application protocols created by the VRT for use in the default white list

Step 2 You have two options:

- To add an application protocol already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple application protocols. You can also click and drag to select multiple adjacent application protocols.

The application protocol is added. Note that if you added a built-in application protocol, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the application protocol’s values (such as the port or protocol), click the application protocol you just added to display the application protocol editor.

- To add a new application protocol, select <New Application Protocol> and click OK .

The application protocol editor appears.

Step 3 From the Type drop-down list, select the application protocol type. For custom application protocols, select any.

Step 4 Specify the application protocol port. You have two options:

- To allow the application protocol to run on any port, check the Any port check box.

- To allow the application protocol to run only on a specific port, type the port number in the port field.

Step 5 From the Protocol drop-down list, select the protocol: TCP or UDP.

Step 6 Optionally, in the Vendor and Version fields, specify a vendor and version for the application protocol.

If you do not specify a vendor or version, the white list allows all vendors and versions as long as the type and protocol match. Note that if you restrict the vendor and version, you must make sure to specify them exactly as they would appear in an event view or in the application protocols network map.

Step 7 Click OK.

The application protocol is added. Note that you must save the white list for your changes to take effect.

If you added an application protocol to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Client to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain client applications to run on specific operating systems. You can also configure a white list to allow certain clients to run on any valid target; these are called globally allowed clients.

Optionally, you can require that the client be a specific version. For example, you could allow only Microsoft Internet Explorer 8.0 to run on Microsoft Windows hosts.

To add a client to a compliance white list host profile:

Access: Admin

if you are modifying the Any Operating System host profile).

A pop-up window appears. The clients listed are:

- clients that you created within the white list

- clients that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network

- clients that are used by other host profiles in the white list, which may include built-in clients created by the VRT for use in the default white list

Step 2 You have two options:

- To add a client already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple clients. You can also click and drag to select multiple adjacent clients.

The client is added. Note that if you added a built-in client, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the client’s values (such as its version), click the client you just added to display the client editor.

- To add a new client, select <New Client> and click OK .

The client editor appears.

Step 3 From the Client drop-down list, select the client.

Step 4 Optionally, in the Version field, specify a version for the client.

If you do not specify a version, the white list allows all versions as long as the name matches. Note that if you restrict the version, you must specify it exactly as it would appear in a table view of clients.

Step 5 Click OK.

The client is added. Note that you must save the white list for your changes to take effect.

If you added a client to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Web Application to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain web applications to run on specific operating systems. You can also configure a white list to allow certain web applications to run on any valid target; these are called globally allowed web applications.

To add a web application to a compliance white list host profile:

Access: Admin

if you are modifying the Any Operating System host profile).

A pop-up window appears, listing all web applications detected by the system.

Step 2 Select a web application and click OK. Use Ctrl or Shift while clicking to select multiple web applications. You can also click and drag to select multiple adjacent web applications.

The web application is added. Note that you must save the white list for your changes to take effect.

If you added a web application to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Protocol to a Host Profile

License: FireSIGHT

You can configure a compliance white list, using either a shared host profile or a host profile that belongs to a single white list, to allow certain protocols to run on specific operating systems. You can also configure a white list to allow certain protocols to run on any valid target; these are called globally allowed protocols. Note that ARP, IP, TCP, and UDP are always allowed to run on any host; you cannot disallow them.

For any allowed protocol, you must specify its type (Network or Transport) and number.

To add a protocol to a compliance white list host profile:

Access: Admin

if you are modifying the Any Operating System host profile).

A pop-up window appears. The protocols listed are:

- protocols that you created within the white list

- protocols that were running on hosts in the network map when you surveyed your networks as described in Surveying Your Network

- protocols that are used by other host profiles in the white list, which may include built-in protocols created by the VRT for use in the default white list

Step 2 You have two options:

- To add a protocol already in the list, select it and click OK . Use Ctrl or Shift while clicking to select multiple protocols. You can also click and drag to select multiple adjacent protocols.

The protocol is added. Note that if you added a built-in protocol, its name appears in italics. You can skip the rest of the procedure, or optionally, to change any of the protocol’s values (such as the type or number) click the protocol you just added to display the protocol editor.

- To add a new protocol, select <New Protocol> and click OK .

The protocol editor appears.

Step 3 From the Type drop-down list, select the protocol type: Network or Transport.

Step 4 Specify the protocol. You have two options:

- Select a protocol from the drop-down list.

- Select Other (manual entry) to specify a protocol that is not in the list. For network protocols, type the appropriate number as listed in http://www.iana.org/assignments/ethernet-numbers/ . For transport protocols, type the appropriate number as listed in http://www.iana.org/assignments/protocol-numbers/ .

Step 5 Click OK.

The protocol is added. Note that you must save the white list for your changes to take effect.

If you added a protocol to a white list that is used by an active correlation policy, after you save the white list, the target hosts are re-evaluated. Although this re-evaluation may bring some hosts into compliance, it does not generate any white list events.

Adding a Shared Host Profile to a Compliance White List

License: FireSIGHT

Shared host profiles are also tied to specific operating systems, but you can use them across white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile.

You can add any of the built-in shared host profiles to your compliance white lists, or you can add shared host profiles that you created. For more information, see Understanding Shared Host Profiles and Creating Shared Host Profiles.

To add a shared host profile to a compliance white list:

Access: Admin

Step 1 On the Create White List page, click Add Shared Host Profile.

The Add Shared Host Profile page appears.

Step 2 From the Name drop-down list, select the shared host profile you want to add to your white list, and click OK.

The shared host profile is added to your white list and the Create White List page appears again. The shared host profile’s name appears in italics under Allowed Host Profiles.

Tip You can edit a shared host profile from within a white list that uses it by clicking on the profile name under Allowed Host Profiles. For more information, see Modifying Existing Host Profiles.

Modifying Existing Host Profiles

License: FireSIGHT

After you modify a host profile within a compliance white list, you must save the white list for your changes to take effect.

If a host profile you modify belongs to a white list used in an active correlation policy, modifying the profile may bring hosts into or out of compliance but does not generate white list events. Further, modifying a shared host profile affects every white list that uses it. This may bring hosts into or out of compliance not only in the white list you are working with, but in other white lists as well.

Tip As with other shared host profiles, you can edit the built-in host profiles used by the default white list. You can also reset them to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults.

To modify an existing host profile:

Access: Admin

Step 1 On the Create White List page, click the name of the host profile you want to modify.

) also appears.

Step 2 You have two options:

- If you are modifying a shared host profile, click Edit .

A pop-up window appears. Make changes as needed as described in the table below. Click Save All Profiles to save the profile, then click Done to close the pop-up window.

For more information editing shared host profiles, see Modifying a Shared Host Profile.

- If you are modifying either the white list’s global host profile or a host profile for a specific operating system, perform one of the actions described in the procedures below.

To rename the host profile:

Access: Admin

Step 1 Type a new name in the Name field.

To change the operating system for the host profile:

Access: Admin

Step 1 Select the new operating system and version from the OS Vendor, OS Name, and Version drop-down lists.

If you change these values, you may also want to rename the host profile. Note that a white list’s global host profile has no operating system associated with it, so you cannot change it.

To add an application protocol:

Access: Admin

Step 1 Follow the directions in Adding an Application Protocol to a Host Profile.

To add a client:

Access: Admin

Step 1 Follow the directions in Adding a Client to a Host Profile.

To add a web application:

Access: Admin

Step 1 Follow the directions in Adding a Web Application to a Host Profile.

To add a protocol:

Access: Admin

Step 1 Follow the directions in Adding a Protocol to a Host Profile.

To allow all application protocols:

Access: Admin

Step 1 Under Allowed Application Protocols, select the Allow all Application Protocols check box.

Note that the check box does not appear until you delete any application protocols you have previously allowed.

To allow all clients:

Access: Admin

Step 1 Under Allowed Clients, select the Allow all Clients check box.

Note that the check box does not appear until you delete any clients you have previously allowed.

To allow all web applications:

Access: Admin

Step 1 Under Allowed Web Applications, select the Allow all Web Applications check box.

Note that the check box does not appear until you delete any web applications you have previously allowed.

To modify an application protocol, client, web application, or protocol:

Access: Admin

Step 1 Click the element you want to modify.

For more information on the properties you can change, see:

- Adding an Application Protocol to a Host Profile

- Adding a Client to a Host Profile

- Adding a Protocol to a Host Profile

Note The changes you make to an application protocol, client, web application, or protocol are reflected in every host profile that uses that element.

To delete an application protocol, client, web application, or protocol:

Access: Admin

).

To survey your network:

Access: Admin

Step 1 Click Survey Network. Surveying your network can add additional allowed clients, application protocols, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during any initial survey. For more information, see Surveying Your Network.

Deleting Existing Host Profiles

License: FireSIGHT

After you delete a host profile from a compliance white list, you must save the white list for your changes to take effect. Note that deleting a shared host profile removes it from the white list, but does not delete the profile or remove it from any other white lists that use it. You cannot delete a white list’s global host profile.

If the host profile you delete belongs to one or more white lists used in an active correlation policy, deleting the profile may force hosts out of compliance, but does not generate white list events.

To delete a compliance white list host profile:

Access: Admin

).

Step 2 When prompted, confirm that you want to delete the host profile.

The host profile is deleted.

Managing Compliance White Lists

License: FireSIGHT

Use the White List page to manage compliance white lists. You can create, modify, and delete white lists, including the default white list. You can also edit any shared host profiles you have created, as well as the built-in shared host profiles, and add new shared host profiles. For more information, see:

- Creating Compliance White Lists

- Modifying a Compliance White List

- Deleting a Compliance White List

- Working with Shared Host Profiles

Modifying a Compliance White List

License: FireSIGHT

When you modify a compliance white list that is included in an active correlation policy, the system re-evaluates the target hosts. Note that the system does not generate white list events — and therefore does not trigger any responses you associated with the white list — during this re-evaluation, even if the white list is included in an active correlation policy and a previously compliant host becomes non-compliant with the updated white list.

To modify an existing compliance white list:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

).

The Create White List page appears.

Step 3 Make modifications as necessary and click Save White List.

The white list is updated.

Deleting a Compliance White List

License: FireSIGHT

You cannot delete a compliance white list that you are using in one or more correlation policies; you must first delete the white list from all policies where it is used. For information on deleting a white list from a policy, see Editing a Correlation Policy.

Deleting a white list also removes the host attribute associated with the white list from all hosts on your network.

To delete an existing compliance white list:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

).

The white list is deleted.

Working with Shared Host Profiles

License: FireSIGHT

Shared host profiles specify which operating systems, clients, application protocols, web applications, and protocols are allowed to run on target hosts across multiple white lists. That is, if you create multiple white lists but want to use the same host profile to evaluate hosts running a particular operating system across the white lists, use a shared host profile. Note that the default white list uses a special category of shared host profiles, called built-in host profiles.

For a more detailed introduction to shared host profiles, see Understanding Shared Host Profiles.

You can create, modify, and delete shared host profiles. In addition, if you modify or delete any of the built-in shared host profiles, or modify or delete any of the built-in application protocols, protocols, or clients, you can reset them to their factory defaults. For more information, see:

- Creating Shared Host Profiles

- Modifying a Shared Host Profile

- Deleting a Shared Host Profile

- Resetting Built-In Host Profiles to Their Factory Defaults

After you create a shared host profile, you can add it to multiple white lists. For more information, see Adding a Shared Host Profile to a Compliance White List.

Creating Shared Host Profiles

License: FireSIGHT

Create a shared host profile if you want to use the same host profile to evaluate hosts running a particular operating system across multiple white lists.

Tip You can also create a shared host profile for your compliance white lists using the host profile of a specific host. For more information, see Creating a White List Host Profile from a Host Profile.

To create a shared host profile:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click Edit Shared Profiles.

The Edit Shared Profiles page appears.

Step 3 Optionally, survey your network.

Surveying your network creates several baseline shared white lists based on the data the system has accumulated about your network. This saves you from manually creating and configuring multiple shared host profiles. You have two options:

- To survey your network, click Survey Network . For more information, see Surveying Your Network.

The system creates one or more baseline shared host profiles. You can edit or delete these shared host profiles as described in Modifying a Shared Host Profile and Deleting a Shared Host Profile. To add any other shared host profiles you might need, continue with the next step.

- To skip surveying your network, continue with the next step.

).

The settings for the new shared host profile appear.

Step 5 In the Name field, type a descriptive name for the shared host profile.

Step 6 From the OS Vendor, OS Name, and Version drop-down lists, pick the operating system and version for which you want to create a shared host profile.

Step 7 Specify the application protocols you want to allow. You have three options:

- To allow all application protocols, select the Allow all Application Protocols check box.

- To allow no application protocols, leave the Allow all Application Protocols check box cleared.

- To allow specific application protocols, next to Allowed Application Protocols , follow the directions in Adding an Application Protocol to a Host Profile.

Step 8 Specify the clients you want to allow. You have three options:

- To allow all clients, select the Allow all Clients check box.

- To allow no clients, leave the Allow all Clients check box cleared.

- To allow specific clients, follow the directions in Adding a Client to a Host Profile.

Step 9 Specify the web applications you want to allow. You have three options:

- To allow all web applications, select the Allow all Web Applications check box.

- To allow no web applications, leave the Allow all Web Applications check box cleared.

- To allow specific web applications, follow the directions in Adding a Web Application to a Host Profile.

Step 10 Specify the protocols you want to allow.

To add a protocol, next to Allowed Protocols, follow the directions in Adding a Protocol to a Host Profile. Note that ARP, IP, TCP, and UDP are always allowed.

Step 11 Click Save all Profiles to save your changes.

The shared host profile is created. You can now add the shared host profile to any compliance white list.

Modifying a Shared Host Profile

License: FireSIGHT

Modifying a shared host profile changes the profile for all the white lists it belongs to. For the white lists that use the shared host profile and are also used in an active correlation policy, modifying a shared host profile may bring hosts into or out of compliance, but does not generate white list events.

To...

You can...

rename the host profile

type a new name in the Name field.

change the operating system

select the new operating system and version from the OS Vendor, OS Name, and Version drop-down lists. If you change these values, you may also want to rename the host profile.

add an application protocol

follow the directions in Adding an Application Protocol to a Host Profile.

add a client

follow the directions in Adding a Client to a Host Profile.

add a web application

follow the directions in Adding a Web Application to a Host Profile.

add a protocol

follow the directions in Adding a Protocol to a Host Profile.

allow all application protocols

under Allowed Application Protocols, select the Allow all Application Protocols check box. Note that the check box does not appear until you delete any application protocols you have previously allowed.

allow all clients

under Allowed Clients, select the Allow all Clients check box. Note that the check box does not appear until you delete any clients you have previously allowed.

allow all web applications

under Allowed Web Applications, select the Allow all Web Applications check box. Note that the check box does not appear until you delete any clients you have previously allowed.

modify an application protocol, client, web application, or protocol

click the element you want to modify. For more information on the properties you can change, see:

- Adding an Application Protocol to a Host Profile

- Adding a Client to a Host Profile

- Adding a Web Application to a Host Profile

- Adding a Protocol to a Host Profile

Note The changes you make to an application protocol, client, or protocol are reflected in every host profile that uses that element.

delete an application protocol, client, web application, or protocol

).

survey your network

click Survey Network. Surveying your network can add additional allowed clients, application protocols, web applications, and protocols to the host profiles that already exist, and can create additional host profiles if the survey detects hosts running operating systems that were not detected during any initial survey. For more information, see Surveying Your Network.

To modify a shared host profile:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click Edit Shared Profiles.

The Edit Shared Profiles page appears.

Step 3 Do you want to edit one of the built-in shared host profiles?

- If yes, expand Built-in Host Profiles to display those host profiles.

- If no, continue with the next step.

Step 4 Click the name of the shared host profile you want to modify.

The host profile appears.

Step 5 Perform any of the actions described in Table 52-2.

Step 6 Click Save all Profiles to save your changes.

The shared host profile is saved.

Deleting a Shared Host Profile

License: FireSIGHT

If the shared host profile you delete belongs to one or more white lists used in an active correlation policy, deleting the profile may force hosts out of compliance, but does not generate white list events.

Tip If you delete a built-in shared host profile that is used by the default white list, you can restore it by resetting the built-in profiles to their factory defaults. For more information, see Resetting Built-In Host Profiles to Their Factory Defaults.

To delete a shared host profile:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click Edit Shared Profiles.

The Edit Shared Profiles page appears.

Step 3 Do you want to delete one of the built-in shared host profiles?

- If yes, expand Built-in Host Profiles to display those host profiles.

- If no, continue with the next step.

).

Confirm that you want to delete the shared host profile.

Step 5 Click Save all Profiles to save your changes.

The shared host profile is deleted and removed from all compliance white lists that use it.

Resetting Built-In Host Profiles to Their Factory Defaults

License: FireSIGHT

The default white list uses a special category of shared host profiles, called built-in host profiles. Built-in host profiles use built-in application protocols, protocols, and clients. You can use any these elements as-is in both the default white list and in any custom white list that you create, or you can modify them to suit your needs. For more information, see Understanding Shared Host Profiles.

If you make changes to the built-in profiles, application protocols, protocols, web applications, or clients that you need to undo, you can reset to factory defaults. When you reset to factory defaults, the following things occur:

- All built-in host profiles, application protocols, protocols, and clients that you modified are reset to their factory defaults.

- All built-in host profiles, application protocols, protocols, and clients that you deleted are restored.

- All white lists (including the default white list) that are used by active correlation policies and that used any of the reset built-in host profiles, application protocols, protocols, or clients are re-evaluated. Although this re-evaluation may change the compliance of some hosts into compliance, it does not generate any white list events.

To reset built-in host profiles, application protocols, protocols, and clients:

Access: Admin

Step 1 Select Policies > Correlation, then click White List.

The White List page appears.

Step 2 Click Edit Shared Profiles.

The Edit Shared Profiles page appears.

Step 3 Click Built-in Host Profiles.

The Built-in Host Profiles page appears.

Step 4 Click Reset to Factory Defaults.

Step 5 Confirm that you want to reset to factory defaults by clicking OK.

All built-in host profiles, application protocols, protocols, and clients are reset to factory defaults. Any white list that is used by an active correlation policy and that used any of the reset built-in host profiles, application protocols, protocols, or clients is re-evaluated.

Working with White List Events

License: FireSIGHT

When the system generates a discovery event that indicates that a host is out of compliance with a white list that is included in an activated correlation policy, a white list event is generated. White list events are a special kind of correlation event, and are logged to the correlation event database. You can search, view, and delete white list events.

Tip For information on configuring the number of events saved in the database, see Configuring Database Event Limits. Note that white list events are stored in the correlation event database.

For more information, see the following sections:

- Viewing White List Events

- Understanding the White List Events Table

- Searching for Compliance White List Events

Viewing White List Events

License: FireSIGHT

You can use the Defense Center to view a table of compliance white list events. Then, you can manipulate the event view depending on the information you are looking for.

The page you see when you access white list events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of white list events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

To...

You can...

view the host profile for a host

) that appears next to the IP address.

view user profile information

)that appears next to the user identity. For more information, see Understanding User Details and Host History.

sort and constrain events on the current workflow page

find more information in Sorting Drill-Down Workflow Pages.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

learn more about the columns that appear

find more information in Understanding the White List Events Table.

modify the time and date range for displayed events

find more information in see Setting Event Time Constraints.

drill down to the next page in the workflow, constraining on a specific value

use one of the following methods:

- on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some users, select the check boxes next to the users you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.

For more information, see Constraining Events.

delete white list events from the system

use one of the following methods:

- To delete some events, select the check boxes next to the events you want to delete, then click Delete .

- To delete all events in the current constrained view, click Delete All , then confirm you want to delete all the events.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

To view compliance white list events:

Access: Admin/Any Security Analyst/Discovery Admin

Step 1 Select Analysis > Correlation > White List Events.

The first page of the default white list events workflow appears. To use a different workflow, including a custom workflow, click (switch workflow).by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Understanding the White List Events Table

License: FireSIGHT

You can use the correlation policy feature to build correlation policies that let the system respond in real time to threats on your network. Correlation policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on correlation policies, see Configuring Correlation Policies and Rules.

Field

Description

Time

The date and time that the white list event was generated.

IP Address

The IP address of the non-compliant host.

User

The identity of any known user logged in to the non-compliant host.

Port

The port, if any, associated with the event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol). For other types of white list violations, this field is blank.

Description

A description of how the white list was violated. For example:

Client “AOL Instant Messenger” is not allowed.

Violations that involve an application protocol indicate the application protocol name and version, as well as the port and protocol (TCP or UDP) it is using. If you restrict prohibitions to a particular operating system, the description includes the operating system name. For example:

Server "ssh / 22 TCP ( OpenSSH 3.6.1p2 )" is not

allowed on Operating System “Linux Linux 2.4 or

2.6”.

Policy

The name of the correlation policy that was violated, that is, the correlation policy that includes the white list.

White List

The name of the white list.

Priority

The priority specified by the policy or white list that triggered the policy violation. For information on setting correlation rule and policy priorities, see Providing Basic Policy Information and Setting Rule and White List Priorities.

Host Criticality

The user-assigned host criticality of the host that is out of compliance with the white list: None, Low, Medium, or High. For more information on host criticality, see Working with the Predefined Host Attributes.

Device

The name of the managed device that detected the white list violation.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for Compliance White List Events

License: FireSIGHT

You can search for specific compliance white list events. You may want to create searches customized for your network environment, then save them to re-use later. The following table describes the search criteria you can use.

Table 52-5 Compliance White List Event Search Criteria

Field

Search Criteria Rules

Policy

Enter the name of a correlation policy to return all events caused by violations of white lists included in that policy.

White List

Enter the name of a white list to return all events caused by violations of that white list.

Description

Enter the white list event description.

Priority

Specify the priority of the white list event, which is determined either by the priority of the white list in a correlation policy or by the priority of the correlation policy itself. Note that the white list priority overrides the priority of its policy. Enter none for no priority.

For information on setting correlation rule and policy priorities, see Providing Basic Policy Information and Setting Rule and White List Priorities.

IP Address

Specify an IP address of a host that has become non-compliant with a white list.

User

Specify the identity of the user logged in to a host that has become non-compliant with a white list.

Port

Specify the port, if any, associated with the discovery event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol).

Host Criticality

Specify the host criticality of the source host involved in the white list event: None, Low, Medium, or High. For more information on host criticality, see Working with the Predefined Host Attributes.

Device

Type the device name or IP address, or a device group, stack, or cluster name to restrict the search to specific devices that detected the white list violation. For detailed information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

To search for compliance white list events:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select White List Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in Table 52-5, and keeping in mind the following additional points:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For more information on search syntax, including using objects in searches, see Searching for Events.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default white list events workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Working with White List Violations

License: FireSIGHT

The system keeps track of the ways in which hosts on your network violate the compliance white lists in active correlation policies. You can search and view these records.

For more information, see the following sections:

- Viewing White List Violations

- Understanding the White List Violations Table

- Searching for White List Violations

Viewing White List Violations

License: FireSIGHT

You can use the Defense Center to view a table of white list violations. Then, you can manipulate the event view depending on the information you are looking for. The page you see when you access white list violations differs depending on the workflow you use. There are two predefined workflows:

- The Host Violation Count workflow provides a series of pages that list all the hosts that violate at least one white list. The first page sorts the hosts based on the number of violations per host, with the hosts with the greatest number of violations at the top of the list. If a host violates more than one white list, there is a separate row for each violated white list. The workflow also contains a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation.

- The White List Violations workflow includes a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation.

Both predefined workflows terminate in a host view, which contains a host profile for every host that meets your constraints. You can also create a custom workflow that displays only the information that matches your specific needs. For more information, see Creating Custom Workflows.

To...

You can...

view the host profile for a host

) that appears next to the IP address.

sort and constrain events on the current workflow page

find more information in Sorting Drill-Down Workflow Pages.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

learn more about the columns that appear

find more information in Understanding the White List Violations Table.

drill down to the next page in the workflow

use one of the following methods:

- To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some events, select the check boxes next to the events you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.

For more information, see Constraining Events.

navigate to other event views to view associated events

find more information in Navigating Between Workflows.

To view compliance white list violations:

Access: Admin/Any Security Analyst/Discovery Admin

Step 1 Select Analysis > Correlation > White List Violations.

The first page of the default white list violations workflow appears. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Understanding the White List Violations Table

License: FireSIGHT

You can use the correlation policy feature to build correlation policies that let the system respond in real time to threats on your network. Correlation policies describe the type of activity that constitutes a policy violation, which include compliance white list violations. For more information on correlation policies, see Configuring Correlation Policies and Rules.

Field

Description

Time

The date and time that the white list violation was detected.

IP Address

The relevant IP address of the non-compliant host.

Type

The type of white list violation, that is, whether the violation occurred as a result of a non-compliant:

- operating system ( os )

- application protocol ( server )

- client ( client )

- protocol ( protocol )

- web application ( web )

Information

Any available vendor, product, or version information associated with the white list violation.

For example, if you have a white list that allows only Microsoft Windows hosts, the Information field describes the operating systems of the hosts that are not running Microsoft Windows.

For protocols that violate a white list, the Information field also indicates whether the violation is due to a network or transport protocol.

Port

The port, if any, associated with the event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol). For other types of white list violations, this field is blank.

Protocol

The protocol, if any, associated with the event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol). For other types of white list violations, this field is blank.

White List

The name of the white list that was violated.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Searching for White List Violations

License: FireSIGHT

You can search for specific compliance white list violations. You may want to create searches customized for your network environment, then save them to re-use later. The following table describes the search criteria you can use.

Table 52-8 Compliance White List Violations Search Criteria

Field

Search Criteria Rules

Time

Specify the date and time that the white list was violated.

IP Address

Specify an IP address of a host that has become non-compliant with a white list.

White List

Enter the name of a white list to return all violations from that white list.

Type

Enter the type of white list violation:

- enter os (or operating system ) to search for violations based on operating systems

- enter server to search for violations based on application protocols

- enter client to search for violations based on clients

- enter protocol to search for violations based on protocols

- enter web application to search for violations based on web applications

Information

Enter white list violation information.

Port

Specify the port, if any, associated with the discovery event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol).

Protocol

Specify the protocol, if any, associated with the discovery event that triggered an application protocol white list violation (a violation that occurred as a result of a non-compliant application protocol).

To search for compliance white list violations:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select White List Violations from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in the Compliance White List Event Search Criteria table, and keeping in mind the following additional points:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

For more information on search syntax, including using objects in searches, see Searching for Events.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default white list violations workflow. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Creating Traffic Profiles

A traffic profile is just that—a profile of the traffic on your network, based on connection data collected over a time span that you specify. You can use connection data collected by your devices, the connection data exported by any or all of your NetFlow-enabled devices, or both.

After you create a traffic profile, you can detect abnormal network traffic by evaluating new traffic against your profile, which presumably represents normal network traffic.

Keep in mind that the FireSIGHT System uses connection data to create traffic profiles and trigger correlation rules based on traffic profile changes. You cannot include connections that you do not log to the Defense Center database in traffic profiles. The system uses only end-of-connection data to populate connection summaries (see Understanding Connection Summaries), which the system then uses to create connection graphs and traffic profiles. Therefore, if you want to create and use traffic profiles, make sure you log connection events at the end of connections.

The time span used to collect data to build your traffic profile is called the profiling time window (PTW). The PTW is a sliding window; that is, if your PTW is one week (the default), your traffic profile includes connection data collected over the last week. You can change the PTW to be as short as an hour or as long as several weeks.

When you first activate a traffic profile, it collects and evaluates connection data according to the criteria you have set, for a learning period equal in time to the PTW. The Defense Center does not evaluate rules you have written against the traffic profile until the learning period is complete.

You can create profiles using all the traffic on a monitored network segment, or you can create more targeted profiles using criteria based on the data in the connection events. For example, you could set the profile conditions so that the traffic profile only collects data where the detected session uses a specific port, protocol, or application. Or, you could add a host profile qualification to the traffic profile to collect data only for hosts that exhibit a host criticality of high.

Finally, when you create a traffic profile, you can specify inactive periods—periods in which connection data do not affect profile statistics and rules written against the profile do not trigger. You can also change how often the traffic profile aggregates and calculates statistics on collected connection data.

The following graphic shows a traffic profile with a PTW of one day and a sampling rate of five minutes.

After you create and activate a traffic profile and its learning period is complete, you can create correlation rules that trigger when you detect anomalous traffic. For example, you could write a rule that triggers if the amount of data traversing your network (measured in packets, KBytes, or number of connections) suddenly spikes to three standard deviations above the mean amount of traffic, which could indicate an attack or other security policy violation. Then, you could include that rule in a correlation policy to alert you of the traffic spike or to perform a remediation in response. For information on using traffic profiles to detect abnormal network traffic, see Creating Rules for Correlation Policies.

You create traffic profiles on the Traffic Profiles page. The slider icon next to each profile indicates whether the profile is active. If you want to base a correlation rule on a traffic profile change, you must activate the profile. If the slider icon is blue with a check mark, the profile is active. If it is gray with an x, the profile is inactive. For more information, see Activating and Deactivating Traffic Profiles.

The progress bar shows the status of the traffic profile’s learning period. When the progress bar reaches 100%, correlation rules written against the profile will trigger.

Tip You can sort traffic profiles by state (active versus inactive) or alphabetically by name using the Sort by drop-down list.

For more information, see:

- Providing Basic Profile Information

- Specifying Traffic Profile Conditions

- Adding a Host Profile Qualification

- Setting Profile Options

- Saving a Traffic Profile

- Activating and Deactivating Traffic Profiles

- Editing a Traffic Profile

- Understanding Condition-Building Mechanics

Providing Basic Profile Information

License: FireSIGHT

When you create a traffic profile, you must give it a name and, optionally, a short description.

To begin creating a traffic profile:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

Step 2 Click New Profile.

The Create Profile page appears.

Step 3 In the Profile Name field, type a name of up to 255 characters for the new traffic profile.

Step 4 In the Profile Description field, type a short description of up to 255 characters of the new traffic profile.

Step 5 Continue with Specifying Traffic Profile Conditions.

Specifying Traffic Profile Conditions

License: FireSIGHT

Profile conditions constrain the kinds of connection data you want the traffic profile to track. A simple traffic profile that profiles all the traffic on a monitored network segment has no conditions. In contrast, traffic profiles can be complex, with multiple nested conditions.

You build traffic profile conditions in the Profile Conditions section of the Create Profile page. See Understanding Condition-Building Mechanics for information on building conditions. Also, the syntax you can use to build conditions is fully described in Syntax for Traffic Profile Conditions.

Tip If you want to use the settings from an existing traffic profile, click Copy Settings and, in the pop-up window, select the traffic profile you want to use and click Load.

Syntax for Traffic Profile Conditions

License: FireSIGHT

The following table describes how to build a traffic profile condition.

Keep in mind that NetFlow records do not contain information about which host in the connection is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

The information available for a traffic profile depends on several factors, including the detection method, the logging method, and event type. For more information, see Information Available in Connection and Security Intelligence Events.

Table 53-1 Syntax for Profile Conditions

If you specify...

Select an operator, then...

Application Protocol

Select an application protocol name from the drop-down list of available protocols.

Application Protocol Category

Select an application protocol category name from the drop-down list of available categories.

Client

Select a client name from the drop-down list of available clients.

Client Category

Select a client category name from the drop-down list of available categories.

Connection Type

Specify in the traffic profile whether you want to use connection data collected by your Cisco devices or by NetFlow-enabled devices. If you do not specify a connection type, the traffic profile includes both.

Destination Country or Source Country

Select a country from the drop-down list of available countries. This represents the country associated with a source or destination IP address identified in network traffic.

Initiator IP,

Responder IP, or Initiator/Responder IP

Use a specific IP address or CIDR notation to specify a range of IP addresses.

See Specifying IP Addresses in Searches for a description of the syntax allowed for IP addresses. Note, however, that you cannot use the local or remote keywords to specify IP addresses that are or are not in the networks you are monitoring.

NetFlow Device

Select the NetFlow-enabled device whose data you want to use to create the traffic profile. If you did not add any NetFlow-enabled devices to your deployment (using the local configuration), the NetFlow Device drop-down list is blank.

Responder Port/ICMP Code

Type the port number or ICMP code.

Security Intelligence Category

Select a Security Intelligence category name from the drop-down list of available categories. To use a Security Intelligence category for a traffic profile condition, that category must be set to Monitor instead of Block in the Security Intelligence section of your access control policy. For more information, see Building the Security Intelligence Whitelist and Blacklist.

SSL Encrypted Session

Select Successfully Decrypted.

Transport Protocol

Type TCP or UDP as the transport protocol.

Web Application

Select a web application name from the drop-down list of available web applications.

Web Application Category

Select a web application category name from the drop-down list of available categories.

Adding a Host Profile Qualification

License: FireSIGHT

You can constrain any traffic profile with information from the host profile of the tracked hosts. This constraint is called a host profile qualification. For example, as shown in the following graphic, you could collect connection data only for hosts that are assigned a host criticality of high.

To use a host profile qualification, the host must exist in the database and the host profile property you want to use as a qualification must already be included in the host profile. For example, if you configure a correlation policy rule to trigger when an intrusion event is generated on a host running Windows, the rule only triggers if the host is already identified as Windows when the intrusion event is generated.

To add a host profile qualification:

Access: Admin/Discovery Admin

Step 1 On the Create Profile page, click Add Host Profile Qualification.

The Host Profile Qualification section appears.

Step 2 Build the host profile qualification’s conditions.

You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Condition-Building Mechanics for information building conditions.

The syntax you can use to build conditions is described in Syntax for Host Profile Qualifications.

Tip To remove a host profile qualification, click Remove Host Profile Qualification.

Syntax for Host Profile Qualifications

License: FireSIGHT

When you build a host profile qualification condition, you must first select the host you want to use to constrain your traffic profile. You can select either Responder Host or Initiator Host. After you select the host role, continue building your host profile qualification condition, as described in the Syntax for Host Profile Qualifications table.

Although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. In addition, if your traffic profile uses connection data exported by NetFlow-enabled devices, keep in mind that NetFlow records do not contain information about which host in the connection is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

To match against implied or generic clients, create a host profile qualification based on the application protocol used by the server responding to the client. When the client list on a host that acts as the initiator or source of a connection includes an application protocol name followed by client, that client may actually be an implied client. In other words, the system reports that client based on server response traffic that uses the application protocol for that client, not on detected client traffic.

Table 53-2 Syntax for Host Profile Qualifications

If you specify...

Select an operator, then...

Host Type

Select one or more host types from the drop-down list. You can choose between a normal host or one of several types of network device.

NETBIOS Name

Type the NetBIOS name of the host.

Operating System > OS Vendor

Select one or more operating system vendor names from the drop-down list.

Operating System > OS Name

Select one or more operating system names from the drop-down list.

Operating System > OS Version

Select one or more operating system versions from the drop-down list.

Network Protocol

Type the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

Transport Protocol

Type the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

Host Criticality

Select the host criticality from the list that appears. You can select None, Low, Medium, or High. For more information on host criticality, see Working with the Predefined Host Attributes.

VLAN ID

Type the VLAN ID number of the host.

Application Protocol>

Application Protocol

Select an application protocol from the drop-down list.

Application Protocol >

Application Port

Type the application protocol port number.

Application Protocol >

Protocol

Select the protocol from the drop-down list.

Client > Client

Select a client from the drop-down list.

Client > Client Version

Type the client version.

Web Application

Select a client from the drop-down list.

MAC Address > MAC Address

Type all or part of the MAC address of the host.

MAC Address > MAC Type

Select whether the MAC type is ARP/DHCP Detected.

That is, select whether the system positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), whether the system is seeing many hosts with that MAC address because, for example, there is a router between the device and the host (is not ARP/DHCP Detected), or whether the MAC type is irrelevant (is any).

MAC Vendor

Type all or part of the MAC vendor of hardware used by the host.

any available host attribute, including the default compliance white list host attribute

Specify the appropriate value, which depends on the type of host attribute you select:

- If the host attribute type is Integer, enter an integer value in the range defined for the attribute.

- If the host attribute type is Text, and enter a text value.

- If the host attribute type is List, select a valid list string from the drop-down list.

- If the host attribute type is URL, enter a URL value.

For more information on host attributes, see Working with User-Defined Host Attributes.

Setting Profile Options

License: FireSIGHT

The profiling time window (PTW) is the sliding time window, equal in length to the learning period, that the FireSIGHT System uses to calculate statistics for the traffic profile. The default PTW is one week, but you can change it to be as short as an hour or as long as several weeks.

Also, traffic profiles are based on aggregated connection data. By default, traffic profiles generate statistics on connection events generated by the system over five-minute intervals. However, you can set this sampling rate anywhere between the default five minutes and one hour.

Keep in mind that you should set your PTW and sampling rate so that your traffic profiles contain enough data to be statistically meaningful. For example, a PTW of one day with a sampling rate of one hour would only contain 24 data points, which may not be enough for accurate analysis of network traffic patterns.

Tip Your PTW should include at least 100 data points.

You can also set up inactive periods in traffic profile. For example, consider a network infrastructure where all the workstations are backed up at midnight every night. The backup takes about 30 minutes and spikes the network traffic. In that case, you might want to set up a recurring inactive period for your traffic profile to coincide with the scheduled backups. During inactive periods, the traffic profile collects data (so you can see the traffic on the traffic profile graphs), but that data is not used when calculating profile statistics. You can set up inactive periods to recur daily, weekly, or monthly. Inactive periods can be as short as five minutes or as long as one hour. Traffic profile graphs plotted over time show inactive periods as a shaded region.

To set profile options:

Table 53-3 Profile Options

If you want to...

You can...

change the profiling time window

in the Profiling Time Window field, type the number of hours, days, or weeks. Then choose hour(s), day(s), or week(s) from the drop-down list.

change the sampling rate

select the rate from the Sampling Rate drop-down list.

add an inactive period

click Add Inactive Period. Then, using the drop-down lists, specify when and how often you want the traffic profile to refrain from collecting data.

delete an inactive period

click Delete next to the inactive period you want to delete.

Saving a Traffic Profile

License: FireSIGHT

Use the following procedure to save a traffic profile.

To save a traffic profile:

Access: Admin/Discovery Admin

Step 1 You have two options:

- To save the profile without activating it, click Save .

- To save the profile and start collecting data immediately, click Save & Activate .

Activating and Deactivating Traffic Profiles

License: FireSIGHT

When you want it to begin profiling the traffic on a monitored network segment, you must activate a traffic profile.

Deactivate a profile when you want it to stop collecting and evaluating connection data. Rules written against deactivated traffic profiles do not trigger. In addition, deactivating a traffic profile deletes all data collected and aggregated by the profile. If you later reactivate a deactivated traffic profile, you must wait the length of its PTW before rules written against it will trigger.

To activate or deactivate a traffic profile:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

Step 2 You have two options:

- To activate an inactive traffic profile, click Activate next to the profile.

- To deactivate an active traffic profile, click Deactivate next to the profile. Confirm that you want to deactivate the profile by clicking OK .

Editing a Traffic Profile

License: FireSIGHT

You cannot substantially edit an active traffic profile; if the traffic profile is active you can only change its name and description. To edit a traffic profile’s conditions options, you must first deactivate it. Note that deactivating a traffic profile deletes all the data it has collected.

For more information on activating and deactivating traffic profiles, see Activating and Deactivating Traffic Profiles.

To edit a traffic profile:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

Step 2 Next to the traffic profile you want to edit, click Edit.

The Create Profile page appears.

Step 3 Make changes to the profile and click Save.

Your profile is updated.

Understanding Condition-Building Mechanics

License: FireSIGHT

You build traffic profiles by specifying the conditions they use to collect data. You can create either simple conditions or more elaborate constructs with nested conditions.

The syntax you can use within conditions varies depending on the element you are creating, but the mechanics are the same. For more information, see:

- Building a Single Condition

- Adding and Linking Conditions

- Using Multiple Values in a Condition

Building a Single Condition

License: FireSIGHT

Most conditions have three parts: a category, an operator, and a value. Some conditions are more complex and contain several categories, each of which may have their own operators and values.

For example, the following traffic profile collects information on the 10.4.x.x network. The category of the condition is Initiator/Responder IP, the operator is is in, and the value is 10.4.0.0/16.

The following steps explain how to build this traffic profile condition.

To build a single condition:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

Step 2 Click New Profile.

The Create Profile page appears.

Step 3 Under Profile Conditions, begin building the profile’s single condition by selecting Initiator/Responder IP from the first (category) drop-down list.

Step 4 Select is in from the second (operator) drop-down list.

Tip When the category represents an IP address, choosing is in or is not in as the operator allows you to specify whether the IP address is in or is not in a range of IP addresses, as expressed in CIDR notation. For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 5 Type 10.4.0.0/16 in the text field.

The following steps explain how to build this host profile qualification.

To build this host profile qualification:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

Step 2 Click New Profile.

The Create Profile page appears.

Step 3 Click Add Host Profile Qualification.

Step 4 Under Host Profile Qualification, in the first condition, specify the host whose information you want to collect.

In this example, select Responder Host because we only want information on responding hosts in a connection.

Step 5 Begin specifying the details of the operating system of the host by choosing the Operating System category.

Three subcategories appear: OS Vendor, OS Name, and OS Version.

Step 6 To specify that the host can be running any version of Microsoft Windows, use the same operator for all three subcategories: is.

Step 7 Finally, specify the values for the subcategories.

Select Microsoft as the value for OS Vendor, Windows as the value for OS Name, and leave any as the value for OS Version.

Note that the categories you can choose from depend on whether you are building traffic profile conditions or a host profile qualification. In addition, a condition’s available operators depend on the category you choose. Finally, the syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you must type the value in a text field. Other times, you can pick a value from a drop-down list.

Note Where the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For more information, see Using Multiple Values in a Condition.

For information on the syntax for building traffic profile conditions and host profile qualifications, see:

- Syntax for Traffic Profile Conditions

- Syntax for Host Profile Qualifications

Adding and Linking Conditions

License: FireSIGHT

You can create simple traffic profile conditions and host profile qualifications, or you can create more elaborate constructs by combining and nesting conditions.

When your construct includes more than one condition, you must link them with an AND or an OR operator. Conditions on the same level are evaluated together:

- The AND operator requires that all conditions on the level it controls must be met.

- The OR operator requires that at least one of the conditions on the level it controls must be met.

For example, the following traffic profile contains two conditions linked by AND. This means that the traffic profile collects connection data only if both conditions are true. In this example, it collects HTTP connections for all hosts with IP addresses in the 10.4.x.x subnet.

Where...

Is the condition that states...

A

Application Protocol Name is HTTP

B

IP Address is in 10.4.0.0/16

C

IP Address is in 192.168.0.0/16

To add a single condition:

Access: Admin/Discovery Admin

Step 1 To add a single condition, click Add condition above the current condition.

A new condition is added to the same logical level as the current set of conditions. By default, it is linked to the conditions on its level with the OR operator, though you can change the operator to AND.

For example, if you add a simple condition to the following host profile qualification:

To add a complex condition:

Access: Admin/Discovery Admin

Step 1 Click Add complex condition above the current condition.

A complex condition is added below the current set of conditions. The complex condition comprises two subconditions, which are linked to each other with the opposite operator from the one used to link the conditions on the level above it.

For example, if you add a complex condition to the following host profile qualification:

To link conditions:

Access: Admin/Discovery Admin

Step 1 Use the drop-down list to the left of a set of conditions:

- To require that all conditions on the level that the operator controls are met, select AND .

- To require that only one of the conditions on the level that the operator controls is met, select OR .

Using Multiple Values in a Condition

License: FireSIGHT

When you are building a condition, and the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For example, if you want to add a host profile qualification to a traffic profile that requires that a host be running some flavor of UNIX, instead of constructing multiple conditions linked with the OR operator, use the following procedure.

To include multiple values in one condition:

Access: Admin/Discovery Admin

Step 1 Build a condition, choosing is in or is not in as the operator.

The drop-down list changes to a text field.

Step 2 Click anywhere in the text field or on the Edit link.

A pop-up window appears.

Step 3 Under Available, use Ctrl or Shift while clicking to select multiple values. You can also click and drag to select multiple adjacent values.

Step 4 Click the right arrow (>) to move the selected entries to Selected.

Step 5 Click OK.

Your selections appear in the value field of your condition on the Create Profile page.

Viewing Traffic Profiles

License: FireSIGHT

Because traffic profiles are based on connection data, you can view graphs of traffic profiles. The following graphic shows a traffic profile with a PTW of one week, a sampling rate of five minutes, and a daily half-hour inactive period from midnight to 12:30 AM.

You can perform almost all the same actions on traffic profile graphs that you can perform on connection data graphs. However, because traffic profiles are based on aggregated data (connection summaries), you cannot examine the individual connection events on which the graphs are based. In other words, you cannot drill down to a connection data table view from a traffic profile graph. See Viewing Connection and Security Intelligence Data for more information. In addition, traffic profiles appear as detached graphs. For more information, see Detaching Connection Graphs.

In addition, traffic profile graphs plotted over time show the mean (average) y-axis value as a bold horizontal line. Graphs over time also plot the values of the first four standard deviations above and below the mean, assuming that network traffic is distributed normally. By default, these statistics are calculated over the PTW, but if you alter the time settings for a graph, the Defense Center recalculates the statistics. Rules written against traffic profile statistics, however, are always evaluated against the statistics for the PTW.

To view a traffic profile graph for a traffic profile:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation, then click Traffic Profiles.

The Traffic Profiles page appears.

).

The graph for the traffic profile appears in a separate browser window.

Configuring Remediations

When a correlation policy violation occurs, you can configure the FireSIGHT System to initiate one or multiple responses, which include remediations (such as running an Nmap scan) and various types of alerts.

The most basic kind of response you can launch is an alert. Alerts notify you, via email, a SNMP trap server, or syslog, of a policy violation. For information on creating alerts, see Configuring External Alerting.

Another kind of response you can launch is a remediation. A remediation is a program that the Defense Center runs when your network traffic violates a correlation policy. The FireSIGHT System ships with predefined remediations, which perform actions such as blocking a host at the firewall or router when it violates a policy or scanning the host.

When the Defense Center launches a remediation, it generates a remediation status event. You can search, view, and delete remediation status events, as you would any other event.

The FireSIGHT System also provides a flexible API that allows you to create custom remediation modules to respond to correlation policy violations. For example, if you are running a Linux-based firewall, you could write and upload a remediation module that dynamically updates the iptables file on the Linux server so that traffic violating a correlation policy is blocked. For more information about writing your own remediation modules, refer to the Cisco Remediation API Guide.

Note You must use a Defense Center to configure and use remediations.

For more information, see:

- Creating Remediations

- Working with Remediation Status Events

Creating Remediations

License: FireSIGHT

In addition to alerts, which are simple notifications of a correlation policy violation, you can also configure responses called remediations. Remediations are programs that the Defense Center runs when a correlation policy is violated. These programs use information provided in the event that triggered the violation to perform a specific action.

The FireSIGHT System ships with several predefined remediation modules:

- The Cisco IOS Null Route module, which, if you are running Cisco routers that use Cisco IOS® Version 12.0 or higher, allows you to dynamically block traffic sent to an IP address or network that violates a correlation policy.

See Configuring Remediations for Cisco IOS Routers for more information.

- The Cisco PIX Shun module, which, if you are running Cisco PIX® Firewall Version 6.0 or higher, allows you to dynamically block traffic sent from an IP address that violates a correlation policy.

See Configuring Remediations for Cisco PIX Firewalls for more information.

- The Nmap Scanning module, which allows you to actively scan specific targets to determine operating systems and servers running on those hosts.

See Configuring Nmap Remediations for more information.

- The Set Attribute Value module, which allows you to set a host attribute on a host where a correlation event occurs.

See Configuring Set Attribute Remediations.

You can create multiple instances for each remediation module, where each instance represents a connection to a specific appliance. For example, if you have four Cisco IOS routers where you want to send remediations, you should configure four instances of the Cisco IOS remediation module.

When you create an instance, you specify the configuration information necessary for the Defense Center to establish a connection with the appliance. Then, for each configured instance, you add remediations that describe the actions you want the appliance to perform when a policy is violated.

After they are configured, you can add remediations to what are called response groups, or you can assign the remediations specifically to rules within correlation policies. When the system executes these remediations, it generates a remediation status event, which includes details such as the remediation name, the policy and rule that triggered it, and the exit status message. For more information on these events, see Working with Remediation Status Events.

In addition to the default modules that Cisco provides, you can write custom remediation modules that perform other specific tasks when policy violations trigger. Refer to the Remediation API Guide for more information about writing your own remediation modules and installing them on the Defense Center. If you are installing a custom module, you can use the Modules page to install, view, and delete new modules.

To install a new module on the Defense Center:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Modules.

The Modules page appears.

Step 2 Click Browse to navigate to the location where you saved the file that contains the custom remediation module (refer to the Remediation API Guide for more information).

Step 3 Click Install.

The custom remediation module installs.

To view or delete a module from the Defense Center:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Modules.

The Modules page appears.

Step 2 Perform one of the following actions:

- Click View to view the module.

The Module Detail page appears.

- Click Delete next to the module you want to delete. You cannot delete default modules provided by Cisco.

The remediation module is deleted.

Configuring Remediations for Cisco IOS Routers

License: FireSIGHT

Cisco provides a Cisco IOS Null Route remediation module that allows you to block a single IP address or an entire block of addresses using Cisco’s “null route” command when a correlation policy is violated. This forwards all traffic sent to the host or network listed as the source or destination host in the event that violated the correlation policy to the router’s NULL interface, causing it to be dropped (note that this will not block traffic sent from the violating host or network).

The Cisco IOS Null Route remediation module supports Cisco routers running Cisco IOS 12.0 and higher. You must have level 15 administrative access to the router to execute Cisco IOS remediations.

Note A destination-based remediation only works if you configure it to launch when a correlation rule that is based on a connection event or intrusion event triggers. Discovery events only transmit source hosts.

Caution When a Cisco IOS remediation is activated, there is no timeout period. To remove the blocked IP address or network from the router, you must manually clear the routing change from the router itself.

To create remediations for routers running Cisco IOS:

Access: Admin/Discovery Admin

Step 1 Enable Telnet on the Cisco router.

Refer to the documentation provided with your Cisco router or IOS software for more information about enabling Telnet.

Step 2 On the Defense Center, add a Cisco IOS Null Route instance for each Cisco IOS router you plan to use with the Defense Center.

See Adding a Cisco IOS Instance for the procedures.

Step 3 Create specific remediations for each instance, based on the type of response you want to elicit on the router when correlation policies are violated.

Each available remediation type is described in the following sections:

- Cisco IOS Block Destination Remediations

- Cisco IOS Block Destination Network Remediations

- Cisco IOS Block Source Remediations

- Cisco IOS Block Source Network Remediations

Step 4 Begin assigning Cisco IOS remediations to specific correlation policy rules.

Adding a Cisco IOS Instance

License: FireSIGHT

After you configure Telnet access on the Cisco IOS router (refer to the documentation provided with your Cisco router or IOS software for more information about enabling Telnet access), you can add an instance to the Defense Center. If you have multiple routers where you want to send remediations, you must create a separate instance for each router.

To add a Cisco IOS instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 From the Add a New Instance list, select Cisco IOS Null Route (v1.0) and click Add.

The Edit Instance page appears.

Step 3 In the Instance Name field, enter a name for the instance.

The name you choose should contain no spaces or special characters and should be descriptive. For example, if you intend to connect more than one Cisco IOS router, you will have multiple instances, so you may want to choose a name such as IOS_01 and IOS_02.

Step 4 In the Router IP field, enter the IP address of the Cisco IOS router you want to use for the remediation.

Step 5 In the Username field, enter the Telnet user name for the router. This user must have level 15 administrative access on the router.

Step 6 In the Connection Password fields, enter the Telnet user’s user password. The password entered in both fields must match.

Step 7 In the Enable Password fields, enter the Telnet user’s enable password. This is the password used to enter privileged mode on the router. The password entered in both fields must match.

Step 8 In the White List field, enter IP addresses that you want to exempt from the remediation, one per line. You can also use CIDR notation or a specific IP address. For example, the following white list would be accepted by the system:

10.1.1.152

172.16.1.0/24

Note that this white list is not associated with any compliance white lists you have created. For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 9 Click Create.

The instance is created and remediations appear in the Configured Remediations section of the page. You must add specific remediations for them to be used by correlation policies. See the following sections for more information:

- Cisco IOS Block Destination Remediations

- Cisco IOS Block Destination Network Remediations

- Cisco IOS Block Source Remediations

- Cisco IOS Block Source Network Remediations

Cisco IOS Block Destination Remediations

License: FireSIGHT

The Cisco IOS Block Destination remediation allows you to block traffic sent from the router to the destination host in a correlation event.

Note Do not use this remediation as a response to a correlation rule that is based on a discovery event; discovery events only transmit a source host and not a destination host. You can use this remediation in response to correlation rules that are based on connection events or intrusion events.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

).

If you have not yet added an instance, see Adding a Cisco IOS Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Destination and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockDest.

Step 5 Optionally, in the Description field, enter a description of the remediation.

Step 6 Click Create, then click Done.

The remediation is added.

Cisco IOS Block Destination Network Remediations

License: FireSIGHT

The Cisco IOS Block Destination Network remediation allows you to block any traffic sent from the router to the network of the destination host in a correlation event.

Note Do not use this remediation as a response to a correlation rule that is based on a discovery event; discovery events only transmit a source host and not a destination host. You can use this remediation in response to correlation rules that are based on connection events or intrusion events.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Next to the instance where you want to add the remediation, click View.

If you have not yet added an instance, see Adding a Cisco IOS Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Destination Network and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockDestNet.

Step 5 Optionally, in the Description field, enter a description of the remediation.

Step 6 In the Netmask field, enter the subnet mask or use CIDR notation to describe the network that you want to block traffic to.

For example, to block traffic to an entire Class C network when a single host triggered a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask.

As another example, to block traffic to 30 addresses that include the triggering IP address, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 triggers the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 32, or enter 255.255.255.255.

Step 7 Click Create, then click Done.

The remediation is added.

Cisco IOS Block Source Remediations

License: FireSIGHT

The Cisco IOS Block Source remediation allows you to block any traffic sent from the router to the source host included in a correlation event that violates a correlation policy. The source host is the source IP address in the connection event or intrusion event upon which the correlation rule is based, or the host IP address in a discovery event.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Next to the instance where you want to add the remediation, click View.

If you have not yet added an instance, see Adding a Cisco IOS Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Source and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockSrc.

Step 5 Optionally, in the Description field, enter a description of the remediation.

Step 6 Click Create, then click Done.

The remediation is added.

Cisco IOS Block Source Network Remediations

License: FireSIGHT

The Cisco IOS Block Source Network remediation allows you to block any traffic sent from the router to the network of the source host in a correlation event. The source host is the source IP address in the connection event or intrusion event upon which the correlation rule is based, or the host IP address in a discovery event.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Next to the instance where you want to add the remediation, click View.

If you have not yet added an instance, see Adding a Cisco IOS Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Source Network and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose should contain no spaces or special characters and should be descriptive. For example, if you have multiple Cisco IOS router instances and multiple remediations for each instance, you may want to specify a name such as IOS_01_BlockSourceNet.

Step 5 Optionally, in the Description field, enter a description of the remediation.

Step 6 In the Netmask field, enter the subnet mask or CIDR notation that describes the network that you want to block traffic to.

For example, to block traffic to an entire Class C network when a single host triggered a rule (this is not recommended), use 255.255.255.0 or 24 as the netmask.

As another example, to block traffic to 30 addresses that include the triggering IP address, specify 255.255.255.224 or 27 as the netmask. In this case, if the IP address 10.1.1.15 triggers the remediation, all IP addresses between 10.1.1.1 and 10.1.1.30 are blocked. To block only the triggering IP address, leave the field blank, enter 32, or enter 255.255.255.255.

Step 7 Click Create, then click Done.

The remediation is added.

Configuring Remediations for Cisco PIX Firewalls

License: FireSIGHT

Cisco provides a Cisco PIX Shun remediation module that allows you to block an IP address or network using Cisco’s “shun” command. This blocks all traffic sent from either the source or destination host that violated the correlation policy and closes all current connections (note that this will not block traffic sent through the firewall to the host).

The Cisco PIX Shun remediation module supports Cisco PIX Firewall 6.0 and higher. You must have level 15 administrative access or higher to launch Cisco PIX remediations.

Note A destination-based remediation only works if you configure it to launch when a correlation rule that is based on a connection event or intrusion event triggers. Discovery events only transmit source hosts.

Caution When a Cisco PIX remediation is activated, no timeout period is used. To unblock the IP address or network, you must manually remove the rule from the firewall.

To create remediations for Cisco PIX firewalls:

Access: Admin/Discovery Admin

Step 1 Enable Telnet or SSH (Cisco recommends SSH) on the firewall.

Refer to the documentation provided with your Cisco PIX firewall for more information about enabling SSH or Telnet.

Step 2 On the Defense Center, add a Cisco PIX Shun instance for each Cisco PIX firewall you plan to use with the Defense Center.

See Adding a Cisco PIX Instance for the procedures.

Step 3 Create specific remediations for each instance, based on the type of response you want to elicit on the firewall when correlation policies are violated.

The available remediation types are described in the following sections:

- Cisco PIX Block Destination Remediations

- Cisco PIX Block Source Remediations

Step 4 Begin assigning Cisco PIX remediations to specific correlation policy rules.

Adding a Cisco PIX Instance

License: FireSIGHT

After you configure SSH or Telnet on the Cisco PIX firewall, you can add an instance to the Defense Center. If you have multiple firewalls you want to send remediations to, you must create a separate instance for each firewall.

Note Cisco recommends that you use an SSH connection instead of a Telnet connection. Data transmitted using SSH is encrypted, making it much more secure than Telnet.

To add a Cisco PIX instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 From the Add a New Instance list, select Cisco PIX Shun and click Add.

The Edit Instance page appears.

Step 3 In the Instance Name field, type a name for the instance.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you intend to connect more than one Cisco firewall, you will have multiple instances, so you may want to choose a name such as PIX_01, PIX_02, and so on.

Step 4 Optionally, type a description for the instance in the Description field.

Step 5 In the PIX IP field, enter the IP address of the Cisco PIX firewall you want to use for the remediation.

Step 6 If you require a specific username other than the default (pix), type it in the Username field.

Step 7 In the Connection Password fields, enter the password required to connect to the firewall using SSH or Telnet. The password entered in both fields must match.

Step 8 In the Enable Password fields, enter the SSH or Telnet enable password. This is the password used to enter privileged mode on the firewall. The password entered in both fields must match.

Step 9 In the White List field, enter IP addresses that you want to exempt from the remediation, one on each line. You can also use CIDR notation or a specific IP address. For example, the following white list is accepted by the system:

10.1.1.152

172.16.1.0/24

Note that this white list is not associated with any compliance white lists you have created. For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 10 From the Protocol list, select the method you want to use to connect to the firewall.

Step 11 Click Create.

The instance is created and remediations appear in the Configured Remediations section of the page. You must add specific remediations for them to be used in correlation policies. See the following sections for more information:

- Cisco PIX Block Destination Remediations

- Cisco PIX Block Source Remediations

Cisco PIX Block Destination Remediations

License: FireSIGHT

The Cisco PIX Block Destination remediation allows you to block traffic sent from the destination host in a correlation event.

Note Do not use this remediation as a response to a correlation rule that is based on a discovery event; discovery events only transmit a source host and not a destination host. You can use this remediation in response to correlation rules that are based on connection events or intrusion events.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Next to the instance where you want to add the remediation, click View.

If you have not yet added an instance, see Adding a Cisco PIX Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Destination and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco PIX firewall instances and multiple remediations for each instance, you may want to specify a name such as PIX_01_BlockDest.

Step 5 Optionally, in the Description field, enter a description of the remediation.

Step 6 Click Create, then click Done.

The remediation is added.

Cisco PIX Block Source Remediations

License: FireSIGHT

The Cisco PIX Block Source remediation allows you to block any traffic sent from the source host included in the event that violates a correlation policy. The source host is the source IP address in the connection event or intrusion event upon which the correlation rule is based, or the host IP address in a discovery event.

To add the remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Next to the instance where you want to add the remediation, click View.

If you have not yet added an instance, see Adding a Cisco PIX Instance.

The Edit Instance page appears.

Step 3 In the Configured Remediations section, select Block Source and click Add.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, enter a name for the remediation.

The name you choose cannot contain spaces or special characters and should be descriptive. For example, if you have multiple Cisco PIX firewall instances and multiple remediations for each instance, you may want to specify a name such as PIX_01_BlockSrc.

Step 5 Optionally, in the Description field, enter a description of the remediation.

The remediation is added.

Configuring Nmap Remediations

License: FireSIGHT

You can respond to a correlation event by scanning the host where the triggering event occurred. You can choose to scan only the port from the event that triggered the correlation event.

To set up Nmap scanning in response to a correlation event, you must first create an Nmap scan instance, then add an Nmap scan remediation. You can then configure Nmap scanning as responses to violations of rules within the policy.

See the following sections:

- Adding an Nmap Scan Instance

- Nmap Scan Remediations

Adding an Nmap Scan Instance

License: FireSIGHT

You can set up a separate scan instance for each Nmap module that you want to use to scan hosts on your network for operating system and server information. You can set up scan instances for the local Nmap module on your Defense Center and for any managed devices you want to use to run scans remotely. The results of each scan are always stored on the Defense Center where you configure the scan, even if you run the scan from a remote managed device. To prevent accidental or malicious scanning of mission-critical hosts, you can create a blacklist for the instance to indicate the hosts that should never be scanned with the instance.

Note that you cannot add a scan instance with the same name as any existing scan instance.

To create a scan instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Select Nmap Remediation (v1.0) from the Add a module type drop-down list and click Add.

The Edit Instance page appears.

Step 3 In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 4 In the Description field, specify a description that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Step 5 Optionally, in the Black Listed Scan hosts field, specify any hosts or networks that should never be scanned with this scan instance, using the following syntax:

- For IPv6 hosts, an exact IP address (for example, 2001:DB8::fedd:eeff )

- For IPv4 hosts, an exact IP address (for example, 192.168.1.101 ) or an IP address block using CIDR notation (for example, 192.168.1.0/24 scans the 254 hosts between 192.168.1.1 and 192.168.1.254 , inclusive)

If you specifically target a scan to a host that is in a blacklisted network, that scan will not run. For information on using CIDR notation in the FireSIGHT System, see IP Address Conventions.

Step 6 Optionally, to run the scan from a remote managed device instead of the Defense Center, specify the name or IP address of the managed device in the Remote Device Name field.

Step 7 Click Create.

The scan instance is created.

Nmap Scan Remediations

License: FireSIGHT

You can define the settings for an Nmap scan by creating an Nmap remediation. An Nmap remediation can be used as a response in a correlation policy, run on demand, or scheduled to run at a specific time. In order for the results of an Nmap scan to appear in the network map, the scanned host must already exist in the network map. Note that NetFlow, the host input feature, and the system itself can add hosts to the network map.

For more information on the specific settings in an Nmap remediation, see Understanding Nmap Remediations.

Note that Nmap-supplied server and operating system data remains static until you run another Nmap scan. If you plan to scan a host for operating system and server data using Nmap, you may want to set up regularly scheduled scans to keep any Nmap-supplied operating system and server data up-to-date. For more information, see Automating Nmap Scans. Also note that if the host is deleted from the network map, any Nmap scan results for that host are discarded.

For general information about Nmap functionality, refer to the Nmap documentation at http://insecure.org.

To create a Nmap remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Scanners.

The Scanners page appears.

Step 2 Click Add Remediation next to the scan instance where you want to add a remediation.

The Edit Remediation page appears.

Step 3 In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 4 In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Step 5 If you plan to use this remediation in response to a correlation rule that triggers on an intrusion event, a connection event, or a user event, configure the Scan Which Address(es) From Event? option.

- Select Scan Source and Destination Addresses to scan the hosts represented by the source IP address and the destination IP address in the event.

- Select Scan Source Address Only to scan the host represented by the event’s source IP address.

- Select Scan Destination Address Only to scan the host represented by the event’s destination IP address.

If you plan to use this remediation in response to a correlation rule that triggers on a discovery event or a host input event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option.

Note Do not assign a Nmap remediation as a response to a correlation rule that triggers on a traffic profile change.

Step 6 Configure the Scan Type option:

- To scan quickly in stealth mode on hosts where the admin account has raw packet access or where IPv6 is not running, by initiating TCP connections but not completing them, select TCP Syn Scan .

- To scan by using a system connect() call, which can be used on hosts where the admin account on your Defense Center does not have raw packet access or where IPv6 is running, select TCP Connect Scan .

- To send an ACK packet to check whether ports are filtered or unfiltered, select TCP ACK Scan .

- To send an ACK packet to check whether ports are filtered or unfiltered but also determine whether a port is open or closed, select TCP Window Scan .

- To identify BSD-derived systems using a FIN/ACK probe, select TCP Maimon Scan .

Step 7 Optionally, to scan UDP ports in addition to TCP ports, select On for the Scan for UDP ports option.

Tip A UDP portscan takes more time than a TCP portscan. To speed up your scans, leave this option disabled.

Step 8 If you plan to use this remediation in response to correlation policy violations, configure the Use Port From Event option:

- Select On to scan the port in the correlation event, rather than the ports you specify in step 12 .

If you scan the port in the correlation event, note that the remediation scans the port on the IP addresses that you specified in step 8. These ports are also added to the remediation’s dynamic scan target.

- Select Off to scan only the ports you will specify in step 12 .

Step 9 If you plan to use this remediation in response to correlation policy violations and want to run the scan using the appliance running the detection engine that detected the event, configure the Scan from reporting detection engine option:

- To scan from the appliance running the reporting detection engine, select On .

- To scan from the appliance configured in the remediation, select Off .

Step 10 Configure the Fast Port Scan option:

- To only scan ports listed in the nmap-services file located in the /var/sf/nmap/share/nmap/nmap-services directory on the managed device that does the scanning, ignoring other port settings, select On .

- To scan all TCP ports, select Off .

Step 11 In the Port Ranges and Scan Order field, type the ports you want to scan by default, using Nmap syntax, in the order you want to scan those ports.

Specify values from 1 to 65535. Separate ports using commas or spaces. You can also use a hyphen to indicate a port range. When scanning for both TCP and UDP ports, preface the list of TCP ports you want to scan with a T and the list of UDP ports with a U. For example, to scan ports 53 and 111 for UDP traffic, then scan ports 21-25 for TCP traffic, enter U:53,111,T:21-25.

Note that the Use Port From Event option overrides this setting when the remediation is launched in response to a correlation policy violation, as described in step 8.

Step 12 To probe open ports for server vendor and version information, configure Probe open ports for vendor and version information:

- Select On to scan open ports on the host for server information to identify server vendors and versions.

- Select Off to continue using server information for the host.

Step 13 If you choose to probe open ports, set the number of probes used by selecting a number from the Service Version Intensity drop-down list:

- To use more probes for higher accuracy with a longer scan, select a higher number.

- To use fewer probes for less accuracy with a faster scan, select a lower number.

Step 14 To scan for operating system information, configure Detect Operating System settings:

- Select On to scan the host for information to identify the operating system.

- Select Off to continue using operating system information for the host.

Step 15 To determine whether or not host discovery occurs and whether port scans are only run against available hosts, configure Treat All Hosts As Online:

- To skip the host discovery process and run a port scan on every host in the target range, select On .

- To perform host discovery using the settings for Host Discovery Method and Host Discovery Port List and skip the port scan on any host that is not available, select Off .

Step 16 Select the method to be used when Nmap tests to see if a host is present and available:

- To send an empty TCP packet with the SYN flag set and elicit an RST response on a closed port or a SYN/ACK response on an open port on available hosts, select TCP SYN .

Note that this option scans port 80 by default and that TCP SYN scans are less likely to be blocked by a firewall with stateful firewall rules.

- To send an empty TCP packet with the ACK flag set and elicit an RST response on available hosts, select TCP ACK.

Note that this option scans port 80 by default and that TCP ACK scans are less likely to be blocked by a firewall with stateless firewall rules.

- To send a UDP packet to elicit port unreachable responses from closed ports on available hosts, select UDP . This option scans port 40125 by default.

Step 17 If you want to scan a custom list of ports during host discovery, type a list of ports appropriate for the host discovery method you selected, separated by commas, in Host Discovery Port List.

Step 18 Configure the Default NSE Scripts option to control whether to use the default set of Nmap scripts for host discovery and server, operating system, and vulnerability discovery:

- To run the default set of Nmap scripts, select On .

- To skip the default set of Nmap scripts, select Off .

See http://nmap.org/nsedoc/categories/default.html for the list of default scripts.

Step 19 To set the timing of the scan process, select a timing template number; select a higher number for a faster, less comprehensive scan and a lower number for a slower, more comprehensive scan.

Step 20 Click Save, then click Done.

The remediation is created.

Configuring Set Attribute Remediations

License: FireSIGHT

You can respond to a correlation event by setting a host attribute value on the host where the triggering event occurred. For text host attributes, you can choose to use the description from the event as the attribute value. For more information on host attributes, see Working with the Predefined Host Attributes and Working with User-Defined Host Attributes.

To configure setting an attribute value in response to a correlation event, you must first create a set attribute instance, then add a set attribute remediation. You can then configure attribute value updates as responses to violations of rules within the policy.

For more information, see the following sections:

- Adding a Set Attribute Value Instance

- Set Attribute Value Remediations

Adding a Set Attribute Value Instance

License: FireSIGHT

You can set up an instance to set attribute values in response to correlation rule violations.

To create a set attribute instance:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Select Set Attribute Value (v1.0) from the Add a module type drop-down list and click Add.

The Edit Instance page appears.

Step 3 In the Instance Name field, enter a name that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 4 In the Description field, specify a description that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Step 5 Click Create.

The instance is created.

Set Attribute Value Remediations

License: FireSIGHT

You can create a set attribute value remediation for each attribute value you want to be able to set in response to a correlation rule violation. If the attribute you want to set is a text attribute, you can set the remediation to use the description from the event as the attribute value.

To create a set attribute value remediation:

Access: Admin/Discovery Admin

Step 1 Select Policies > Actions > Instances.

The Instances page appears.

Step 2 Click View next to the scan instance where you want to add a remediation.

The Edit Instance page appears.

Step 3 Select Set Attribute Value from the Add a new remediation of type drop-down list.

The Edit Remediation page appears.

Step 4 In the Remediation Name field, type a name for the remediation that includes 1 to 63 alphanumeric characters, with no spaces and no special characters other than underscore (_) and dash (-).

Step 5 In the Description field, type a description for the remediation that includes 0 to 255 alphanumeric characters, including spaces and special characters.

Step 6 If you plan to use this remediation in response to a correlation rule that triggers on an intrusion event, user event, or a connection event, configure the Update Which Host(s) From Event option.

- Select Update Source and Destination Hosts to update the attribute value on the hosts represented by the source IP address and the destination IP address in the event.

- Select Update Source Host Only to update the attribute value on the host represented by the event’s source IP address.

- Select Update Destination Host Only to update the attribute value on the host represented by the event’s destination IP address.

If you plan to use this remediation in response to a correlation rule that triggers on a discovery event or host input event, by default the remediation scans the IP address of the host involved in the event; you do not need to configure this option.

Step 7 Configure the Use Description From Event For Attribute Value (text attributes only) option:

- To use the description from the event as the attribute value, select On .

- To use the Attribute Value setting for the remediation as the attribute value, select Off .

Step 8 If you are not planning to use the event description, type the attribute value you want to set in the Attribute Value field.

Step 9 Click Save, then click Done.

The remediation is created.

Working with Remediation Status Events

License: FireSIGHT

When a remediation triggers, a remediation status event is generated. These events are logged to the database and can be viewed on the Remediation Status page. You can search, view, and delete remediation status events.

For more information, see:

- Setting Event Time Constraints

- Searching for Remediation Status Events

Viewing Remediation Status Events

License: FireSIGHT

The page you see when you access remediation status events differs depending on the workflow you use. You can use the predefined workflow, which includes a table view of remediations. The table view contains a row for each remediation status event. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on a remediation status events workflow page.

Table 54-1 Options for Viewing Remediation Status Events

To...

You can...

learn more about the columns that appear

find more information in Understanding the Remediation Status Table.

modify the time and date range for displayed events

see Setting Event Time Constraints.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This can occur even if you configured a sliding time window for the appliance.

sort and constrain the events

see Constraining Events and Sorting Drill-Down Workflow Pages.

temporarily use a different workflow

click (switch workflow) by the workflow title. For more information, see Selecting Workflows.

navigate to the correlation events view to see associated events

click Correlation Events. For more information, see Navigating Between Workflows.

bookmark the current page so that you can quickly return to it

click Bookmark This Page. For more information, see Using Bookmarks.

navigate to the bookmark management page

click View Bookmarks. For more information, see Using Bookmarks.

generate a report based on the data in the table view

click Report Designer. For more information, see Creating a Report Template from an Event View.

drill down to the next page in the workflow, constraining on a specific value

use one of the following methods:

- on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some users, select the check boxes next to the users you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.
For more information, see Constraining Events.

delete remediation status events from the system

use one of the following methods:

- To delete some events, select the check boxes next to events you want to delete, then click Delete .

- To delete all events in the current constrained view, click Delete All , then confirm you want to delete all the events.

search for remediation status events

click Search. For more information, see Searching for Remediation Status Events.

To view remediation status events:

Access: Admin

Step 1 Select Analysis > Correlation > Status.

The first page of the default remediations workflow appears. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of remediations, click (switch workflow) menu by the workflow title, then select Remediation Status.

Working with Remediation Status Events

License: FireSIGHT

You can change the layout of the event view or constrain the events in the view by a field value.

When you disable a column, it is disabled for the duration of your session (unless you add it back later). Note that when you disable the first column, the Count column is added.

Clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

Tip Table views always include “Table View” in the page name.

For more information, see the following topics:

- Constraining Events.

- Using Compound Constraints.

- Sorting Drill-Down Workflow Pages.

- Understanding the Remediation Status Table

Understanding the Remediation Status Table

License: FireSIGHT

You can configure the Defense Center to launch a variety of responses to policy violations and to discovery events. These responses include remediations, such as blocking a host at the firewall or router when it violates a policy. When a remediation triggers, a remediation status event is generated and logged to the database. For more information on remediations, see Configuring Remediations.

The fields in the remediation status table are described in the following table.

Table 54-2 Remediation Status Fields

Field

Description

Policy

The name of the correlation policy that was violated and triggered the remediation.

Remediation Name

The name of the remediation that was launched.

Result Message

A message that describes what happened when the remediation was launched. Status messages include:

- Successful completion of remediation

- Error in the input provided to the remediation module

- Error in the remediation module configuration

- Error logging into the remote device or server

- Unable to gain required privileges on remote device or server

- Timeout logging into remote device or server

- Timeout executing remote commands or servers

- The remote device or server was unreachable

- The remediation was attempted but failed

- Failed to execute remediation program

- Unknown/unexpected error

Note If custom remediation modules are installed, you may see additional status messages that are implemented by the custom module.

Rule

The name of the rule that triggered the remediation.

Time

The date and time that the Defense Center launched the remediation

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

To display the table view of remediation status events:

Access: Admin

Step 1 Select Analysis > Correlation > Status.

The table view appears. For information on working with remediation status events, see Working with Remediation Status Events.

Tip If you are using a custom workflow that does not include the table view of remediation status events, click (switch workflow) by the workflow title, then click Remediation Status.

Searching for Remediation Status Events

License: FireSIGHT

You can search for remediation status events to determine when and if a particular remediation was launched. You may want to create searches customized for your network environment, then save them to reuse later. The search criteria you can use are described in the following table.

Table 54-3 Remediation Status Search Criteria

Search Field

Description

Result Message

Enter the exact name of the result message (a message that describes what happened when the remediation was launched) you want to match. Valid status messages are:

- Successful completion of remediation

- Error in the input provided to the remediation module

- Error in the remediation module configuration

- Error logging into the remote device or server

- Unable to gain required privileges on remote device or server

- Timeout logging into remote device or server

- Timeout executing remote commands or servers

- The remote device or server was unreachable

- The remediation was attempted but failed

- Failed to execute remediation program

- Unknown/unexpected error

Note If you installed custom remediation modules, you may be able to enter additional status messages implemented by the custom module.

Time

Specify the date and time the Defense Center launched the remediation. See Specifying Time Constraints in Searches for the syntax for entering time.

Remediation Name

Enter the exact name of the remediation that was launched. This is the name you specified when you created the remediation.

Policy

Enter the name of the correlation policy that triggered the remediation.

Rule

Enter the name of the correlation rule that triggered the remediation.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

To search for remediation status events:

Access: Admin

Step 1 Select Analysis > Search.

The search page appears.

Step 2 From the table drop-down menu, select Remediation Status.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields, as described in the Remediation Status Search Criteria table.

If you enter criteria for multiple fields, the search returns only the records that match search criteria specified for all fields.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to save a search as a restriction for restricted event analyst users, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default remediation status workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Using Dashboards

The FireSIGHT System dashboard provides you with at-a-glance views of current system status, including data about the events collected and generated by the system. You can also use the dashboard to see information about the status and overall health of the appliances in your deployment. Only certain user roles (Administrator, Maintenance User, Security Analyst, Security Analyst [Read Only], and custom roles with the Dashboards permission) have access to the dashboard. Other roles see as their default start pages a page relevant to the role; for example, a Discovery Admin sees the Network Discovery page.

A dashboard has one or more tabs, each of which can display one or more widgets in a three-column layout. Widgets are small, self-contained components that provide insight into different aspects of the FireSIGHT System. The FireSIGHT System is delivered with several predefined widgets. For example, the Appliance Information widget tells you the appliance name, model, remote manager, and currently running version of the FireSIGHT System software.

The dashboard has a time range that constrains its widgets. You can change the time range to reflect a period as short as the last hour or as long as the last year.

The dashboard is a complex, highly customizable monitoring feature. Another way to view many types of system data is the Context Explorer, which presents information using intrusion, connection, and discovery data in a set of preset visual contexts that you change, only temporarily, with filters to add granularity. In contrast to the exhaustive data available in the FireSIGHT System dashboard, the Context Explorer offers a broad, brief, and colorful picture of how your monitored network looks and acts. For more information on the Context Explorer, see Using the Context Explorer.

Each type of appliance is delivered with a default dashboard, named Summary Dashboard. This dashboard provides the casual user with general FireSIGHT, intrusion, threat detection, geolocation, and system status information for your FireSIGHT System deployment. Note that because some widgets are useful only for specific types of appliances, the Summary Dashboard differs depending on whether you are using a Defense Center, virtual Defense Center, or managed device.

Note Virtual managed devices do not have a web interface and do not support dashboards.

By default, the home page for your appliance displays the Summary Dashboard, although you can configure your appliance to display a different default home page.

Tip If you change the home page, you can access dashboards by selecting Overview > Dashboards. For more information, see Viewing Dashboards.

Note that the data displayed depends on such factors as how you license and deploy your managed devices, whether you configure features that provide the data and, in the case of Series 2 appliances and Cisco NGIPS for Blue Coat X-Series, whether the appliance supports a feature that provides the data. For example, because neither the DC500 Defense Center nor Series 2 devices support URL filtering by category and reputation, the DC500 Defense Center does not display data for this feature and Series 2 devices do not detect this data.

In addition to the Summary Dashboard, the Defense Center is delivered with the following predefined dashboards:

- The Application Statistics dashboard provides detailed information about application activity and intrusion events on your monitored network. You can use this dashboard to track which applications produce the most traffic, allowed and denied connections, and intrusion events, as well as the number of unique applications in use and the estimated risk and business relevance of those applications.

- The Connection Summary dashboard uses connection data to create tables and charts of the activity on your monitored network. You can use this dashboard to track the ports, applications, and initiator and responder IPs associated with connections and traffic on your network, the overall volume of connections and traffic, and geolocation information. You must log connections for this dashboard to generate data; see Understanding Connection and Security Intelligence Data. Note that the output of this widget depends on your connection logging configuration.

Tip Widgets on this dashboard list total traffic in kilobytes (KB). The total traffic in KB is equal to the traffic in KB/s multiplied by the total seconds covered by the selected time window.

- The Detailed Dashboard provides advanced users with detailed information about their FireSIGHT System deployment and includes multiple widgets that summarize collected intrusion event, network discovery, compliance, correlation, traffic, and system status data, as well as providing information about Cisco news and product updates. You can use this dashboard to monitor a very broad variety of network information at once.

- The Files Dashboard provides detailed information about the files (including malware files) detected on your network by managed devices, captured files stored on devices and submitted for dynamic analysis, and malware detected using a subscription-based FireAMP strategy. Note that you must have a Malware license and enable malware detection for this dashboard to include network-based malware data. Also, neither the DC500 nor Series 2 devices or Cisco NGIPS for Blue Coat X-Series support advanced malware protection, so the DC500 cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. For more information, see Understanding Malware Protection and File Control.

- The URL Statistics dashboard provides detailed information about allowed and denied traffic from your monitored network to external URLs, sorted by URL category and reputation. Note that you must have a URL Filtering license and enable URL Filtering for this dashboard to include URL category and reputation data. Note also that neither the DC500 nor Series 2 devices support URL filtering by reputation and category, so the DC500 cannot display this data and Series 2 devices do not detect it. See Performing Reputation-Based URL Blocking.

- The Access Controlled User Statistics dashboard provides detailed information about user activity and intrusion events on your monitored network. You can use this dashboard to track allowed and denied connections, traffic, and intrusion events associated with users on your network, as well as the number of unique users on the network. Because this dashboard depends on user awareness data, for this dashboard to display meaningful statistics you must configure at least one User Agent and a Defense Center-Active Directory LDAP server connection; see Using User Agents to Report Active Directory Logins.

You can use the predefined dashboards, modify the predefined dashboards, or create a custom dashboard to suit your needs. You can share custom dashboards among all users of an appliance, or you can create a custom dashboard solely for your own use. You can also set a custom dashboard as your default dashboard.

Some drill-down pages and table views of events include a Dashboard toolbar link that you can click to view a relevant predefined dashboard. The following table lists which event views correspond to which predefined dashboards. Note that if you delete a predefined dashboard or tab, the associated Dashboard links do not function.

Table 55-1 Event Table Dashboard Links

Table

Dashboard Link

Connection Events

(Analysis > Connections > Events)

Connection Summary

Security Intelligence Events

(Analysis > Connections > Security Intelligence)

Connection Summary

Intrusion Events

(Analysis > Intrusions > Events)

Summary (Intrusion Events tab)

Malware Events

(Analysis > Files > Malware Events)

Files (Malware tab)

File Events

(Analysis > Files > File Events)

Files (Files tab)

Captured Files

(Analysis > Files > Captured Files)

Files (File Storage tab)

Applications

(Analysis > Hosts > Applications)

Application Statistics

Application Details

(Analysis > Hosts > Application Details)

Application Statistics

Indications of Compromise

(Analysis > Hosts > Indications of Compromise)

Summary (Threats tab)

Users

(Analysis > Users > Users)

Access Controlled User Statistics

User Activity

(Analysis > Users > User Activity)

Access Controlled User Statistics

Correlation Events

(Analysis > Correlation > Correlation Events)

Detailed (Correlation tab)

White List Events

(Analysis > Correlation > White List Events)

Detailed (Correlation tab)

For more information on dashboards and their contents, see the following sections:

- Understanding Dashboard Widgets

- Understanding the Predefined Widgets

- Working with Dashboards

Understanding Dashboard Widgets

License: Any

A dashboard has one or more tabs, each of which can display one or more widgets in a three-column layout. The FireSIGHT System is delivered with many predefined dashboard widgets, each of which provides insight into a different aspect of the FireSIGHT System. Widgets are grouped into three categories:

- Analysis & Reporting widgets display data about the events collected and generated by the FireSIGHT System.

- Miscellaneous widgets display neither event data nor operations data. Currently, the only widget in this category displays an RSS feed.

- Operations widgets display information about the status and overall health of the FireSIGHT System.

The dashboard widgets that you can view depend on the type of appliance you are using and on your user role. In addition, each dashboard has a set of preferences that determines its behavior. You can minimize and maximize widgets, add and remove widgets from tabs, as well as rearrange the widgets on a tab.

Note For widgets that display event counts over a time range, the total number of events may not reflect the number of events for which detailed data is available in the event viewer. This occurs because the system sometimes prunes older event details to manage disk space usage. To minimize the occurrence of event detail pruning, you can fine-tune event logging to log only those events most important to your deployment. For more information, see Logging Connections in Network Traffic.

For more information, see:

- Understanding Widget Availability

- Understanding Widget Preferences

- Understanding the Predefined Widgets

- Working with Dashboards

Understanding Widget Availability

License: Any

The FireSIGHT System is delivered with several predefined dashboard widgets. The dashboard widgets that you can view depend on the type of appliance you are using and on your user role:

- An invalid widget is one that you cannot view because you are using the wrong type of appliance.

- An unauthorized widget is one that you cannot view because you do not have the necessary account privileges.

For example, the Current Sessions widget is available on all appliances, but only to users with Administrator account privileges, while the Appliance Status widget is available only on the Defense Center for users with Administrator, Maintenance User, Security Analyst, or Security Analyst (Read Only) account privileges.

Although you cannot add an unauthorized or invalid widget to a dashboard, if you import a dashboard created either on a different kind of appliance or by a user with different access privileges, that dashboard may contain unauthorized or invalid widgets. These widgets are disabled and display error messages that indicate the reason why you cannot view them.

Also note that widgets cannot display data to which an appliance has no access. For example, managed devices cannot access correlation events, intrusion events, discovery events, and so on. If you import a dashboard onto a managed device that contains a Custom Analysis widget configured to display one of those data types, the widget displays an error message. Individual widgets also display error messages when those widgets have timed out or are otherwise experiencing problems.

The content of a widget can differ depending on the type of appliance you are using. For example, the Custom Analysis widget on a Defense Center can display discovery information, but this feature is not available when you configure the Custom Analysis widget on a managed device. Note than you can sort any content generated in table format by clicking on the table column header.

You can delete or minimize unauthorized and invalid widgets, as well as widgets that display no data, keeping in mind that modifying a widget on a shared dashboard modifies it for all users of the appliance. For more information, see Minimizing and Maximizing Widgets and Deleting Widgets.

Table 55-2 FirePOWER Appliances and Dashboard Widget Availability

Widget

Defense Center

Any Managed Device

Appliance Information

yes

yes

Appliance Status

yes

no

Correlation Events

yes

no

Current Interface Status

yes

yes

Current Sessions

yes

yes

Custom Analysis

yes

no

Disk Usage

yes

yes

Interface Traffic

yes

yes

Intrusion Events

yes

no

Network Compliance

yes

no

Product Licensing

yes

no

Product Updates

yes

yes

RSS Feed

yes

yes

System Load

yes

yes

System Time

yes

yes

White List Events

yes

no

The following table lists the user account privileges required to view each widget. Only user accounts with Administrator, Maintenance User, Security Analyst, or Security Analyst (Read Only) access can use dashboards.

Table 55-3 User Roles and Dashboard Widget Availability

Widget

Administrator

Maintenance User

Security Analyst

Security Analyst (RO)

Appliance Information

yes

yes

yes

yes

Appliance Status

yes

yes

yes

no

Correlation Events

yes

no

yes

yes

Current Interface Status

yes

yes

yes

yes

Current Sessions

yes

no

no

no

Custom Analysis

yes

no

yes

yes

Disk Usage

yes

yes

yes

yes

Interface Traffic

yes

yes

yes

yes

Intrusion Events

yes

no

yes

yes

Network Compliance

yes

no

yes

yes

Product Licensing

yes

yes

no

no

Product Updates

yes

yes

no

no

RSS Feed

yes

yes

yes

yes

System Load

yes

yes

yes

yes

System Time

yes

yes

yes

yes

White List Events

yes

no

yes

yes

Understanding Widget Preferences

License: Any

Each widget has a set of preferences that determines its behavior.

Widget preferences can be simple. For example, the following graphic shows the preferences for the Current Interface Status widget, which displays the current status of all enabled interfaces on the internal network. You can only configure the update frequency for this widget.

Widget preferences can also be more complex. For example, the following graphic shows the preferences for the Custom Analysis widget, which is a highly customizable widget that allows you to display detailed information on the events collected and generated by the FireSIGHT System.

To modify a widget’s preferences:

Access: Admin/Any Security Analyst/Maint

).

The preferences section for that widget appears.

Step 2 Make changes as needed.

Your changes take effect immediately. For information on the preferences you can specify for individual widgets, see Understanding the Predefined Widgets.

) to hide the preferences section.

Understanding the Predefined Widgets

License: Any

The FireSIGHT System is delivered with several predefined widgets that, when used on dashboards, can provide you with at-a-glance views of current system status, including data about the events collected and generated by the system, as well as information about the status and overall health of the appliances in your deployment.

For detailed information on the widgets delivered with the FireSIGHT System, see the following sections:

- Understanding the Appliance Information Widget

- Understanding the Appliance Status Widget

- Understanding the Correlation Events Widget

- Understanding the Current Interface Status Widget

- Understanding the Current Sessions Widget

- Understanding the Custom Analysis Widget

- Understanding the Disk Usage Widget

- Understanding the Interface Traffic Widget

- Understanding the Intrusion Events Widget

- Understanding the Network Compliance Widget

- Understanding the Product Licensing Widget

- Understanding the Product Updates Widget

- Understanding the RSS Feed Widget

- Understanding the System Load Widget

- Understanding the System Time Widget

- Understanding the White List Events Widget

Note The dashboard widgets you can view depend on the type of appliance you are using and on your user role. For more information, see Understanding Widget Availability.

Understanding the Appliance Information Widget

License: Any

The Appliance Information widget provides a snapshot of the appliance. It appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.

The widget provides:

- the name, IPv4 address, IPv6 address, and model of the appliance

- the versions of the FireSIGHT System software, operating system, Snort, rule update, rule pack, module pack, vulnerability database (VDB), and geolocation update installed on the appliances with dashboards, except for virtual Defense Centers

- for managed appliances, the name and status of the communications link with the managing appliance

- for Defense Centers in a high availability pair, the name, model, and FireSIGHT System software and operating system versions of the peer Defense Center, as well as how recently the Defense Centers made contact

You can configure the widget to display more or less information by modifying the widget preferences to display a simple or an advanced view; the preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

Understanding the Appliance Status Widget

License: Any

The Appliance Status widget indicates the health of the appliance and of any appliances it is managing. Note that because the Defense Center does not automatically apply a health policy to managed devices, you must manually apply a health policy to devices or their status appears as Disabled. This widget appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.

The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

You can click a section on the pie chart or one of the numbers on the appliance status table to go to the Health Monitor page and view the compiled health status of the appliance and of any appliances it is managing. For more information, see Using the Health Monitor.

Understanding the Correlation Events Widget

License: FireSIGHT

The Correlation Events widget shows the average number of correlation events per second, by priority, over the dashboard time range. It appears by default on the Correlation tab of the Detailed Dashboard.

Select one or more Priorities check boxes to display separate graphs for events of specific priorities, including events that do not have a priority. Select Show All to display an additional graph for all correlation events, regardless of priority. The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

You can click a graph to view correlation events of a specific priority, or click the All graph to view all correlation events. In either case, the events are constrained by the dashboard time range; accessing correlation events via the dashboard changes the events (or global) time window for the appliance. For more information on correlation events, see Viewing Correlation Events.

Understanding the Current Interface Status Widget

License: Any

The Current Interface Status widget shows the status of all interfaces on the appliance, enabled or unused. On a Defense Center, you can display the management (eth0, eth1, and so on) interfaces. On a managed device, you can choose to show only sensing (s1p1 and so on) interfaces or both management and sensing interfaces. Interfaces are grouped by type: management, inline, passive, switched, routed, stacked, and unused.

- the name of the interface

- the link state of the interface

- the link mode (for example, 100Mb full duplex, or 10Mb half duplex) of the interface

- the type of interface, that is, copper or fiber

- the amount of data received (Rx) and transmitted (Tx) by the interface

The color of the ball representing link state indicates the current status, as follows:

- green: link is up and at full speed

- yellow: link is up but not at full speed

- red: link is not up

- gray: link is administratively disabled

- blue: link state information is not available (for example, ASA)

The widget preferences control how often the widget updates. For more information, see Understanding Widget Preferences.

Understanding the Current Sessions Widget

License: Any

) and rendered in bold type. Sessions are pruned from this widget’s data within one hour of logoff or inactivity. This widget appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.

On the Current Sessions widget, you can:

- click any user name to manage user accounts on the User Management page; see Managing User Accounts

- click the host icon (

) or compromised host icon ( ) next to any IP address to view the host profile for the associated machine; see Using Host Profiles (Defense Center with network discovery only)

- click any IP address or access time to view the audit log constrained by that IP address and by the time that the user associated with that IP address logged on to the web interface; see Viewing Audit Records

The widget preferences control how often the widget updates. For more information, see Understanding Widget Preferences.

Understanding the Custom Analysis Widget

License: Any

The Custom Analysis widget is a highly customizable widget that allows you to display detailed information on the events collected and generated by the FireSIGHT System.

The Custom Analysis widget is delivered with numerous widget presets, which are groups of configurations that are predefined by Cisco. The presets serve as examples and can provide quick access to information about your deployment. You can use these presets or create a custom configuration.

When you configure the widget preferences, you must select which table and individual field you want to display, as well as the aggregation method that configures how the widget groups the data it displays.

The colored bars in the widget background show the relative number of occurrences of each event; you should read the bars from right to left. You can change the color of the bars as well as the number of rows that the widget displays. You can also configure the widget to display the most frequently occurring events or the least frequently occurring events.

) indicates and controls the sort order of the display. A downward-pointing icon indicates descending order; an upward-pointing icon indicates ascending order. To change the sort order, click the icon.

Next to each event, the widget can display one of three icons to indicate any changes from the most recent results:

- The new event icon (

) signifies that the event is new to the results.

- The up arrow icon (

) indicates that the event has moved up in the standings since the last time the widget updated. A number indicating how many places the event has moved up appears next to the icon.

- The down arrow icon (

) indicates that the event has moved down in the standings since the last time the widget updated. A number indicating how many places the event has moved down appears next to the icon.

The widget displays the last time it updated, based on the local time of the appliance. The widget updates with a frequency that depends on the dashboard time range. For example, if you set the dashboard time range to an hour, the widget updates every five minutes. On the other hand, if you set the dashboard time range to a year, the widget updates once a week. To determine when the dashboard will update next, hover your pointer over the Last updated notice in the bottom left corner of the widget.

Note If you constrain a Custom Analysis widget using a saved search, then edit the search, the widget does not reflect your changes until the next time it updates.

Finally, you can choose a custom title for the widget.

From Custom Analysis widgets, you can invoke event views (that is, workflows) that provide detailed information about the events displayed in the widget. To do so, click the event for which you want more information.

You can also right-click any IP address in the custom analysis widget to display a context menu that allows you to obtain more information on the associated host, as well as add it to the global blacklist or whitelist for Security Intelligence filtering.

Note Depending on how you configure them, Custom Analysis widgets may place a drain on an appliance’s resources; a red-shaded Custom Analysis widget indicates that its use is harming system performance. If the widget continues to stay red over time, you should remove the widget.

For more information, see the following sections:

- Configuring the Custom Analysis Widget

- Viewing Associated Events from the Custom Analysis Widget

- Custom Analysis Widget Limitations

- Using the Context Menu

Configuring the Custom Analysis Widget

License: Any

Like all widgets, the Custom Analysis widget has preferences that determine its behavior. To configure a Custom Analysis widget, show the preferences as described in Understanding Widget Preferences.

A different set of preferences appears depending on whether you configure the widget to show relative occurrences of events (that is, a bar graph), or configure the widget to show a graph over time (that is, a line graph).

To configure the widget to show a bar graph, select any value except Time from the Field drop-down list.

To configure the widget to show a line graph, select Time from the Field drop-down list.

Table 55-4 Custom Analysis Widget Preferences

Use this preference...

To control...

Title

the title of the widget.

If you do not specify a title, the appliance uses the configured event type as the widget title.

Preset

the preset for the widget.

The Custom Analysis widget is delivered with numerous presets, which are widget configurations predefined by Cisco. The presets serve as examples and can provide quick access to information about your deployment. You can use these presets or you can create a custom configuration.

For a detailed list of presets, see the Custom Analysis Widget Presets table.

Table

the table of events which contains the event data the widget displays.

Field

the specific field of the event type you want to display.
.

Aggregate

the aggregation method for the widget.

The aggregation method configures how the widget groups the data it displays. For most event types, the default aggregation criterion is Count.

Filter

a user-defined application filter that you want to use to further constrain the data that the widget displays.

You can only use application filters if you are displaying data from the Application Statistics or Intrusion Event Statistics by Application tables. For more information on application filters, see Working with Application Filters.

Search

the saved search you want to use to further constrain the data that the widget displays.

You do not have to specify a search, although some presets use predefined searches.

If you create a saved connection event search that uses data in fields without an asterisk (*), the widget displays incorrect data. Only fields that constrain connection summaries can constrain custom analysis dashboard widgets based on connection events. Invalid searches are grayed out and cannot be selected.

Show

whether you want to display the most frequently occurring events (Top) or the least frequently occurring events (Bottom).

Results

the number of result rows you want to display.

You can display from 10 to 25 result rows, in increments of five.

Show Movers

whether you want to display the icons that indicate changes from the most recent results.

Time Zone

which time zone you want to use to display results.

The time zone appears whenever you select a time-based field.

Color

the color of the bars in the widget background that show the relative number of occurrences of each result.

The following table describes the available presets for the Custom Analysis widget. It also indicates which, if any, Defense Center predefined dashboard uses each preset. Note the following:

- Predefined dashboards on managed devices do not include Custom Analysis widgets.

- The DC500 Defense Center does not display and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect data for features they do not support.

For more information on specific license types, see Service Subscriptions.

.

Table 55-5 Custom Analysis Widget Presets

Preset

Description

Predefined Dashboards

Licenses

All Intrusion Events

Displays a graph of the total number of intrusion events on your monitored network over the dashboard time range.

Detailed Dashboard

Summary Dashboard

Protection

All Intrusion Events (Not Dropped)

Displays the most frequently occurring types of intrusion events, by classification, where the packet was not dropped as part of the event.

Detailed Dashboard

Protection

Allowed Connections by Application

Displays allowed application connections on your monitored network, grouped by application.

Application Statistics

FireSIGHT

Allowed Connections by Application Risk

Displays allowed application connections on your monitored network, grouped by application risk level.

Application Statistics

FireSIGHT

Allowed Connections by Business Relevance

Displays allowed application connections on your monitored network, grouped by estimated relevance to business activity.

Application Statistics

FireSIGHT

Allowed Connections by URL Category

Displays allowed application connections on your monitored network, grouped by URL category.

URL Statistics

URL Filtering

Allowed Connections by URL Reputation

Displays allowed application connections on your monitored network, grouped by URL reputation.

URL Statistics

URL Filtering

Allowed Connections by User

Displays allowed application connections on your monitored network, grouped by connecting user.

Access Controlled User Statistics

FireSIGHT

Application Protocols Introducing Malware

Displays the number of malware files transmitted over your network, grouped by the application protocol used to transmit the files.

Files Dashboard

Malware

Application Protocols Transferring Files

Displays the number of files transmitted over your network, grouped by the application protocol used to transmit the files.

Files Dashboard

Protection

Client Applications Introducing Malware

Displays the applications, or parent files, that accessed or created malware detected by FireAMP Connectors.

Files Dashboard

FireAMP subscription

Client Applications Transferring Files

Displays the applications, or parent files, that transmitted files over your network.

Files Dashboard

Protection

Clients

Displays clients on your monitored network, by type.

Detailed Dashboard

FireSIGHT

Connections by Application

Displays applications on your monitored network, based on the number of detected connections.

Connection Summary

FireSIGHT

Connections by Destination Continent

Displays continents to which connections were sent from your monitored network, based on the number of connections.

Connection Summary

FireSIGHT

Connections by Destination Country

Displays countries to which connections were sent from your monitored network, based on the number of connections.

Connection Summary

FireSIGHT

Connections by Initiator IP

Displays host IP addresses on your monitored network, based on the number of connections where that IP address on a host initiated the session.

Connection Summary

FireSIGHT

Connections by Port

Displays ports on your monitored network, based on the number of detected connections.

Connection Summary

FireSIGHT

Connections by Responder IP

Displays host IP addresses on your monitored network, based on the number of connections where the responder in that session was that IP address on a host. The output of this widget varies according to your connection logging configuration.

Connection Summary

FireSIGHT

Connections by Security Intelligence Category

Displays all connections monitored or blocked by Security Intelligence on your monitored network, grouped by Security Intelligence category.

Summary Dashboard

Protection

Connections by Source Continent

Displays continents communicating with your monitored network, based on the number of connections initiated from each continent.

Connection Summary

FireSIGHT

Connections by Source Country

Displays countries communicating with your monitored network, based on the number of connections initiated from each country.

Connection Summary

FireSIGHT

Connections by URL Category

Displays all application connections on your monitored network, grouped by URL category.

Summary Dashboard

URL Filtering

Connections by URL Reputation

Displays all application connections on your monitored network, grouped by URL reputation.

Summary Dashboard

URL Filtering

Connections over Time

Displays a graph of the total number of connections on your monitored network, over the dashboard time range.

Connection Summary

FireSIGHT

Denied Connections by Application

Displays denied connections on your monitored network, grouped by application.

Application Statistics

FireSIGHT

Denied Connections by URL Category

Displays denied connections on your monitored network, grouped by URL category.

URL Statistics

URL Filtering

Denied Connections by URL Reputation

Displays denied connections on your monitored network, grouped by URL reputation.

URL Statistics

URL Filtering

Denied Connections by User

Displays denied connections on your monitored network, grouped by connecting user.

Access Controlled User Statistics

FireSIGHT

Dropped Events by Application

Displays dropped intrusion events, grouped by application.

Application Statistics

Protection + FireSIGHT

Dropped Events by User

Displays dropped intrusion events, grouped by user.

Access Controlled User Statistics

Protection + FireSIGHT

Dropped Intrusion Events

Displays counts for intrusion events, by classification, where the packet was dropped.

Detailed Dashboard

Summary Dashboard

Protection

Dynamic Analysis Traffic by Device

Displays the most active devices, based on the size of the file data submitted to the Collective Security Intelligence Cloud for analysis.

Files Dashboard

Malware

Dynamic Analysis Traffic over Time

Displays the captured file data size submitted to the cloud for analysis over the dashboard time range.

Files Dashboard

Malware

File Actions

Displays the number of files transmitted over your network, grouped by the file rule actions used to handle the files.

Files Dashboard

Protection or Malware

File Categories

Displays the number of files transmitted over your network, grouped by file category.

Files Dashboard

Protection

File Dispositions

Displays the number of files detected in network traffic as a result of Malware Cloud Lookup file rules, grouped by malware disposition.

Files Dashboard

Malware

File Names

Displays the number of files transmitted over your network, grouped by file name.

Files Dashboard

Protection

File Storage by Device

Displays the devices that have stored the most file data.

Files Dashboard

Malware

File Storage by Disposition

Displays the size in kilobytes of file data stored on the device, based on file disposition.

Files Dashboard

Malware

File Storage by Type

Displays the size in kilobytes of file data stored on the device, based on file type.

Files Dashboard

Malware

File Storage over Time

Displays a graph of kilobytes of file data stored on managed devices over the dashboard time range.

Files Dashboard

Malware

File Transfers over Time

Displays a graph of the total number of file transfers detected in network traffic by the system, over the dashboard time range.

Files Dashboard

Protection

File Types

Displays the number of files transmitted over your network, grouped by file type.

Files Dashboard

Protection

File Types Infected with Malware

Displays the number of malware detected either in network traffic by the system or by FireAMP Connectors, grouped by file type.

Files Dashboard

Malware

Files Sent for Dynamic Analysis over Time

Displays a graph of the total number of files submitted for dynamic analysis, over the dashboard time range.

Files Dashboard

Malware

Files Stored over Time

Displays a graph of the total number of files stored on managed devices, over the dashboard time range.

Files Dashboard

Malware

Hosts Receiving Files

Displays the number of files received (downloaded) by host IP addresses on your network, grouped by IP address.

Files Dashboard

Protection

Hosts Receiving Malware

Displays the number of malware files received by host IP addresses on your network, grouped by IP address.

Files Dashboard

Malware license or FireAMP subscription

Hosts Sending Files

Displays the number of files sent (uploaded) from host IP addresses on your network, grouped by IP address.

Files Dashboard

Protection

Hosts Sending Malware

Displays the number of malware files sent from host IP addresses on your network, grouped by IP address.

Files Dashboard

Malware

Impact X Events by Application

Displays number of events of estimated impact level X (where X is a number 0-4), grouped by application.

Application Statistics

Protection + FireSIGHT

Impact Level X Events by Application Protocol

Displays number of events of estimated impact level X (where X is a number 1-2), grouped by application protocol.

Summary Dashboard

Protection + FireSIGHT

Impact Level X Events by User

Displays number of events of estimated impact level X (where X is a number 0-4), grouped by user.

Access Controlled User Statistics

Protection + FireSIGHT

Indications of Compromise by Host

Displays number of triggered indications of compromise, grouped by associated host IP address.

Summary Dashboard

FireSIGHT

Intrusion Events Requiring Analysis

Displays a count of intrusion events requiring analysis, based on event classification.

Detailed Dashboard

Protection + FireSIGHT

Intrusion Events by Destination Continent

Displays continents targeted by intrusion events, based on the number of events associated with each continent.

Summary Dashboard

FireSIGHT

Intrusion Events by Destination Country

Displays countries targeted by intrusion events, based on the number of events associated with each country.

Summary Dashboard

FireSIGHT

Intrusion Events by Source Continent

Displays continents where intrusion events originated, based on the number of events originated from each continent.

Summary Dashboard

FireSIGHT

Intrusion Events by Source Country

Displays countries where intrusion events originated, based on the number of events originated from each country.

Summary Dashboard

FireSIGHT

Intrusion Events to High Criticality Hosts

Displays intrusion events, based on the number of intrusion events occurring on high criticality hosts.

Detailed Dashboard

Protection + FireSIGHT

Malware Intrusions

Displays intrusion events, based on the number of intrusion events occurring in connections transmitting malware.

Files Dashboard

Malware

Malware Threats

Displays the number of malware threats detected either in network traffic by the system or by FireAMP Connectors, grouped by threat name.

Files Dashboard

Malware license or FireAMP subscription

New Indications of Compromise over Time

Displays a graph of new indications of compromise detected over the dashboard time range.

Summary Dashboard

FireSIGHT

Operating Systems

Displays operating systems, based on the number of hosts running each operating system within your network.

Detailed Dashboard

FireSIGHT

Possible Zero-Day Malware

Displays the captured files most likely to be zero-day malware, with a file disposition of unknown and either High or Very High threat scores, based on the number of times the file was seen.

Files Dashboard

Malware

Processes Introducing Malware

Displays the system processes that accessed or created malware detected by FireAMP Connectors.

Files Dashboard

Malware license or FireAMP subscription

Risky Applications with Low Business Relevance

Displays all application connections on your monitored network that have both high application risk level and low estimated business relevance.

Summary Dashboard

FireSIGHT

Servers

Displays servers, by number of hosts.

Detailed Dashboard

FireSIGHT

SSL Actions

Displays a count of the SSL rule actions taken on encrypted traffic, based on frequency.

Connection Summary

Any

SSL Certificate Status

Displays a count of the certificate statuses the system detected in SSL-encrypted sessions, based on frequency.

Connection Summary

Any

SSL Decryption Failure Reasons

Displays a count of the system’s reasons to improperly decrypt SSL-encrypted sessions, based on frequency.

Connection Summary

Any

SSL Sessions Decrypted over Time

Displays a graph of the number of SSL-encrypted sessions the system decrypted, over the dashboard time range.

Connection Summary

Any

SSL Sessions Not Decrypted over Time

Displays a graph of the number of SSL-encrypted sessions the system did not decrypt, over the dashboard time range.

Connection Summary

Any

SSL Sessions with Errors over Time

Displays a graph of the number of SSL-encrypted sessions the system detected that contained internal errors, over the dashboard time range.

Connection Summary

Any

Threat Detections over Time

Displays a graph of the total number of malware threats detected either in network traffic by the system or by FireAMP Connectors, over the dashboard time range.

Files Dashboard

Malware license or FireAMP subscription

Top Attackers

Displays attacking host IP addresses on your monitored network, based on the number of intrusion events where the listed IP address was the attacker in the connection that caused the event.

Summary Dashboard

Protection

Top Client Applications Seen

Displays client applications on your monitored network, based on total kilobytes of data transmitted by the client application.

Summary Dashboard

FireSIGHT

Top Operating Systems Seen

Displays operating systems on your monitored network, based on the number of network hosts with the operating system.

Summary Dashboard

FireSIGHT

Top Server Applications Seen

Displays server applications on your monitored network, based on the number of hosts running the service.

Summary Dashboard

FireSIGHT

Top Targets

Displays host IP addresses on your monitored network, based on the number of intrusion events where that address was targeted in the connection that caused the event.

Summary Dashboard

Protection

Top Threats

Displays the distribution of threat scores, based on the number of stored files with that threat score.

Files Dashboard

Malware

Top Web Applications Seen

Displays web applications on your monitored network, based on total kilobytes of data transmitted by the client application.

Summary Dashboard

FireSIGHT

Total Events by Application

Displays applications on your monitored network, based on the number of intrusion events generated by the application.

Application Statistics

Protection + FireSIGHT

Total Events by Application Protocol

Displays application protocols on your monitored network, based on the number of intrusion events associated with the application protocol.

Summary Dashboard

Protection + FireSIGHT

Total Events by User

Displays users on your monitored network, based on the number of intrusion events generated by each user’s activity.

Summary Dashboard

Access Controlled User Statistics

Protection + FireSIGHT

Traffic by Application

Displays applications on your monitored network, based on total kilobytes of data transmitted on your monitored network by the application over the dashboard time range.

Application Statistics

Connection Summary

Detailed Dashboard

FireSIGHT

Traffic by Application Category

Displays application categories on your monitored network, based on total kilobytes of data transmitted on your monitored network by applications in each category over the dashboard time range.

Application Statistics

Summary Dashboard

FireSIGHT

Traffic by Application Risk

Displays estimated risk levels of applications on your monitored network, based on total kilobytes of data transmitted on your monitored network by applications at each level over the dashboard time range.

Summary Dashboard

FireSIGHT

Traffic by Business Relevance

Displays estimated business relevance levels of applications on your monitored network, based on total kilobytes of data transmitted on your monitored network by applications at each level over the dashboard time range.

Summary Dashboard

FireSIGHT

Traffic by Destination Continent

Displays continents contacted from your monitored network, based on total kilobytes of data transmitted on your monitored network to each continent over the dashboard time range.

Connection Summary

FireSIGHT

Traffic by Destination Country

Displays countries contacted from your monitored network, based on total kilobytes of data transmitted on your monitored network to each country over the dashboard time range.

Connection Summary

FireSIGHT

Traffic by Initiator IP

Displays host IP addresses on your monitored network, based on total kilobytes of data transmitted on your monitored network from the IP address over the dashboard time range.

Connection Summary

Detailed Dashboard

FireSIGHT

Traffic by Initiator User

Displays users on your monitored network, based on total kilobytes of data received by the hosts where those users are logged in.

Detailed Dashboard

Summary Dashboard

FireSIGHT

Traffic by Port

Displays responder ports on your monitored network, based on total kilobytes of data transmitted on your monitored network via each port over the dashboard time range. The output of this widget varies according to your connection logging configuration.

Connection Summary

FireSIGHT

Traffic by Responder IP

Displays IP addresses on your monitored network, based on total kilobytes of data received by the IP addresses (on hosts) over the dashboard time range. The output of this widget varies according to your connection logging configuration.

Connection Summary

Detailed Dashboard

FireSIGHT

Traffic by Security Intelligence Category

Displays Security Intelligence categories on your monitored network, based on total kilobytes of data transmitted over connections in each category over the dashboard time range.

Summary Dashboard

Protection

Traffic by Source Continent

Displays continents transmitting data to your monitored network, based on total kilobytes of data on your monitored network transmitted from each continent over the dashboard time range.

Connection Summary

FireSIGHT

Traffic by Source Country

Displays countries transmitting data to your monitored network, based on total kilobytes of data on your monitored network transmitted from each country over the dashboard time range.

Connection Summary

FireSIGHT

Traffic by URL Category

Displays application URL categories on your monitored network, based on total kilobytes of data exchanged with URLs of each category over the dashboard time range.

URL Statistics

URL Filtering

Traffic by URL Reputation

Displays application URL reputation types on your monitored network, based on total kilobytes of data exchanged with URLs of each reputation over the dashboard time range.

URL Statistics

URL Filtering

Traffic by User

Displays users on your monitored network, based on total kilobytes of data exchanged by each user over the dashboard time range.

None

FireSIGHT

Traffic over Time

Displays a graph of total kilobytes of data transmitted on your monitored network over the dashboard time range.

Connection Summary

Detailed Dashboard

FireSIGHT

Unique Applications over Time

Displays a graph of total unique applications detected on your monitored network over the dashboard time range.

Application Statistics

Summary Dashboard

FireSIGHT

Unique Users over Time

Displays a graph of total unique users detected on your monitored network over the dashboard time range.

Access Controlled User Statistics

FireSIGHT

Users Affected by Malware

Displays the number of threats detected either in network traffic by the system or by FireAMP Connectors, grouped by user.

Files Dashboard

Malware + FireSIGHT, or FireAMP subscription

Users Transferring Files

Displays the number of files being transmitted over your network, grouped by sender.

Files Dashboard

Malware + FireSIGHT

Web Applications Introducing Malware

Displays web applications on your monitored network that accessed or created malware detected by FireAMP Connectors.

Files Dashboard

Malware license or FireAMP subscription

Web Applications Transferring Files

Displays the number of files transmitted over your network, grouped by the web application used to transmit the files.

Files Dashboard

Malware license or FireAMP subscription

White List Violations

Displays hosts with white list violations, by violation count.

Detailed Dashboard

FireSIGHT

Viewing Associated Events from the Custom Analysis Widget

License: Any

Depending on the kind of data that a Custom Analysis widget is configured to display, you can invoke an event view (that is, a workflow) that provides detailed information about the events displayed in the widget.

When you invoke an event view from the dashboard, the events appear in the default workflow for that event type, constrained by the dashboard time range. This also changes the appropriate time window for the appliance, depending on how many time windows you have configured and on what type of event you are trying to view.

For example, if you configure multiple time windows on your Defense Center and then access health events from a Custom Analysis widget, the events appear in the default health events workflow, and the health monitoring time window changes to the dashboard time range.

As another example, if you configure a single time window and then access any type of event from the Custom Analysis widget, the events appear in the default workflow for that event type, and the global time window changes to the dashboard time range.

For more information on time windows, see Default Time Windows and Specifying Time Constraints in Searches.

To view associated events from the Custom Analysis Widget:

Access: Admin/Any Security Analyst/Maint

Step 1 You have two options, depending on how you configured the widget:

- On widgets configured to show relative occurrences of events (that is, bar graphs), click any event to view associated events constrained by the widget preferences, as well as by that event. You can also click the view all icon (

) in the lower right corner of the widget to view all associated events, constrained by the widget preferences.

- On widgets configured to show connection data over time, click the view all icon in the lower right corner of the widget to view all associated events, constrained by the widget preferences.

For information on working with specific event types, see the following sections:

- Working with Security Intelligence Lists and Feeds

- Viewing Audit Records

- Viewing Intrusion Events

- Viewing Discovery and Host Input Events

- Viewing File Events

- Viewing Malware Events

- Viewing Captured Files

- Viewing Hosts

- Viewing Host Attributes

- Viewing Indications of Compromise

- Viewing Servers

- Viewing Application Details

- Viewing Vulnerabilities

- Viewing Third-Party Vulnerabilities

- Viewing Connection and Security Intelligence Data

- Viewing Users

- Viewing User Activity Events

- Viewing Correlation Events

- Viewing White List Events

- Viewing White List Violations

- Viewing Health Events

- Viewing the Rule Update Log

- Working with Active Scan Results

- Using Geolocation

- Understanding Custom Tables

Custom Analysis Widget Limitations

License: Any

There are some important points to keep in mind when using the Custom Analysis widget.

If you are configuring the widget on a shared dashboard, remember that not all users can view data of all event types, depending on the user’s account privileges. For example, Maintenance Users cannot view discovery events.

Similarly, if you are using a dashboard imported from another appliance, remember that not all appliances have access to data of all event types. For example, managed devices do not store correlation data. If your dashboard includes a Custom Analysis widget that displays data you cannot see, the widget indicates that you are unauthorized to view the data. Note, however, that you (and any other users who share the dashboard) can modify the preferences of the widget to display data that you can see, or even delete the widget. If you want to make sure that this does not happen, save the dashboard as private.

Remember that only you can access searches that you have saved as private. If you configure the widget on a shared dashboard and constrain its events using a private search, the widget resets to not using the search when another user logs in. This affects your view of the widget as well. If you want to make sure that this does not happen, save the dashboard as private.

You enable or disable the Custom Analysis widget from the Dashboard settings in your system policy. For more information, see Configuring Dashboard Settings.

Understanding the Disk Usage Widget

License: Any

Table 55-6 Disk Usage Categories

Disk Usage Category

Description

Events

all events logged by the system

Files

all files stored by the system

Backups

all backup files

Updates

all files related to updates, such as rule updates and system updates

Other

system troubleshooting files and other miscellaneous files

Free

free space remaining on the appliance

You can hover your pointer over a disk usage category in the By Category stacked bar to view the percentage of available disk space used by that category, the actual storage space on the disk, and the total disk space available for that category. Note that if you have a malware storage pack installed, the total disk space available for the Files category is the available disk space on the malware storage pack. For more information, see Understanding Captured File Storage.

The widget preferences also control how often the widget updates, as well as whether it displays the current disk usage or collected disk usage statistics over the dashboard time range. For more information, see Understanding Widget Preferences.

Understanding the Interface Traffic Widget

License: Any

The Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s management (eth0 and so on) and sensing (s1p1 and so on) interfaces over the dashboard time range. It does not appear by default on any of the predefined dashboards.

Outbound (transmitted) traffic includes flow control packets. Because of this, passive interfaces on your appliances may show transmitted traffic and generate events; this is expected behavior. Note also that devices with Malware licenses enabled periodically attempt to connect to the Cisco cloud even if you have not configured dynamic analysis. Because of this, these devices show transmitted traffic; this is also expected behavior.

The widget preferences control how often the widget updates. On managed devices, the preferences also control whether the widget displays the traffic rate for unused interfaces (by default, the widget only displays the traffic rate for active interfaces). For more information, see Understanding Widget Preferences.

Understanding the Intrusion Events Widget

License: Protection

On managed devices, the widget can display statistics for dropped (or, on passively deployed devices, would have dropped) intrusion events, all intrusion events, or both. Note that you must enable local event storage or the widget will not have any data to display. Note also that the total rate represented by All does not include the dropped event rate.

On the Defense Center, but not managed devices, you can configure the widget to display intrusion events with dropped/would have dropped packets and different impacts by modifying the widget preferences. You can display dropped and would have dropped events on Defense Centers and devices. The following graphic shows the Defense Center version of the widget preferences.

In the widget preferences, you can:

- on a Defense Center,select one or more Event Flags check boxes to display separate graphs for events with dropped packets, would have dropped packets, or specific impacts; select All to display an additional graph for all intrusion events, regardless of impact or rule state; see Using Impact Levels to Evaluate Events for more information

- select Show to choose Average Events Per Second or Total Events

- select Vertical Scale to choose Linear (incremental) or Logarithmic (factor of ten) scale

The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

On the Intrusion Events widget, you can:

- on a Defense Center, click a graph corresponding to dropped packets, to would have dropped packets, or to a specific impact to view intrusion events of that type

- click the graph corresponding to dropped events to view dropped events

- click the graph corresponding to would have dropped events to view would have dropped events

- click the All graph to view all intrusion events

Note that the resulting event view is constrained by the dashboard time range; accessing intrusion events via the dashboard changes the events (or global) time window for the appliance. For more information on intrusion events, see Viewing Intrusion Events.

Note also that packets in a passive deployment are not dropped, regardless of the rule state or the inline drop behavior of the intrusion policy.

Understanding the Network Compliance Widget

License: FireSIGHT

If you choose to display network compliance for all white lists, the widget considers a host to be non-compliant if it is not compliant with any white list in an active correlation policy.

You can also use the widget preferences to specify which of three different styles you want to use to display network compliance.

The preferences control how often the widget updates. You can check the Show Not Evaluated box to hide events which have not been evaluated. For more information, see Understanding Widget Preferences.

Understanding the Product Licensing Widget

License: Any

The top section of the widget displays all device and feature licenses installed on the Defense Center, including temporary licenses, while the Expiring Licenses section displays only temporary and expired licenses. For example, if you have two feature licenses for FireSIGHT Hosts, one of which is a permanent license and allows 750 hosts, and another that is temporary and allows an additional 750 hosts, the top section of the widget displays a FireSIGHT Hosts feature license with 1500 licensed hosts, while the Expiring Licenses section displays a FireSIGHT Hosts feature license with 750 hosts.

The bars in the widget background show the percentage of each type of license that is being used; you should read the bars from right to left. Expired licenses are marked with a strikethrough.

You can configure the widget to display either the features that are currently licensed, or all the features that you can license, by modifying the widget preferences. The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

You can click any of the license types to go to the License page of the local configuration and add or delete feature licenses. For more information, see Licensing the FireSIGHT System.

Understanding the Product Updates Widget

License: Any

The Product Updates widget provides you with a summary of the software (FireSIGHT System software and rule updates) currently installed on the appliance as well as information on available updates that you have downloaded, but not yet installed, for that software. This widget appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.

Note that the widget displays Unknown as the latest version of the software unless you have configured a scheduled task to download, push, or install software updates; the widget uses scheduled tasks to determine the latest version. For more information, see Scheduling Tasks.

The widget also provides you with links to pages where you can update the software; the Defense Center version of the widget provides you with similar links so you can update the software on your managed devices.

You can configure the widget to hide the latest versions by modifying the widget preferences. The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

On the Product Updates widget, you can:

- manually update an appliance by clicking the current version of the FireSIGHT System software, rule update, geolocation update, or VDB:

- to update the system software, geolocation database, or VDB, see Updating System Software.

- to import the newest rule update, see Importing Rule Updates and Local Rule Files.

- create a scheduled task to download the latest version of the FireSIGHT System software, rule update, or VDB by clicking either the latest version or the Unknown link in the Latest column; see Scheduling Tasks.

Understanding the RSS Feed Widget

License: Any

The RSS Feed widget adds an RSS feed to a dashboard. By default, the widget shows a feed of Cisco security news. It appears by default on the Status tabs of the Detailed Dashboard and the Summary Dashboard.

Feeds update every 24 hours (although you can manually update the feed), and the widget displays the last time the feed was updated based on the local time of the appliance. Keep in mind that the appliance must have access to the web site (for the two preconfigured feeds) or to any custom feed you configure.

When you configure the widget, you can also choose how many stories from the feed you want to show in the widget, as well as whether you want to show descriptions of the stories along with the headlines; keep in mind that not all RSS feeds use descriptions.

On the RSS Feed widget, you can:

- click one of the stories in the feed to view the story

- click the more link to go to the feed’s web site

- click the update icon (

) to manually update the feed

Understanding the System Load Widget

License: Any

You can configure the widget to show or hide the load average by modifying the widget preferences. The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

Understanding the System Time Widget

License: Any

You can configure the widget to hide the boot time by modifying the widget preferences. The preferences also control how often the widget synchronizes with the appliance’s clock. For more information, see Understanding Widget Preferences.

Understanding the White List Events Widget

License: FireSIGHT

In the widget preferences, you can:

- select one or more Priorities check boxes to display separate graphs for events of specific priorities, including events that do not have a priority

- select Show All to display an additional graph for all white list events, regardless of priority

- select Vertical Scale to choose Linear (incremental) or Logarithmic (factor of ten) scale

The preferences also control how often the widget updates. For more information, see Understanding Widget Preferences.

You can click a graph to view white list events of a specific priority, or click the All graph to view all white list events. In either case, the events are constrained by the dashboard time range; accessing white list events via the dashboard changes the events (or global) time window for the Defense Center. For more information on white list events, see Viewing White List Events.

Working with Dashboards

License: Any

You can view and modify the widgets that appear on the dashboard.

You manage dashboards on the Dashboard Management page (see Viewing Dashboards). You can create, view, modify, export, and delete dashboards.

For each dashboard, the page indicates the owner (that is, the user who created it) and whether a dashboard is private. Note that, unless you have Administrator access, you can only see your own private dashboards; you cannot view or modify private dashboards created by other users.

Finally, the page indicates which dashboard is the default. You specify the default dashboard in your user preferences; for more information, see Specifying Your Default Dashboard.

For more information on working with dashboards, see:

- Creating a Custom Dashboard

- Viewing Dashboards

- Modifying Dashboards

- Deleting a Dashboard

- Exporting Configurations

Creating a Custom Dashboard

License: Any

When you create a new dashboard, you can choose to base it on any existing dashboard, whether user-created or predefined by Cisco. This makes a copy of the preexisting dashboard; you can modify this copy to suit your needs. Optionally, you can create a blank new dashboard by choosing not to base your dashboard on any preexisting dashboards.

You must also specify (or disable) the tab change and page refresh intervals. These settings determine how often the dashboard cycles through its tabs and how often the entire dashboard page refreshes.

Refreshing the entire dashboard allows you to see any preference or layout changes that were made to a shared dashboard by another user, or that you made to a private dashboard on another computer, since the last time the dashboard refreshed. This may be useful, for example, in a network operations center (NOC) where a dashboard is displayed at all times. If you want to make changes to the dashboard, you can make the changes at a local computer. Then, the dashboard in the NOC automatically refreshes at the interval you specify and displays your changes without you having to manually refresh the dashboard in the NOC. Note that you do not need to refresh the entire dashboard to see data updates; individual widgets update according to their preferences.

Finally, you can choose to associate the new dashboard with your user account by saving it as a private dashboard. If you choose not to save the dashboard as private, all other users of the appliance can view it.

Keep in mind that because not all user roles have access to all dashboard widgets, users with fewer permissions viewing a dashboard created by a user with more permissions may not be able to use all of the widgets on the dashboard. Although the unauthorized widgets still appear on the dashboard, they are disabled.

You should also keep in mind that any user with dashboard access, regardless of role, can modify shared dashboards. If you want to make sure that only you can modify a particular dashboard, save it as private.

Tip Instead of creating a new dashboard, you can export a dashboard from another appliance, then import it onto your appliance. You can then edit the imported dashboard to suit your needs. Note that the dashboard widgets you can view depend on the type of appliance you are using and on your user role; for example, a dashboard created on the Defense Center and imported onto a managed device may display some invalid, disabled widgets. For more information, see Importing and Exporting Configurations.

To create a new dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 Select Overview > Dashboards > Management.

The Dashboard Management page appears.

Step 2 Click Create Dashboard.

The Create Dashboard page appears.

Step 3 Use the Copy Dashboard drop-down list to select the dashboard on which you want to base the new dashboard.

You can select any predefined or user-defined dashboard. Optionally, select None (the default) to create a blank dashboard.

Step 4 Type a name and optional description for the dashboard.

Step 5 In the Change Tabs Every field, specify (in minutes) how often the dashboard should change tabs.

Unless you pause the dashboard or your dashboard has only one tab, this setting advances your view to the next tab at the interval you specify. To disable tab cycling, enter 0 in the Change Tabs Every field.

Step 6 In the Refresh Page Every field, specify (in minutes) how often the current dashboard tab should refresh with new data. This value must be greater than the Change Tabs Every setting.

Unless you pause the dashboard, this setting will refresh the entire dashboard at the interval you specify. To disable the periodic page refresh, enter 0 in the Refresh Page Every field.

Note that this setting is separate from the update interval available on many individual widgets; although refreshing the dashboard page resets the update interval on individual widgets, widgets will update according to their individual preferences even if you disable the Refresh Page Every setting.

Step 7 Optionally, select the Save As Private check box to associate the dashboard with your user account and to prevent other users from viewing and modifying the dashboard.

Step 8 Click Save.

Your dashboard is created and appears in the web interface. You can now tailor it to suit your needs by adding tabs and widgets (and, if you based it on a preexisting dashboard, by rearranging and deleting widgets). For more information, see Modifying Dashboards.

Viewing Dashboards

License: Any

By default, the home page for your appliance displays the default dashboard. If you do not have a default dashboard defined, the home page shows the Dashboard Management page, where you can choose a dashboard to view. At any time, to view the default dashboard you have configured for your appliance, select Overview > Dashboards; to view details of all available dashboards, select Overview > Dashboards > Management.

Tip You can configure your appliance to display a different default home page, including pages that are not dashboard pages. You can also change the default dashboard. For more information, see Specifying Your Home Page and Specifying Your Default Dashboard.

Each dashboard has a time range that constrains its widgets. You can change the time range to reflect a period as short as the last hour (the default) or as long as the last year. When you change the time range, the widgets that can be constrained by time automatically update to reflect the new time range.

Note that not all widgets can be constrained by time. For example, the dashboard time range has no effect on the Appliance Information widget, which provides information that includes the appliance name, model, and current version of the FireSIGHT System software.

Keep in mind that for enterprise deployments of the FireSIGHT System, changing the time range to a long period may not be useful for widgets like the Custom Analysis widget, depending on how often newer events replace older events.

You can also pause a dashboard, which allows you to examine the data provided by the widgets without the display changing and interrupting your analysis. Pausing a dashboard has the following effects:

- Individual widgets stop updating, regardless of any Update Every widget preference.

- Dashboard tabs stop cycling, regardless of the Cycle Tabs Every setting in the dashboard properties.

- Dashboard pages stop refreshing, regardless of the Refresh Page Every setting in the dashboard properties.

- Changing the time range has no effect.

When you are finished with your analysis, you can unpause the dashboard. Unpausing the dashboard causes all appropriate widgets on the page to update to reflect the current time range. In addition, dashboard tabs resume cycling and the dashboard page resumes refreshing according to the settings you specified in the dashboard properties.

If you experience connectivity problems or other issues that interrupt the flow of system information to the dashboard, the dashboard automatically pauses and an error notice appears until the problem is resolved.

Note Your session normally logs you out after 1 hour of inactivity (or another configured interval), regardless of whether the dashboard is paused. If you plan to passively monitor the dashboard for long periods of time, consider exempting some users from session timeout, or changing the system timeout settings. For more information, see Managing User Login Settings and Configuring User Interface Settings.

To view a dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 Select Overview > Dashboards. You have two options, depending on whether you have a default dashboard defined:

- If you have a default dashboard defined, it appears. To view a different dashboard, use the Overview > Dashboards menu.

- If you do not have a default dashboard defined, the Dashboard Management page appears. Click View next to the dashboard you want to view.

The dashboard you selected appears.

To change the dashboard time range:

Access: Admin/Any Security Analyst/Maint

Step 1 From the Show the Last drop-down list, choose a dashboard time range.

Unless the dashboard is paused, all appropriate widgets on the page update to reflect the new time range.

To pause the dashboard:

Access: Admin/Any Security Analyst/Maint

).

The dashboard is paused until you unpause it.

To unpause the dashboard:

Access: Admin/Any Security Analyst/Maint

).

The dashboard is unpaused.

Modifying Dashboards

License: Any

A dashboard has one or more tabs. You can add, delete, and rename tabs. Note that you cannot change the order of dashboard tabs.

Each tab can display one or more widgets in a three-column layout. You can minimize and maximize widgets, add and remove widgets from tabs, as well as rearrange the widgets on a tab.

You can also change the basic dashboard properties, which include its name and description, the tab cycle and page refresh intervals, and whether you want to share the dashboard with other users.

Note that any user with dashboard access, regardless of role, can modify shared dashboards. If you want to make sure that only you can modify a particular dashboard, make sure to set it as a private dashboard in the dashboard properties.

Every configuration of the Custom Analysis widget in the Cisco predefined dashboards corresponds to a preset for that widget. If you change or delete one of these widgets, you can restore it by creating a new Custom Analysis widget based on the appropriate preset. For more information, see

Tip Every configuration of the Custom Analysis widget in the Cisco predefined dashboards corresponds to a system preset for that widget. If you change or delete one of these widgets, you can restore it by creating a new Custom Analysis widget based on the appropriate preset. For more information, see Configuring the Custom Analysis Widget.

For more information, see the following sections:

- Changing Dashboard Properties

- Adding Tabs

- Deleting Tabs

- Renaming Tabs

- Adding Widgets

- Rearranging Widgets

- Minimizing and Maximizing Widgets

- Deleting Widgets

Changing Dashboard Properties

License: Any

Use the following procedure to change the basic dashboard properties, which include its name and description, the tab cycle and page refresh intervals, and whether you want to share the dashboard with other users.

To change a dashboard’s properties:

Access: Admin/Any Security Analyst/Maint

Step 1 Select Overview > Dashboards > Management.

The Dashboard Management page appears.

) next to the dashboard whose properties you want to change.

The Edit Dashboard page appears. See Creating a Custom Dashboard for information on the various configurations you can change.

Step 3 Make changes as needed and click Save.

The dashboard is changed.

Adding Tabs

License: Any

Use the following procedure to add a tab to a dashboard.

To add a tab to a dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 View the dashboard where you want to add a tab.

For more information, see Viewing Dashboards.

).

A pop-up window appears, prompting you to name the tab.

Step 3 Type a name for the tab (maximum 25 characters) and click OK, or simply click OK to accept the default name. Note that you can rename the tab at any time; see Renaming Tabs.

The new tab is added. You can now add widgets to the new tab. For more information, see Adding Widgets.

Deleting Tabs

License: Any

Use the following procedure to delete a dashboard tab and all its widgets. You cannot delete the last tab from a dashboard; each dashboard must have at least one tab.

To delete a tab from a dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 View the dashboard where you want to delete a tab.

For more information, see Viewing Dashboards.

).

Step 3 Confirm that you want to delete the tab.

The tab is deleted.

Renaming Tabs

License: Any

Use the following procedure to rename a dashboard tab.

To rename a tab:

Access: Admin/Any Security Analyst/Maint

Step 1 View the dashboard where you want to rename a tab.

For more information, see Viewing Dashboards.

Step 2 Click the tab you want to rename.

Step 3 Click the tab title.

A pop-up window appears, prompting you to rename the tab.

Step 4 Type a name for the tab (maximum 25 characters) and click OK.

The tab is renamed.

Adding Widgets

License: Any

To add a widget to a dashboard, you must first decide to which tab you want to add the widget. When you add a widget to a tab, the appliance automatically adds it to the column with the fewest widgets. If all columns have an equal number of widgets, the new widget is added to the leftmost column. You can add a maximum of 15 widgets to a dashboard tab.

Tip After you add widgets, you can move them to any location on the tab. You cannot, however, move widgets from tab to tab. For more information, see Rearranging Widgets.

To add a widget to a dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 View the dashboard where you want to add a widget.

For more information, see Viewing Dashboards.

Step 2 Select the tab where you want to add the widget.

Step 3 Click Add Widgets.

The Add Widgets page appears.

The widgets that you can add depend on the type of appliance you are using and on your user role. They are organized according to function: Analysis & Reporting, Miscellaneous, and Operations. You can view the widgets in each category by clicking on the category name, or you can view all widgets by clicking All Categories.

Step 4 Click Add next to the widgets you want to add.

Tip To add multiple widgets of the same type (for example, you may want to add multiple RSS Feed widgets, or multiple Custom Analysis widgets), click Add again.

The widget is immediately added to the dashboard. The Add Widgets page indicates how many widgets of each type are on the tab, including the widget you just added.

Step 5 Optionally, when you are finished adding widgets, click Done to return to the dashboard.

The tab where you added the widgets appears again, reflecting the changes you made.

Rearranging Widgets

License: Any

You can change the location of any widget on a tab. Note, however, that you cannot move widgets from tab to tab. If you want a widget to appear on a different tab, you must delete it from the existing tab and add it to the new tab.

To move a widget:

Access: Admin/Any Security Analyst/Maint

Step 1 Click the title bar of the widget you want to move, then drag it to its new location.

Minimizing and Maximizing Widgets

License: Any

You can minimize widgets to simplify your view, then maximize them when you want to see them again.

To minimize a widget:

Access: Admin/Any Security Analyst/Maint

) in a widget’s title bar.

To maximize a widget:

Access: Admin/Any Security Analyst/Maint

) in a minimized widget’s title bar.

Deleting Widgets

License: Any

Delete a widget if you no longer want to view it on a tab.

To delete a widget:

Access: Admin/Any Security Analyst/Maint

) in the title bar of the widget.

Step 2 Confirm that you want to delete the widget.

The widget is deleted from the tab.

Deleting a Dashboard

License: Any

Delete a dashboard if you no longer need to use it.

If you delete your default dashboard, you must define a new default or the appliance will force you to select a dashboard to view every time you attempt to view a dashboard. For more information, see Specifying Your Default Dashboard.

To delete a dashboard:

Access: Admin/Any Security Analyst/Maint

Step 1 Select Overview > Dashboards > Management.

The Dashboard Management page appears.

) next to the dashboard you want to delete.

Step 3 Confirm that you want to delete the dashboard.

The dashboard is deleted.

Using the Context Explorer

The FireSIGHT System Context Explorer displays detailed, interactive graphical information in context about the status of your monitored network, including data on applications, application statistics, connections, geolocation, indications of compromise, intrusion events, hosts, servers, Security Intelligence, users, files (including malware files), and relevant URLs. Distinct sections present this data in the form of vivid line, bar, pie, and donut graphs, accompanied by detailed lists.

You can easily create and apply custom filters to fine-tune your analysis, and you can examine data sections in more detail by simply clicking or hovering your cursor over graph areas. You can also configure the explorer’s time range to reflect a period as short as the last hour or as long as the last year. Only users with the Administrator, Security Analyst, or Security Analyst (Read Only) user roles have access to the Context Explorer.

The FireSIGHT System dashboard is highly customizable and compartmentalized and updates in real time. In contrast, the Context Explorer is manually updated, designed to provide broader context for its data, and has a single, consistent layout designed for active user exploration.

You use the dashboard to monitor real-time activity on your network and appliances according to your own specific needs. Conversely, you use the Context Explorer to investigate a predefined set of recent FireSIGHT data in granular detail and clear context: for example, if you notice that only 15% of hosts on your network use Linux, but account for almost all YouTube traffic, you can quickly apply filters to view data only for Linux hosts, only for YouTube-associated application data, or both. Unlike the compact, narrowly focused dashboard widgets, the Context Explorer sections are designed to provide striking visual representations of system activity in a format useful to both expert and casual users of the FireSIGHT System.

Note that the data displayed depends on such factors as how you license and deploy your managed devices, whether you configure features that provide the data and, in the case of Series 2 appliances and Cisco NGIPS for Blue Coat X-Series, whether the appliance supports a feature that provides the data. For example, neither the DC500 Defense Center nor Series 2 devices or Cisco NGIPS for Blue Coat X-Series support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it.

The following table summarizes some of the key differences between the dashboard and the Context Explorer.

Table 56-1 Comparison: Dashboard and Context Explorer

Feature

Dashboard

Context Explorer

Displayable data

Anything monitored by the FireSIGHT System

Applications, application statistics, geolocation, indications of compromise, intrusion events, files (including malware files), hosts, Security Intelligence events, servers, users, and URLs

Customizability

- Selection of widgets for a dashboard is customizable

- Individual widgets can be customized to varying degrees

- Cannot change base layout

- Applied filters appear in explorer URL and can be bookmarked for later use

Data update frequency

Automatic (default); user-configured

Manual

Data filtering

Possible for some widgets (must edit widget preferences)

Possible for all parts of the explorer, with support for multiple filters

Graphical context

Some widgets (particularly Custom Analysis) can display data in graph form

Extensive graphical context for all data, including uniquely detailed donut graphs

Links to relevant web interface pages

In some widgets

In every section

Time range of displayed data

User-configured

User-configured

For more information on the related FireSIGHT System dashboard, see Using Dashboards.

Understanding the Context Explorer

License: FireSIGHT

The Context Explorer comprises several distinct sections that together offer a complete overview of FireSIGHT data on your monitored network. The first section, a line chart of traffic and event counts over time, provides an at-a-glance picture of recent trends in your network’s activity.

The other sections are sets of interactive graphs and lists that provide greater detail for indications of compromise, network, application, Security Intelligence, intrusion, file, geolocation, and URL data. Except for the traffic and events time graph, you can view or hide any section. You can also apply filters to constrain the data that appears in all sections; see Working with Filters in the Context Explorer for more information.

For in-depth information on the content and function of Context Explorer sections, see the following topics:

- Understanding the Traffic and Intrusion Event Counts Time Graph

- Understanding the Indications of Compromise Section

- Understanding the Network Information Section

- Understanding the Application Information Section

- Understanding the Security Intelligence Section

- Understanding the Intrusion Information Section

- Understanding the Files Information Section

- Understanding the Geolocation Information Section

- Understanding the URL Information Section

For information on how to configure the Context Explorer as a whole, see the following topics:

- Refreshing the Context Explorer

- Setting the Context Explorer Time Range

- Minimizing and Maximizing Context Explorer Sections

- Drilling Down on Context Explorer Data

For information on configuring and using Context Explorer filters, see the following topics:

- Working with Filters in the Context Explorer

- Adding and Applying Filters

- Creating Filters with the Context Menu

- Bookmarking Filters

Understanding the Traffic and Intrusion Event Counts Time Graph

License: FireSIGHT

At the top of the Context Explorer is a line chart of traffic and intrusion events over time. The X-axis plots time intervals (which range from five minutes to one month, depending on the selected time window). The Y-axis plots traffic in kilobytes (blue line) and intrusion event count (red line).

Note that the smallest X-axis interval is five minutes. To accommodate this, the system will round the beginning and ending points in your selected time range down to the nearest five-minute interval.

By default, this section shows all network traffic and all generated intrusion events for the selected time range. If you apply filters, the chart changes to display only traffic and intrusion events associated with the criteria specified in the filters. For example, filtering on the OS Name of Windows causes the time graph to display only traffic and events associated with hosts using Windows operating systems.

If you filter the Context Explorer on intrusion event data (such as a Priority of High), the blue Traffic line is hidden to allow greater focus on intrusion events alone.

This section draws data primarily from the Intrusion Events and Connection Events tables.

Understanding the Indications of Compromise Section

License: FireSIGHT

The Indications of Compromise (IOC) section of the Context Explorer contains two interactive sections that provide an overall picture of potentially compromised hosts on your monitored network: a proportional view of the most prevalent IOC types triggered, as well as a view of hosts by number of triggered indications.

For more information on the graphs in the Indications of Compromise section, see the following topics:

- Viewing the Hosts by Indication Graph

- Viewing the Indications by Host Graph

Viewing the Hosts by Indication Graph

License: FireSIGHT

The Hosts by Indication graph, in donut form, displays a proportional view of the Indications of Compromise (IOC) triggered by hosts on your monitored network. The inner ring divides by IOC category (such as CnC Connected or Malware Detected), while the outer ring further divides that data by specific event type (such as Impact 2 Intrusion Event — attempted-admin or Threat Detected in File Transfer).

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Hosts and Indications of Compromise tables.

Viewing the Indications by Host Graph

License: FireSIGHT

The Indications by Host graph, in bar form, displays counts of unique Indications of Compromise (IOC) triggered by the 15 most IOC-active hosts on your monitored network.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Hosts and Indications of Compromise tables.

Understanding the Network Information Section

License: FireSIGHT

The Network Information section of the Context Explorer contains six interactive graphs that display an overall picture of connection traffic on your monitored network: sources, destinations, users, and security zones associated with traffic, a breakdown of operating systems used by hosts on the network, as well as a proportional view of access control actions your FireSIGHT System has performed on network traffic.

For more information on the graphs in the Network Information section, see the following topics:

- Viewing the Operating Systems Graph

- Viewing the Traffic by Source IP Graph

- Viewing the Traffic by Source User Graph

- Viewing the Connections by Access Control Action Graph

- Viewing the Traffic by Destination IP Graph

- Viewing the Traffic by Ingress/Egress Security Zone Graph

Viewing the Operating Systems Graph

License: FireSIGHT

The Operating Systems graph, in donut form, displays a proportional representation of operating systems detected on hosts on your monitored network. The inner ring divides by OS name (such as Windows or Linux), while the outer ring further divides that data by specific operating system version (such as Windows Server 2008 or Linux 11.x). Some closely related operating systems (such as Windows 2000, Windows XP, and Windows Server 2003) are grouped together. Very scarce or unrecognized operating systems are grouped under Other.

Note that this graph reflects all available data regardless of date and time constraints. If you change the explorer time range, the graph does not change.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Hosts table.

Viewing the Traffic by Source IP Graph

License: FireSIGHT

The Traffic by Source IP graph, in bar form, displays counts of network traffic (in kilobytes per second) and unique connections for the top 15 most active source IP addresses on your monitored network. For each source IP address listed, blue bars represent traffic data and red bars represent connection data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note If you filter on intrusion event information, the Traffic by Source IP graph is hidden.

This graph draws data primarily from the Connection Events table.

Viewing the Traffic by Source User Graph

License: FireSIGHT

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note If you filter on intrusion event information, the Traffic by Source User graph is hidden.

This graph draws data primarily from the Connection Events table. Note that it displays only users reported by the User Agent.

Viewing the Connections by Access Control Action Graph

License: FireSIGHT

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note If you filter on intrusion event information, the Traffic by Source User graph is hidden.

This graph draws data primarily from the Connection Events table.

Viewing the Traffic by Destination IP Graph

License: FireSIGHT

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note If you filter on intrusion event information, the Traffic by Destination IP graph is hidden.

This graph draws data primarily from the Connection Events table.

Viewing the Traffic by Ingress/Egress Security Zone Graph

License: FireSIGHT

The Traffic by Ingress/Egress Security Zone graph, in bar form, displays counts of incoming or outgoing network traffic (in kilobytes per second) and unique connections for each security zone configured on your monitored network. You can configure this graph to display either ingress (the default) or egress security zone information, according to your needs.

For each security zone listed, blue bars represent traffic data and red bars represent connection data. For information about security zones, see Working with Security Zones.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information

Tip To constrain the graph so it displays only traffic by egress security zone, hover your pointer over the graph, then click Egress on the toggle button that appears. Click Ingress to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Ingress view.

Note If you filter on intrusion event information, the Traffic by Ingress/Egress Security Zone graph is hidden.

This graph draws data primarily from the Connection Events table.

Understanding the Application Information Section

License: FireSIGHT

The Application Information section of the Context Explorer contains three interactive graphs and one table-format list that display an overall picture of application activity on your monitored network: traffic, intrusion events, and hosts associated with applications, further organized by the estimated risk or business relevance assigned to each application. The Application Details list provides an interactive list of each application and its risk, business relevance, category, and host count.

For all instances of “application” in this section, the Application Information graph set, by default, specifically examines application protocols (such as DNS or SSH). You can also configure the Application Information section to specifically examine client applications (such as PuTTY or Firefox) or web applications (such as Facebook or Pandora).

For more information on the graphs and list in the Application Information section, see the following topics:

- Viewing the Traffic by Risk/Business Relevance and Application Graph

- Viewing the Intrusion Events by Risk/Business Relevance and Application Graph

- Viewing the Hosts by Risk/Business Relevance and Application Graph

- Viewing the Application Details List

To configure the Application Information section focus:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Context Explorer.

The Context Explorer appears.

Step 2 Hover your pointer over the Application Protocol Information section. (Note that if you previously changed this setting in the same Context Explorer session, the section title may appear as Client Application Information or Web Application Information instead.)

The section option buttons appear at the upper right.

Step 3 Click Application Protocol, Client Application, or Web Application.

The Application Information section refreshes according to the option you selected.

Note If you navigate away from the Context Explorer, this section reverts to its default state (Application Protocol).

Viewing the Traffic by Risk/Business Relevance and Application Graph

License: FireSIGHT

The Traffic by Risk/Business Relevance and Application graph, in donut form, displays a proportional representation of application traffic detected on your monitored network, arranged by the applications’ estimated risk (the default) or estimated business relevance. The inner ring divides by estimated risk/business relevance level (such as Medium or High), while the outer ring further divides that data by specific application (such as SSH or NetBIOS). Scarcely detected applications are grouped under Other.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays traffic by business relevance and application, hover your pointer over the graph, then click Business Relevance on the toggle button that appears. Click Risk to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Risk view.

Note If you filter on intrusion event information, the Traffic by Risk/Business and Application graph is hidden.

This graph draws data primarily from the Connection Events and Application Statistics tables.

Viewing the Intrusion Events by Risk/Business Relevance and Application Graph

License: FireSIGHT

Hover your pointer over any part of the donut graph to view more detailed information. Click any part of the graph to filter or drill down on that information, or (where applicable) to view application information.

Tip To constrain the graph so it displays intrusion events by business relevance and application, hover your pointer over the graph, then click Business Relevance on the toggle button that appears. Click Risk to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Risk view.

This graph draws data primarily from the Intrusion Events and Application Statistics tables.

Viewing the Hosts by Risk/Business Relevance and Application Graph

License: FireSIGHT

Hover your pointer over any part of the donut graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays hosts by business relevance and application, hover your pointer over the graph, then click Business Relevance on the toggle button that appears. Click Risk to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Risk view.

This graph draws data primarily from the Applications table.

Viewing the Application Details List

License: FireSIGHT

At the bottom of the Application Information section is the Application Details List, a table that provides estimated risk, estimated business relevance, category, and hosts count information for each application detected on your monitored network. The applications are listed in descending order of associated host count.

The Application Details List table is not sortable, but you can click on any table entry to filter or drill down on that information, or (where applicable) to view application information. This table draws data primarily from the Applications table.

Note that this list reflects all available data regardless of date and time constraints. If you change the explorer time range, the list does not change.

Understanding the Security Intelligence Section

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

The Security Intelligence section of the Context Explorer contains three interactive bar graphs that display an overall picture of traffic on your monitored network that is blacklisted or monitored by Security Intelligence. The graphs sort such traffic by category, source IP address, and destination IP address, respectively; both the amount of traffic (in kilobytes per second) and the number of applicable connections appear.

For more information on the graphs in the Security Intelligence section, see the following topics:

- Viewing the Security Intelligence Traffic by Category Graph

- Viewing the Security Intelligence Traffic by Source IP Graph

- Viewing the Security Intelligence Traffic by Destination IP Graph

Viewing the Security Intelligence Traffic by Category Graph

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

The Security Intelligence Traffic by Category graph, in bar form, displays counts of network traffic (in kilobytes per second) and unique connections for the top Security Intelligence categories of traffic on your monitored network. For each category listed, blue bars represent traffic data and red bars represent connection data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Security Intelligence Traffic by Category graph is hidden.

This graph draws data primarily from the Security Intelligence Events table.

Viewing the Security Intelligence Traffic by Source IP Graph

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Security Intelligence Traffic by Source IP graph is hidden.

This graph draws data primarily from the Security Intelligence Events table.

Viewing the Security Intelligence Traffic by Destination IP Graph

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Security Intelligence Traffic by Destination IP graph is hidden.

This graph draws data primarily from the Security Intelligence Events table.

Understanding the Intrusion Information Section

License: Protection

The Intrusion Information section of the Context Explorer contains six interactive graphs and one table-format list that display an overall picture of intrusion events on your monitored network: impact levels, attack sources, target destinations, users, priority levels, and security zones associated with intrusion events, as well as a detailed list of intrusion event classifications, priorities, and counts.

For more information on the graphs and list in the Network Information section, see the following topics:

- Viewing the Intrusion Events by Impact Graph

- Viewing the Top Attackers Graph

- Viewing the Top Users Graph

- Viewing the Intrusion Events by Priority Graph

- Viewing the Top Targets Graph

- Viewing the Top Ingress/Egress Security Zones Graph

- Viewing the Intrusion Event Details List

Viewing the Intrusion Events by Impact Graph

License: Protection

The Intrusion Events by Impact graph, in pie form, displays a proportional view of intrusion events on your monitored network, grouped by estimated impact level (from 0 to 4).

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the IDS Statistics and Intrusion Events tables.

Viewing the Top Attackers Graph

License: Protection

The Top Attackers graph, in bar form, displays counts of intrusion events for the top attacking host IP addresses (causing those events) on your monitored network.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Intrusion Events table.

Viewing the Top Users Graph

License: Protection

The Top Users graph, in bar form, displays users on your monitored network that are associated with the highest intrusion event counts, by event count.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the IDS User Statistics and Intrusion Events tables. Note that it displays only users reported by the User Agent.

Viewing the Intrusion Events by Priority Graph

License: Protection

The Intrusion Events by Priority graph, in pie form, displays a proportional view of intrusion events on your monitored network, grouped by estimated priority level (such as High, Medium, or Low).

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Intrusion Events table.

Viewing the Top Targets Graph

License: Protection

The Top Targets graph, in bar form, displays counts of intrusion events for the top target host IP addresses (targeted in the connections causing those events) on your monitored network.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

This graph draws data primarily from the Intrusion Events table.

Viewing the Top Ingress/Egress Security Zones Graph

License: Protection

The Top Ingress/Egress Security Zones graph, in bar form, displays counts of intrusion events associated with each security zone (ingress or egress, depending on graph settings) configured on your monitored network. For information about security zones, see Working with Security Zones.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only traffic by egress security zone, hover your pointer over the graph, then click Egress on the toggle button that appears. Click Ingress to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Ingress view.

This graph draws data primarily from the Intrusion Events table.

You can configure this graph to display either ingress (the default) or egress security zone information, according to your needs.

Viewing the Intrusion Event Details List

License: Protection

At the bottom of the Intrusion Information section is the Intrusion Event Details List, a table that provides classification, estimated priority, and event count information for each intrusion event detected on your monitored network. The events are listed in descending order of event count.

The Intrusion Event Details List table is not sortable, but you can click on any table entry to filter or drill down on that information. This table draws data primarily from the Intrusion Events table.

Understanding the Files Information Section

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Files Information section of the Context Explorer contains six interactive graphs that display an overall picture of file and malware events on your monitored network. Five of the graphs display the file types, file names, and malware dispositions of the files detected in network traffic, as well as the hosts sending (uploading) and receiving (downloading) those files. The final graph displays the malware threats detected on your network and, if you have a FireAMP subscription, on the endpoints where your users installed FireAMP Connectors.

Note If you filter on intrusion information, the entire Files Information Section is hidden.

Note that you must have a Malware license and enable malware detection for Files Information graphs to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

For more information on the graphs in the Files Information section, see the following topics:

- Viewing the Top File Types Graph

- Viewing the Top File Names Graph

- Viewing the Files by Disposition Graph

- Viewing the Top Hosts Sending Files Graph

- Viewing the Top Hosts Receiving Files Graph

- Viewing the Top Malware Detections Graph

Viewing the Top File Types Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Top File Types graph, in donut form, displays a proportional view of the file types detected in network traffic (outer ring), grouped by file category (inner ring).

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events table.

Viewing the Top File Names Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events table.

Viewing the Files by Disposition Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events table.

Viewing the Top Hosts Sending Files Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only hosts sending malware, hover your pointer over the graph, then click Malware on the toggle button that appears. Click Files to return to the default files view. Note that navigating away from the Context Explorer also returns the graph to the default files view.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events table.

Viewing the Top Hosts Receiving Files Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Top Hosts Receiving Files graph, in bar form, displays counts of the number of files detected in network traffic for the top file-receiving host IP addresses.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only hosts receiving malware, hover your pointer over the graph, then click Malware on the toggle button that appears. Click Files to return to the default files view. Note that navigating away from the Context Explorer also returns the graph to the default files view.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events table.

Viewing the Top Malware Detections Graph

License: Protection or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Top Malware Detections graph, in bar form, displays counts of the top malware threats detected on your network and, if you have a FireAMP subscription, on the endpoints where your users installed FireAMP Connectors.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Note that you must have a Malware license and enable malware detection for this graph to include network-based malware data. Note also that the DC500 Defense Center and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, so the DC500 Defense Center cannot display this data and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect it. See Understanding Malware Protection and File Control.

This graph draws data primarily from the File Events and Malware Events tables.

Understanding the Geolocation Information Section

License: FireSIGHT

Supported Defense Centers: Any except DC500

The Geolocation Information section of the Context Explorer contains three interactive donut graphs that display an overall picture of countries with which hosts on your monitored network are exchanging data: unique connections by initiator or responder country, intrusion events by source or destination country, and file events by sending or receiving country.

For more information on the graphs in the Geolocation Information section, see the following topics:

- Viewing the Connections by Initiator/Responder Country Graph

- Viewing the Intrusion Events by Source/Destination Country Graph

- Viewing the File Events by Sending/Receiving Country Graph

Viewing the Connections by Initiator/Responder Country Graph

License: FireSIGHT

Supported Defense Centers: Any except DC500

The Connections by Initiator/Responder Country graph, in donut form, displays a proportional view of the countries involved in connections on your network as either the initiator (the default) or the responder. The inner ring groups these countries together by continent. For information about geolocation information, see Using Geolocation. For information about connection data, see Working with Connection & Security Intelligence Data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only countries acting as the responder in connections, hover your pointer over the graph, then click Responder on the toggle button that appears. Click Initiator to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Initiator view.

This graph draws data primarily from the Connection Summary Data table.

Viewing the Intrusion Events by Source/Destination Country Graph

License: FireSIGHT

Supported Defense Centers: Any except DC500

The Intrusion Events by Source/Destination Country graph, in donut form, displays a proportional view of the countries involved in intrusion events on your network as either the source of the event (the default) or the destination. The inner ring groups these countries together by continent. For information about geolocation information, see Using Geolocation. For information about intrusion event data, see Working with Intrusion Events.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only countries acting as the destinations of intrusion events, hover your pointer over the graph, then click Destination on the toggle button that appears. Click Source to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Source view.

This graph draws data primarily from the Intrusion Events table.

Viewing the File Events by Sending/Receiving Country Graph

License: FireSIGHT

Supported Defense Centers: Any except DC500

The File Events by Sending/Receiving Country graph, in donut form, displays a proportional view of the countries detected in file events on your network as either sending (the default) or receiving files. The inner ring groups these countries together by continent. For information about geolocation information, see Using Geolocation. For information about file event data, see Working with File Events.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to filter or drill down on that information.

Tip To constrain the graph so it displays only countries receiving files, hover your pointer over the graph, then click Receiver on the toggle button that appears. Click Sender to return to the default view. Note that navigating away from the Context Explorer also returns the graph to the default Sender view.

This graph draws data primarily from the File Events table.

Understanding the URL Information Section

License: FireSIGHT or URL Filtering

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The URL Information section of the Context Explorer contains three interactive bar graphs that display an overall picture of URLs with which hosts on your monitored network are exchanging data: traffic and unique connections associated with URLs, sorted by individual URL, URL category, and URL reputation. You cannot filter on URL information.

Note If you filter on intrusion event information, the entire URL Information Section is hidden.

Note that you must have a URL Filtering license and enable URL Filtering for URL filtering graphs to include URL category and reputation data. Note also that neither the DC500 Defense Center nor Series 2 devices support URL filtering by reputation and category, so the DC500 Defense Center cannot display this data and Series 2 devices do not detect it. See Blocking URLs.

For more information on the graphs in the URL Information section, see the following topics:

- Viewing the Traffic by URL Graph

- Viewing the Traffic by URL Category Graph

- Viewing the Traffic by URL Reputation Graph

Viewing the Traffic by URL Graph

License: FireSIGHT or URL Filtering

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Traffic by URL graph, in bar form, displays counts of network traffic (in kilobytes per second) and unique connections for the top 15 most requested URLs on your monitored network. For each URL listed, blue bars represent traffic data and red bars represent connection data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Traffic by URL graph is hidden.

Note that you must have a URL Filtering license and enable URL Filtering for URL filtering graphs to include URL category and reputation data. Note also that neither the DC500 Defense Center nor Series 2 devices support URL filtering by reputation and category, so the DC500 Defense Center cannot display this data and Series 2 devices do not detect it. See Enabling Cloud Communications.

This graph draws data primarily from the Connection Events table.

Viewing the Traffic by URL Category Graph

License: URL Filtering

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Traffic by URL Category graph, in bar form, displays counts of network traffic (in kilobytes per second) and unique connections for the most requested URL categories (such as Search Engines or Streaming Media) on your monitored network. For each URL category listed, blue bars represent traffic data and red bars represent connection data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Traffic by URL Category graph is hidden.

Note that you must have a URL Filtering license and enable URL Filtering for URL filtering graphs to include URL category and reputation data. Note also that neither the DC500 Defense Center nor Series 2 devices support URL filtering by reputation and category, so the DC500 Defense Center cannot display this data and Series 2 devices do not detect it. See Performing Reputation-Based URL Blocking.

This graph draws data primarily from the URL Statistics and Connection Events tables.

Viewing the Traffic by URL Reputation Graph

License: URL Filtering

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The Traffic by URL Reputation graph, in bar form, displays counts of network traffic (in kilobytes per second) and unique connections for the most requested URL reputation groups (such as Well known or Benign sites with security risks) on your monitored network. For each URL reputation listed, blue bars represent traffic data and red bars represent connection data.

Hover your pointer over any part of the graph to view more detailed information. Click any part of the graph to drill down on that information.

Note If you filter on intrusion event information, the Traffic by URL Reputation graph is hidden.

Note that you must have a URL Filtering license and enable URL Filtering for URL filtering graphs to include URL category and reputation data. Note also that neither the DC500 Defense Center nor Series 2 devices support URL filtering by reputation and category, so the DC500 Defense Center cannot display this data and Series 2 devices do not detect it. See Performing Reputation-Based URL Blocking.

This graph draws data primarily from the URL Statistics and Connection Events tables.

Refreshing the Context Explorer

License: FireSIGHT

The Context Explorer does not automatically update the information it displays. To incorporate new data, you must manually refresh the explorer.

Note that, although reloading the Context Explorer itself (by refreshing the browser program or navigating away from, then back to, the Context Explorer) refreshes all displayed information, this does not preserve any changes you made to section configuration (such as the Ingress/Egress graphs and the Application Information section) and may cause delays in loading.

To refresh the Context Explorer:

Access: Admin/Any Security Analyst

Step 1 On the Context Explorer, click Reload at the upper right.

The explorer updates to display the latest information within your selected time range. Note that the Reload button is grayed out until your refresh is finished.

Setting the Context Explorer Time Range

License: FireSIGHT

You can configure the Context Explorer time range to reflect a period as short as the last hour (the default) or as long as the last year. Note that when you change the time range, the Context Explorer does not automatically update to reflect the change. To apply the new time range, you must manually refresh the explorer.

Changes to the time range persist even if you navigate away from the Context Explorer or end your login session.

To change the Context Explorer time range:

Access: Admin/Any Security Analyst

Step 1 From the Show the last drop-down list, select a time range.

Step 2 Optionally, to view data from the new time range, click Reload.

All sections of the Context Explorer update to reflect the new time range.

Tip Clicking Apply Filters also applies any time range updates.

Minimizing and Maximizing Context Explorer Sections

License: FireSIGHT

You can minimize and hide one or more sections of the Context Explorer. This is useful if you want to focus on only certain sections, or if you want a simpler view. You cannot minimize the Traffic and Intrusion Event Counts Time Graph.

Note that Context Explorer sections retain the minimized or maximized states that you configure even if you refresh the page or log out of the appliance.

To minimize a Context Explorer section:

Access: Admin/Any Security Analyst

) in a section’s title bar.

To maximize a Context Explorer section:

Access: Admin/Any Security Analyst

) in a minimized section’s title bar.

Drilling Down on Context Explorer Data

License: feature dependent

If you want to examine graph or list data in more detail than the Context Explorer allows, you can drill down to the table views of the relevant data. (Note that you cannot drill down on the Traffic and Intrusion Events over Time graph.) For example, drilling down on an IP address in the Traffic by Source IP graph displays the Connections with Application Details view of the Connection Events table, including only data associated with the source IP address you selected.

Depending on the type of data you examine, additional options can appear in the context menu. Data points that are associated with specific IP addresses offer the option to view host or whois information on the IP address you select. Data points associated with specific applications offer the option to view application information on the application you select. Data points associated with a specific user offer the option to view that user’s user profile page. Data points associated with an intrusion event message offer the option to view the rule documentation for that event’s associated intrusion rule, and data points associated with a specific IP address offer the option to blacklist or whitelist that address.

The context menu that you use to drill down on data also contains options to filter that data. For more information on filtering, see Working with Filters in the Context Explorer.

To drill down on data in the Context Explorer:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Context Explorer.

The Context Explorer appears.

Step 2 In any section but Traffic and Intrusion Events over Time, click a data point that you want to investigate.

The context menu pop-up window appears nearby.

Step 3 Depending on the data point you selected, you have several options:

- To view more details of this data in a table view, select Drill into Analysis .

A new window opens with a detailed table view of the data you selected.

- If you selected a data point associated with a specific IP address and want more information about the associated host, select View Host Information .

A new window opens with a host profile page for the IP address you selected. For more information on host attributes and host profiles, see Using Host Profiles.

- If you selected a data point with a specific IP address and want to make a whois search on that address, select Whois .

A new window opens with the results of a whois query for the IP address you selected.

- If you selected a data point associated with a specific application and want more information about that application, select View Application Information .

A new window opens with information on the application you selected. For more information about application attributes, see Understanding Application Detection.

- If you selected a data point associated with a specific user and want more information about that user, select View User Information .

A new window opens with a user profile page for the user you selected. For more information on user details, see Understanding User Details and Host History.

- If you selected a data point associated with a specific intrusion event message and want more information about the associated intrusion rule, select View Rule Documentation .

A new window opens with a rule details page relevant to the event you selected. For more information on intrusion rule details, see Viewing Rule Details.

- If you selected a data point associated with a specific IP address and want to add that IP address to the Security Intelligence global blacklist or whitelist, select the appropriate option: Blacklist Now or Whitelist Now . Confirm your choice in the pop-up window that appears.

The IP address is blacklisted or whitelisted. For more information, see Working with the Global Whitelist and Blacklist.

These options are not listed on the DC500 Defense Center, which does not support Security Intelligence data.

Working with Filters in the Context Explorer

License: FireSIGHT

Beyond the basic, wide-ranging data that the Context Explorer initially displays, you have the option to filter that data for a more granular contextual picture of activity on your network. Filters encompass all types of FireSIGHT data except URL information, support exclusion as well as inclusion, can be applied quickly by clicking on Context Explorer graph data points, and affect the entire explorer. You can apply up to 20 filters at once to create a highly specific portrait tailored to the needs of your network and organization. Filters that you apply are reflected in the Context Explorer URL so you can bookmark useful filter sets in your browser program for later use.

For information on using filters in the Context Explorer, see the following topics:

- Adding and Applying Filters

- Creating Filters with the Context Menu

- Bookmarking Filters

Adding and Applying Filters

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

You can add filters to Context Explorer data in several ways:

- from the Add Filter window

- from the context menu pop-up window, when you select a data point in the explorer

- from the Context Explorer icon (

) or from text links that appear in certain detail view pages (Application Detail, Host Profile, Rule Detail, and User Profile). Clicking these links automatically opens and filters the Context Explorer according to the relevant data on the detail view page. For example, clicking the Context Explorer link on a user detail page for the user jenkins constrains the explorer to show only data associated with that user

This section focuses on creating filters from scratch with the Add Filter window. For information on using the context menu to create quick filters from Context Explorer graph and list data, see Creating Filters with the Context Menu.

.

The Data Type drop-down list contains many different types of FireSIGHT System data you can use to constrain the Context Explorer. After you select a data type, you then enter a specific value for that type in the Filter field (for example, a value of Asia for the type Continent). To assist you, the Filter field presents several grayed-out example values for the data type you select. (These are erased when you enter data in the field.)

The following table lists the data types available as filters, with examples and brief definitions of each. Note that The DC500 Defense Center does not display and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect data for features they do not support. See the Supported Access Control Capabilities by Device Model table for a summary of Series 2 device and Cisco NGIPS for Blue Coat X-Series features.

Table 56-2 Filter Data Types

Type

Example Values

Definition

Access Control Action

Allow, Block

Action taken by your access control policy to allow or block traffic

Application Category

web browser, email

General classification of an application’s most essential function

Application Name

Facebook, HTTP

Name of an application

Application Risk

Very High, Medium

Estimated security risk of an application

Application Tag

encrypts communications, sends mail

Additional information about an application; applications can have any number of tags, including none

Application Type

Client, Web Application

Type of an application: application protocol, client, or web application

Business Relevance

Very Low, High

Estimated relevance of an application to business activity (as opposed to recreation)

Continent

North America, Asia

Continent associated with a routable IP address detected on your monitored network

Country

Canada, Japan

Country associated with a routable IP address detected on your monitored network

Device

device1.example.com, 192.168.1.3

Name or IP address of a device on your monitored network

Event Classification

Potential Corporate Policy Violation, Attempted Denial of Service

Capsule description of an intrusion event, determined by the classification of the rule, decoder, or preprocessor that triggered it

Event Message

dns response, P2P

Message generated by an event, determined by the rule, decoder, or preprocessor that triggered it

File Disposition

Malware, Clean

Cloud-determined disposition of a file for which the Defense Center performed a malware cloud lookup

File Name

Packages.bz2

Name of a file detected in network traffic

File SHA256

any 32-bit string

SHA-256 hash value of a file for which the Defense Center performed a malware cloud lookup

File Type

GZ, SWF, MOV

File type detected in network traffic

File Type Category

Archive, Multimedia, Executables

General category of file type detected in network traffic

IP Address

192.168.1.3, 2001:0db8:85a3::0000/24

IPv4 or IPv6 addresses, address ranges, or address blocks

Note that searching for an IP address returns events where that address was either the source or the destination for the event

Impact Level

Impact Level 1, Impact Level 2

Estimated impact of an event on your monitored network

Inline Result

dropped, would have dropped

Whether traffic was dropped, would have been dropped, or was not acted upon by the system

IOC Category

High Impact Attack, Malware Detected

Category for a triggered Indication of Compromise (IOC) event

IOC Event Type

exploit-kit, malware-backdoor

Identifier associated with a specific Indication of Compromise (IOC), referring to the event that triggers it

Malware Threat Name

W32.Trojan.a6b1

The name of a malware threat

OS Name

Windows, Linux

Name of an operating system

OS Version

XP, 2.6

Specific version of an operating system

Priority

high, low

Estimated urgency of an event

Security Intelligence Category

Malware, Spam

Category of risky traffic, as determined by Security Intelligence

Security Zone

My Security Zone, Security Zone X

A set of interfaces through which traffic is analyzed and, in an inline deployment, passes

SSL

yes, no

SSL- or TLS-encrypted traffic

User

wsmith, mtwain

Identity of a user logged in to a host on your monitored network

In the Filter field, you can input special search parameters such as * and ! essentially as you can in event searches. You can create exclusionary filters by prefixing filter parameters with the ! symbol. For more information on the search constraints typically supported by the FireSIGHT System, see Using Wildcards and Symbols in Searches.

When multiple filters are active, values for the same data type are treated as OR search criteria: all data that matches at least one of the values appears. Values for different data types are treated as AND search criteria: to appear, data must match at least one value for each filtered data type. For example, data that appears for the filter set of Application: 2channel, Application: Reddit, and User: edickinson must be associated with the user edickinson AND either the application 2channel OR the application Reddit.

After you confirm a data type and value for your filter, a filter widget appears at the top left of the page, displaying the new filter’s data type and value.

button.

Note that some filter types are incompatible with others: for example, filters that relate to intrusion events (such as Device and Inline Result) cannot be applied at the same time as connection event-related filters (such as Access Control Action) because the system cannot sort connection event data by intrusion event data. The system automatically prevents incompatible filters from simultaneously applying; when one filter type is more recently activated, filters of the incompatible type are hidden as long as the incompatibility exists.

Note that the data displayed depends on such factors as how you license and deploy your managed devices, whether you configure features that provide the data and, in the case of Series 2 appliances, whether the appliance supports a feature that provides the data. For example, because neither the DC500 Defense Center nor Series 2 devices support URL filtering by category and reputation, the DC500 Defense Center does not display data for this feature and Series 2 devices do not detect this data.

To create a new filter from the Add Filter window:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Context Explorer.

The Context Explorer appears.

).

The Add Filter pop-up window appears.

Step 3 From the Data Type drop-down list, select the data type you want to filter on.

The Filter field populates with example values for that data type.

Step 4 In the Filter field, type the data type value you want to filter on.

Step 5 Click OK.

Your filter is added. The Context Explorer reappears and a corresponding filter widget appears.

Step 6 Optionally, repeat the previous steps to add more filters until you have the filter set you need. Note that because the Context Explorer does not automatically refresh, your filters are not applied when you add them.

Step 7 Click Apply Filters.

Your filters are applied and the Context Explorer refreshes to reflect the filtered data.

To delete a filter:

Access: Admin/Any Security Analyst

) on any filter widget.

The filter is deleted.

To clear all filters:

Access: Admin/Any Security Analyst

Step 1 Click the Clear button that appears to the right of the filter widgets.

All filters are cleared.

Note that this button does not appear if no filters have been created.

Creating Filters with the Context Menu

License: FireSIGHT

While exploring Context Explorer graph and list data, you can click on data points, then use the context menu to quickly create a filter based on that data, either inclusive or exclusive. If you use the context menu to filter on information of data type Application, User, or Intrusion Event Message, or any individual host, the filter widget includes a widget information icon that links to the relevant detail page for that data type (such as Application Detail for application data). Note that you cannot filter on URL data.

You can also use the context menu to investigate specific graph or list data in more detail. For information, see Drilling Down on Context Explorer Data.

To create a filter from the context menu:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Context Explorer.

The Context Explorer appears.

Step 2 In any explorer section except Traffic and Intrusion Events over Time or sections that contain URL data, click a data point you want to filter on.

The context menu pop-up window appears nearby.

Step 3 You have two options:

- To add a filter for this data, click Add Filter .

The filter is added and its widget appears at upper left.

- To add an exclusion filter for this data, click Add Exclude Filter . The filter, when applied, displays all data not associated with the excluded value.

The filter is added and its widget appears at upper left. Exclude filters display an exclamation point before the filter value.

To view filter detail:

Access: Admin/Any Security Analyst

) on any eligible filter widget.

A new window opens with the detail page relevant to the filter’s data type.

Bookmarking Filters

License: FireSIGHT

Filters function as a simple, agile tool to get the precise FireSIGHT data context you need at any given time. They are not intended as permanent configuration settings, and disappear when you navigate away from the Context Explorer or end your session. However, your organization may use certain filter combinations frequently. To preserve filter settings for later use, you can create a browser bookmark of the Context Explorer with your preferred filters applied. Because applied filters are incorporated in the Context Explorer page URL, loading a bookmark of that page also loads the corresponding filters.

Working with Reports

The FireSIGHT System provides a flexible reporting system that allows you to quickly and easily generate multi-section reports with the event views or dashboards that appear on your Defense Center. You can also design your own custom reports from scratch. Reporting is available only on Defense Centers.

A report is a document file formatted in PDF, HTML, or CSV with the content you want to communicate. A report template specifies the data searches and formats for the report and its sections. The FireSIGHT System includes a powerful report designer that automates the design of report templates. You can replicate the content of any event view table or dashboard graphic displayed in the web interface.

You can build as many report templates as you need. Each report template defines the individual sections in the report and specifies the database search that creates the report’s content, as well as the presentation format (table, chart, detail view, and so on) and the time frame. Your template also specifies document attributes, such as the cover page and table of contents and whether the document pages have headers and footers (available only for reports in PDF format). You can export a report template in a single configuration package file and import it for reuse on another Defense Center.

You can include input parameters in a template to expand its usefulness. Input parameters allow you to produce tailored variations of the same report. When you generate a report with input parameters, the generation process prompts you to enter a value for each input parameter. The values you type constrain the report contents on a one-time basis. For example, you can place an input parameter in the destination IP field of the search that produces an intrusion event report; at report generation time, you can specify a department’s network segment when prompted for the destination IP address. The generated report then contains only information concerning that particular department.

See the following sections for more information on reports and report templates:

- Understanding Report Templates

- Creating and Editing Report Templates

- Generating and Viewing Reports

- Using Report Generation Options

- Managing Report Templates and Report Files

Understanding Report Templates

License: Any

The FireSIGHT System’s reporting feature allows you to quickly capture the content of any event view, dashboard, or workflow from your Defense Center and present it in report format. You use report templates to define the content and format of the data in each of the report’s sections, as well as the document attributes of the report file (cover page, table of contents, and page headers and footers). After you generate a report, the template stays available for reuse until you delete it.

Your reports contain one or more information sections. You choose the format (text, table, or chart) for each section individually. The format you select for a section may constrain the data that can be included. For example, you cannot show time-based information in certain tables using a pie chart format. You can change the data criteria or format of a section at any time to obtain optimum presentation.

You can base a report’s initial design on a predefined event view, or you can start your design by importing content from any defined dashboard, workflow, or summary. You can also start with an empty template shell, adding sections and defining their attributes one by one.

All sections in a report template have a title bar and various attribute fields that control the section’s contents and appearance. For more information, see the following:

- the Report Section Title Bar Elements table

- the Report Section Fields table

Table 57-1 Report Section Title Bar Elements

Attribute

Definition

section title

Contains the name of the section as it appears in the report. Change it by clicking it and typing a new name. To avoid display issues, the system truncates long section title names when viewed on the Report Sections page.

section title icons

) to add a duplicate of the section to the report template. ) to minimize the section. ) to delete the section, after confirmation.

Table 57-2 Report Section Fields

Field Name

Definition

Table

Presents a drop-down menu that allows you to select the table from which the section data is extracted.

Preset

Presents a drop-down menu of predefined searches. You can select an appropriate preset to initialize the search criteria when you define a new search.

Format

Presents icons that allow you to select the format of the section data. Options include:
Bar chart: Compares quantities of the selected variables. Line chart: Shows trends/changes over time of a selected variable. Available only for time-based tables. . Table view: Shows values of attributes for each record. Not available for summary or statistical data. Detail view: Shows complex object data associated with certain events, such as packets (for intrusion events) and host profiles (for host events). Format is available only for certain event types that involve such objects. Output may degrade performance if large numbers are requested.

Search or Filter

Presents a drop-down menu of searches or application filters.
); see Working with Searches in Report Template Sections.
For the Application Statistics table, you use a user-defined application Filter to constrain a report; for information on creating filters, see Working with Application Filters.

X-Axis

Presents a drop-down menu of available data columns for the X-axis of the selected chart. Appears only when you select a chart format. For line charts, the X-axis value is always Time. For bar and pie charts, you cannot select Time as the X-axis value.

Y-Axis

Presents a drop-down menu of available data columns for the Y-axis of the selected chart.

Section Description

Defines the descriptive text that precedes the search data in the section. Enter a combination of text and input parameters. Default for a new section is the following set of two input parameters: $<Time Window> and $<Constraints>.

For more information on input parameters, see Using Input Parameters.

Time Window

Defines the time window for the data that appears in the section. If the section searches time-based tables, you can select the check box to inherit the report’s global time window. Alternatively, you can set a specific time window for the section. For information about setting the time window, see Editing the Sections of a Report Template.

Results

Select either Top or Bottom and enter the maximum number of records to be included in the section.

Color

Defines the colors for graphed data in the section. Select one or more colors, as applicable.

Creating and Editing Report Templates

License: Any

You can build a new report template in any of the following ways:

- Creating a New Report Template

- Creating a Report Template from an Existing Template

- Creating a Report Template from an Event View

- Creating a Report Template by Importing a Dashboard or Workflow

To modify and customize a report template, see the following sections:

- Editing the Sections of a Report Template

- Working with Searches in Report Template Sections

- Using Input Parameters

- Editing Document Attributes in a Report Template

- Customizing a Cover Page

- Managing Logos

Creating a New Report Template

License: Any

If you do not want to copy an existing report template, you can create an entirely new template. First, you create a default template shell. Then, in the order you prefer, you design the individual template sections and set attributes for the report document. For information on these steps, see the following sections:

- Creating a Template Shell

- Configuring the Content of the Template Sections

- Setting Attributes for PDF and HTML Report Documents

Creating a Template Shell

License: Any

A report template is a framework of sections, each independently built from its own database query. The first step in creating a template is to generate the framework shell that allows you to add and format the sections.

To create a template shell:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Click the Report Templates tab.

The Report Templates page appears.

Step 3 Click Create Report Template.

The Report Sections page appears with the default template name, New Report, in the Report Title field.

Step 4 Optionally, type a name for your new template in the Report Title field and click Save. The report title can contain any combination of alphanumeric characters and spaces.

An entry with the new template name appears on the Report Templates page list.

).

The added input parameters appear in the Report Title field. For information on input parameters, see Using Input Parameters.

Step 6 Use the set of add icons under the Report Sections title bar to insert section shells as necessary. For information on section formatting, see the Report Section Fields table.

Each added section appears at the bottom of the template. Drag it to the correct location.

Step 7 Click the section title on the section title bar and type a name for the section (using a maximum of 120 characters).

Step 8 Click Save to save the template.

Your template is saved.

Configuring the Content of the Template Sections

License: Any

Each template section consists of a dataset generated by a search or filter, and has a format specification (table, pie chart, and so on) that determines the mode of presentation. You further determine section content by selecting the fields in the data records you want to include in the output, as well as the time frame and number of records to show.

To configure report template sections:

Access: Admin/Any Security Analyst

Step 1 Edit the section attributes as described in Editing the Sections of a Report Template.

Step 2 Optionally, click Preview at the bottom of the section window to view the column layout or graphic format you selected.

Note Use the section preview utility to check the column selection and output characteristics such as pie chart colors. It is not a reliable indicator of the correctness of your configured search.

Setting Attributes for PDF and HTML Report Documents

License: Any

The report you generate from the template has several document attributes that span all sections and control features, such as the cover page, headers and footers, page numbering, and so on.

To set attributes for the report documents:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Click the Report Templates tab.

The Report Templates page appears.

Step 3 Click Edit for the report template you want to use to generate the report.

The Report Sections page for your template appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears.

Step 5 For documents in PDF or HTML format, perform the tasks described in Editing Document Attributes in a Report Template.

If you selected CSV as your document format, you have no document attributes to set.

Creating a Report Template from an Existing Template

License: Any

If you identify a good model among your existing templates, you can copy the template and edit its attributes to create a new report template. Cisco also provides a set of predefined report templates, visible on the Reports Tab in the list of templates. For a description of their attributes, see Using Predefined Report Templates.

To create a report template from an existing template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Click the Report Templates tab.

The Report Templates page appears. For information about Cisco-provided report templates, see Using Predefined Report Templates.

) next to the report template you want to copy as a model.

The copied template appears as a new report template.

Step 4 In the Report Title field, type a name for your new report template.

Step 5 Click Save.

The report template is saved and an entry for the new report template appears on the Report Templates page.

Step 6 Make changes to the template as needed.

For information on defining the sections of the template and the document attributes, see:

- Editing the Sections of a Report Template

- Editing Document Attributes in a Report Template

Using Predefined Report Templates

License: Any

You can use the following predefined report templates as-is, edit them, or use them as the basis for your own templates:

- Host Report: $<Host>

- User Report: $<User>

- Attack Report: Attack $<Attack SID>

- Malware Report

- FireSIGHT Report: $<Customer Name>

- Files Report

Host Report: $<Host>

The Host Report: $<Host> report template provides information about a specific host on the network. This report template contains the following sections:

- Server Applications

- Client Applications

- Intrusion Events Originating from This Host

- Intrusion Events Destined to This Host

- Connections Originating from This Host

- Connections Destined to This Host

- Users of This Host

- White List Violations by This Host

User Report: $<User>

The User Report: $<User> report template provides information about a specific user on the network. This report template contains the following sections:

- Client Applications Used by This User

- Web Applications Used by This User

- Application Protocols Used by This User

- Comprehensive List of Applications Used by This User

- Intrusion Events Originated By This User’s Machines

- Intrusion Events Destined to This User’s Machines

- Connections Originating from This User’s Machines

- Connections Destined to This User’s Machines

- Hosts for This User

Attack Report: Attack $<Attack SID>

The Attack Report: Attack $<Attack SID> report template provides information about a specific attack on the network. This report template contains the following sections:

- General Information About This Attack

- Number of Attacks

- Number of Machines Initiating Attack

- Number of Machines Being Attacked

- Sources of This Attack

- Destinations of This Attack

- Traffic Patterns of This Attack

Malware Report

The Malware Report report template provides information about network and endpoint-based malware events. This report template contains the following sections:

- Malware Threats

- Threat Detections over Time

- Application Protocols Transferring Malware

- Hosts Receiving Malware

- Hosts Sending Malware

- Users Affected by Malware

- Malware Intrusions

- File Types Infected with Malware

- Applications Introducing Malware

- Table View of Malware Events

Note that neither Series 2 devices nor the DC500 Defense Center support network-based malware protection, which can affect the data detected and displayed. For example, a Series 3 Defense Center managing only Series 2 devices can display only endpoint-based malware events.

FireSIGHT Report: $<Customer Name>

The FireSIGHT Report: $<Customer Name> report template provides overall information about an organization’s network. This report template contains the following sections:

- Summary of Application Traffic by Risk

- Risky Applications with Low Business Relevance

- Users of Risky Applications

- Anonymizers and Proxies

- Typically High Bandwidth Applications

- Applications by Total Bandwidth

- Hosts Accessing Sensitive Network

- Users Accessing Sensitive Network

- Applications on Sensitive Network

- Ports and Protocols Related to Sensitive Network

- Hosts Visiting Malicious URLs

- Users Visiting Malicious URLs

- Granular Application Usage

- Web Applications

- Client Applications

- Application Protocols

- Web Browser Versions

- Operating System Versions

- Overall User Activity

- Intrusion Events by Impact

- Intrusion Events by Impact (After Blocking)

- Intrusion Events by Application

- Top Intrusion Events

- Comprehensive Application List

Files Report

The Files Report report template provides information about files detected in network traffic by managed devices. This report template contains the following sections:

- File Transfers over Time

- Application Protocols Used by File Transfers

- File Dispositions

- File Actions

- Hosts Receiving Files

- Hosts Sending Files

- Users Transferring Files

- File Categories

- File Types

- File Names

- Table View of File Events

Creating a Report Template from an Event View

License: Any

Before you generate a report, the reporting system creates a report template that you can modify to meet your needs. You can add additional sections, modify automatically included sections, and delete sections.

To create a report template from an event view:

Access: Admin/Any Security Analyst

Step 1 Populate an event view with the events you want in the report. You can do this in various ways:

- Use an event search to define the events you want to view. For details on using the event search, see Searching for Events.

- Drill down through a workflow until you have the appropriate events in your event view. For details on workflows and how to constrain events within a workflow, see Understanding and Using Workflows.

Step 2 From the event view page, click Report Designer.

The Report Sections page appears with a section for each view in the captured workflow.

Step 3 Optionally, type a new name in the Report Title field and click Save.

) in the section’s title bar, and confirm the deletion.

The deleted sections disappear.

Note The last report section in some workflows contains detail views that show packets, host profiles, or vulnerabilities, depending on the workflow. Retrieving large numbers of events with these detail views when generating your report may affect performance of the Defense Center.

Step 5 Optionally, adjust the settings of the fields in your report sections.

For details on configuring the fields in a report section, see Editing the Sections of a Report Template.

Tip To view the current column layout or chart formatting for a section, click the section’s Preview link.

Step 6 Optionally, change the title of any section by clicking the section title in the title bar.

The Set Section Title pop-up window appears. Type the section title and click OK.

).

A new page break object appears at the bottom of the template. Drag it in front of the section that should start the new page. For information on using page breaks, see Editing the Sections of a Report Template.

).

A new text section appears at the bottom of the template. Drag it to the place where it should appear in the report template. For information about editing a text section, see Editing the Sections of a Report Template.

Tip Text sections, which support rich text (bold, italics, variable font size, and so on) as well as imported images, are useful for introductions to your report or your report sections.

Step 9 Optionally, click Advanced Settings to add a cover page, table of contents, starting page number, or header and footer text. For more information, see Editing Document Attributes in a Report Template.

Step 10 When the report template is correct, click Save.

The report template is saved and an entry for the report template appears on the Report Templates page.

Creating a Report Template by Importing a Dashboard or Workflow

License: Any

You can quickly create a new report by importing dashboards, workflows, and statistics summaries. The import creates a section for each widget graphic in your dashboard and each event view in your workflow. You can delete any unnecessary sections to focus on the most important information. The following table describes the import options.

Table 57-3 Data Source Options on Import Report Sections Window

Select this option...

To import...

Import Dashboard

any custom analysis widget on the selected dashboard.

Import Workflow

any predefined or custom workflow.
imports the views in the Traffic by Port workflow generated from the Connection Events table.

Import Summary Sections

any of the following generic summaries:

- Intrusion Detailed Summary

- Intrusion Short Summary

- Discovery Detailed Summary

- Discovery Short Summary

To create a report template from a dashboard, workflow, or statistics summary:

Access: Admin/Any Security Analyst

Step 1 Identify the dashboard, workflow, or summary you want to replicate in your report.

Step 2 Select Overview > Reporting.

Step 3 Click the Report Templates tab.

The Report Templates page appears.

Step 4 Click Create Report Template.

The Report Sections page appears.

Step 5 Type a name for your new report template in the Report Title field.

Step 6 Click Save to save the report template under the new name.

The report template is saved and an entry for the report template appears on the Report Templates page.

).

The Import Report Sections pop-up window appears. You can choose any of the data sources described in the Data Source Options on Import Report Sections Window table.

Step 8 Select a dashboard, workflow or summary from the drop-down menus.

Step 9 For the data sources you want to add, click Import.

The Report Sections page for your template reappears with a section for each element of the selected data source. For dashboards, each widget graphic will have its own section; for workflows, each event view will have its own section.

Step 10 Make changes to the content of your sections as needed.

For information on editing a report template, see Editing the Sections of a Report Template.

Note The last report section in some workflows contains detail views that show packets, host profiles, or vulnerabilities, depending on the workflow. Retrieving large numbers of events with these detail views when generating your report may affect performance of the Defense Center.

Step 11 When the report template is correct, click Save.

The report template is saved and an entry for the report template appears on the Report Templates page.

Editing the Sections of a Report Template

License: Any

You can modify a variety of report section attributes to adjust the content of the section and its data presentation. For information, see the following sections:

- Setting the Table and Data Format for a Template Section

- Specifying the Search or Filter for a Template Section

- Setting the Search Fields that Appear in Table Format Sections

- Adding a Text Section to a Report Template

- Adding a Page Break to a Report Template

- Setting the Time Window for a Template and Its Sections

- Renaming a Template Section

- Previewing a Template Section

Note Security Analysts can edit only report templates they created.

Setting the Table and Data Format for a Template Section

License: Any

Each section in a report template queries a database table to generate content for that section. Changing the section’s data format uses the same data query, but modifies the fields that appear in the section according to the analytical purpose of the format type. For example, the table view of intrusion events populates the section with a large number of data fields per event record, while a pie chart section shows the portion of all matching records that each selected attribute represents, with no details about individual events. Bar chart sections compare the total counts of matching records that have specific attributes. Line charts summarize changes in the matching records over time with respect to a single attribute. Line charts are available only for data that is time-based, not for information about hosts, users, third-party vulnerabilities, and so on.

For information on the different available formats, see the Report Section Fields table.

To select the table and output format for a template section:

Access: Admin/Any Security Analyst

Step 1 Use the Table drop-down menu to select the table to query in this section.

Icons appear in the Format field for each of the output formats available for the selected table.

Step 2 Select the applicable output format icon for the section. For information about these formats, see the Report Section Title Bar Elements table.

The fields included in the output appear.

field.

The Search Editor pop-up window appears with options for constraining the search. For information on using this window, see Working with Searches in Report Template Sections.

Step 4 For graphic output formats (pie chart, bar chart, and so on), adjust the X-Axis and Y-Axis parameters using the drop-down menus.

When you select a value for the X-axis, only compatible values appear in the Y-axis drop-down menu, and vice versa.

Step 5 For table output, select the columns, order of appearance, and sort order in your output. For detailed information, see Setting the Search Fields that Appear in Table Format Sections.

Step 6 Click Save to save the template.

Your template is saved.

Specifying the Search or Filter for a Template Section

License: Any

The search or filter in a report section specifies the database query on which the section content is based. For most tables, you can constrain a report using a predefined or saved search, or you can create a new search on the fly:

- Predefined searches serve as examples for searching certain event tables and can provide quick access to important information about your network that you may want to include in reports.

- Saved event searches include all public event searches that you or others have created, plus all your saved private event searches. For information on defining, naming, and using saved event searches, see Searching for Events.

- Saved searches for the current report template are accessible only in the report template itself. The search names of saved report template searches end with the string “Custom Search.” Users create these searches while designing reports.

For the Application Statistics table, you use a user-defined application filter to constrain a report; for information on creating filters, see Working with Application Filters.

To specify a search or filter for a template section:

Access: Admin/Any Security Analyst

Step 1 Select the database table to query from the Table drop-down menu:

- For most tables, the Search drop-down list appears.

- For the Application Statistics table, the Filter drop-down list appears.

Step 2 Select the search or filter you want to use to constrain the report.

). For more information, see Working with Searches in Report Template Sections.

Setting the Search Fields that Appear in Table Format Sections

License: Any

If you include table data in a section, you can choose which fields in the data record to show. All fields in the table are available for inclusion or exclusion. You select fields that accomplish the purpose of the report, then order and sort them accordingly.

To add and delete the fields in a table format section:

Access: Admin/Any Security Analyst

parameter.

The Table Field Selector window appears.

Step 2 Optionally, add and delete fields, and drag the field icons into the column order you want.

Step 3 Optionally, change the sort order of any column. Use the drop-down lists on each field icon to set the sort order and priority.

Step 4 When the fields are in the right order and have the necessary sort characteristics, click OK.

The Report Sections page appears.

Adding a Text Section to a Report Template

License: Any

You can add text sections to your templates to provide custom text, such as an introduction, for the whole report or for individual sections. Text sections can have rich text with multiple font sizes and styles (bold, italic, and so on) as well as input parameters and imported images. For information on input parameters, see Using Input Parameters.

To add a text section to a report template:

Access: Admin/Any Security Analyst

).

A text section appears at the bottom of the template.

Step 2 Drag the new text section to its intended position in the report template.

Step 3 Optionally, add page breaks before and after the text section. For information on page breaks, see Adding a Page Break to a Report Template.

Step 4 Optionally, click the text section’s generic name in the title bar to type a new name.

Step 5 Add formatted text and images to the body of the text section. You can include input parameters that dynamically update when you generate the report.

Step 6 Click Save when finished.

Your template is saved.

Adding a Page Break to a Report Template

License: Any

You can add page breaks before or after any section in the template. This feature is particularly helpful for multi-section reports with text pages that introduce the various sections.

To add a page break:

Access: Admin/Any Security Analyst

).

A page break appears at the bottom of the template.

Step 2 Drag the page break to its intended location, before or after a section.

Step 3 Repeat the process for all page breaks you add to the template.

Setting the Time Window for a Template and Its Sections

License: Any

A report template’s time window defines the template’s reporting period. Report templates with time-based data (such as intrusion or discovery events) have a global time window, which the time-based sections in the template inherit by default when created. Changing the global time window changes the local time window for the sections that are configured to inherit the global time window. You can disable time window inheritance for an individual section by clearing its Inherit Time Window check box. You can then edit the local time window.

Note Global time window inheritance applies only to report sections with data from time-based tables, such as intrusion events and discovery events. For sections that report on network assets (hosts and devices) and related information (such as vulnerabilities), you must set each time window individually.

To change a report template’s global time window:

Access: Admin/Any Security Analyst

) next to the report template you want to edit.

The Report Sections page appears.

Step 2 Click Generate.

The Generate Report pop-up window appears.

).

The Events Time Window page appears in a new window. For information about using this page, see Setting Event Time Constraints.

Step 4 When you are finished, click Apply on the Events Time Window.

The Generate Report pop-up window reappears with the new time window.

Step 5 Click Cancel to return to the Report Sections page, or OK to generate the report.

Your report can have different time ranges per section. For example, your first section could be a summary for the month, and the remaining sections could drill down into details at the week level. In such cases, you set the section-level time windows individually.

To configure a section’s local time window:

Access: Admin/Any Security Analyst

Step 1 On the Report Sections page of a template, clear the Inherit Time Window check box for the section if it is present.

The local section time window icon appears.

).

The Events Time Window page appears. For information about using this page, see Setting Event Time Constraints.

Note Sections with data from statistics tables can have only sliding time windows.

Step 3 When you have set a new local time window, click Apply on the Events Time Window.

Step 4 Click Save.

The Report Sections page appears for further editing.

Renaming a Template Section

License: Any

When you create a new template, the sections you add receive generic section names and should be renamed to indicate their content.

To rename a template section:

Access: Admin/Any Security Analyst

Step 1 Click the current section name in the section header.

The Set Section Title pop-up window appears.

Step 2 Type a new name for the section (using a maximum of 120 characters) and click OK.

The name in the section title bar is changed.

Previewing a Template Section

License: Any

The preview function shows the field layout and sort order for table views and important legibility characteristics of graphics, such as pie chart colors.

To preview a template section:

Access: Admin/Any Security Analyst

Step 1 At any time while editing a section, click Preview for the section.

The Preview pop-up window appears.

Step 2 Close the preview by clicking OK at the bottom of the window.

The Report Sections page appears.

Working with Searches in Report Template Sections

License: Any

The key to generating successful reports is defining the searches that populate the report’s sections. The FireSIGHT System provides a search editor to view the searches available in your report templates and to define new custom searches.

Tip The custom searches you make in a report template are specific to the template where you create them. You can make searches that are reusable across all report templates in the event viewer. When you save a custom search in the event viewer, it appears in the Search drop-down menu of all report templates. For details on using the event viewer to create and save custom searches, see Searching for Events.

To create a custom search:

Access: Admin/Any Security Analyst

field.

The Search Editor page appears with the table to be searched selected.

Step 2 Optionally, from the Saved Searches drop-down menu, select a predefined search.

The drop-down presents all available predefined searches for this table, including system-wide and report-specific predefined searches.

Step 3 Edit the search criteria in the appropriate fields. For certain fields, your constraints can include the same operators (<, <>, and so on) as event searches. For the syntax of search criteria, see Searching for Events.

If you enter multiple criteria, the search returns only the records that match all the criteria.

) appears, you can insert an input parameter from the drop-down menu instead of typing a constraint value. For information on using input parameters in report designs, see Using Input Parameters.

For some search fields, the drop-down menu may contain user-defined managed objects instead of, or with, input parameters. Managed objects, which have distinctive icons depending on their type, are system configuration variables you can use as values in constraining searches. However, they do not produce the generation-time query for user input that occurs with input parameters. For information on managed objects, see Managing Reusable Objects.

Note When you edit the constraints of a reporting search, the system saves your edited search under the following name: section custom search, where section is the name in the section title bar followed by the string custom search. To have meaningful names for your saved custom searches, be sure you change the section name before you save the edited search. You cannot rename a saved reporting search.

Step 5 When finished modifying the fields in the search editor, click OK.

The Report Sections page reappears and a new predefined search appears in the section’s Search drop-down menu.

Using Input Parameters

License: Any

) indicates the fields that can process them. There are two kinds of input parameters:

- Predefined — see the Predefined Input Parameters table

- User-defined — see User-Defined Input Parameter Types table

Predefined Input Parameters

License: Any

Predefined input parameters are resolved by internal system functions or configuration information. For example, at report generation time, the system replaces the $<Time> parameter with the current date and time. The following table defines the parameters available for use. You might, for example, include $<Month> in the title of a monthly summary report that generates automatically under scheduler control. Your report title then automatically updates with the correct month.

Table 57-4 Predefined Input Parameters

Insert this parameter...

...to include this information in your template:

$<Logo>

The selected uploaded logo

$<Report Title>

The report title

$<Time>

The date and time of day the report ran, with one-second granularity

$<Month>

The current month

$<Year>

The current year

$<System Name>

The name of the Defense Center

$<Model Number>

The model number of the Defense Center

$<Time Window>

The time window currently applied to the report section

$<Constraints>

The search constraints currently applied to the report section

The following table lists the valid input parameters that can be used in different areas within the Report Templates page.

Table 57-5 Predefined Input Parameter Usage

Parameter

Report Template Cover Page

Report Template Report Title

Report Template Section Description

Report Template Text Section

Generate Report File Name

Generate Report Email Subject, Body

$<Logo>

yes

no

no

no

no

no

$<Report Title>

yes

no

yes

yes

yes

yes

$<Time>

yes

yes

yes

yes

yes

yes

$<Month>

yes

yes

yes

yes

yes

yes

$<Year>

yes

yes

yes

yes

yes

yes

$<System Name>

yes

yes

yes

yes

yes

yes

$<Model Number>

yes

yes

yes

yes

yes

yes

$<Time Window>

no

no

yes

no

no

no

$<Constraints>

no

no

yes

no

no

no

User-Defined Input Parameters

License: Any

You can create your own input parameters to supply as constraints in section searches. Constraining a search with an input parameter instructs the system to collect a value at generation time from the person who requests the report. In this way, you can dynamically tailor a report at generation time to show a particular subset of data without changing the template. For example, you can provide an input parameter for the Destination IP field of a report section’s search. Then, when you generate the report, you can type the IP network segment for a particular department to get data for that department only.

Tip You can also type * in an input parameter field, with the effect of ignoring the constraint.

You can also define string-type input parameters to add dynamic text in certain fields of your report, such as in emails (subject or body), report file names, and text sections. You can personalize reports for different departments, with customized report file names, email addresses, and email messages, using the same template for all.

Each input parameter you define has a name and a type. The following table describes the parameter types.

Table 57-6 User-Defined Input Parameter Types

Use this parameter type...

With fields with this data...

Network/IP

any IP address or network segment in CIDR format

Application

name of an application protocol, client application, or web application

Event Message

any event view message

Device

3D appliance (Defense Center or FireSIGHT System managed device)

Username

user identification such as initiator user and responder user

Number (VLAN ID, Snort ID, Vuln ID)

any VLAN ID, Snort ID, or vulnerability ID

String

text fields such as application or OS version, notes, or descriptions

An input parameter’s type determines the search fields where you can use it. You can use a given type only in appropriate fields, as described in the User-Defined Input Parameter Types table. For example, a user parameter you define as a string type is available for insertion in text fields but not in fields that take an IP address.

To create user-defined input parameters for a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears.

).

The Add Input Parameter pop-up window appears.

Step 6 Type the parameter name in the Name field and use the Type drop-down menu to select the type, then click OK.

The new parameter appears in the Input Parameters menu.

Step 7 Repeat the steps above until you have defined all the parameters you need.

Step 8 Click OK.

Your new input parameters are saved for this template and the Report Sections page reappears.

If you reuse a report template, you can change the name and type for any input parameters to better reflect the purpose of the new report.

To edit user-defined input parameters for a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears. The Input Parameters section lists all available user-defined parameters for the report template.

).

The Edit Input Parameter pop-up window appears.

Step 6 Change the parameter name in the Name field and the parameter type using the Type drop-down menu, then click OK.

The changed parameter appears in the Input Parameters section.

Step 7 Repeat the steps above until you have defined all the parameters you need. Click OK.

Your changes are saved and the Report Sections page reappears.

To delete user-defined input parameters for a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears. The Input Parameters section lists all available user-defined parameters for the report template.

) next to the input parameter and confirm.

Step 6 Click OK.

The input parameter is deleted and the Report Sections page reappears.

You use input parameters to expand the usefulness of your searches. The input parameter instructs the system to collect a value at generation time from the person who requests the report. In this way, you can dynamically constrain a report at generation time to show a particular subset of data without changing the search. For example, you can provide an input parameter for the Destination IP field of a report section that drills down on security events at a department level. When you generate the report, you can type the IP network segment for a particular department to get data for that department only.

To constrain the search in a report template with user-defined input parameters:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the template you want to edit.

The Report Sections page appears.

field within the section.

).

).

The input parameter appears in the field.

Note Input parameters you define are available only for search fields that match their parameter type. For example, a parameter of type Network/IP is available only for fields that accept IP addresses or network segments in CIDR format.

Step 6 Click OK when you have added all necessary input parameters.

The Report Sections page appears with your changes.

Editing Document Attributes in a Report Template

License: Any

Before you generate your report, you can set document attributes that affect the report’s appearance. These attributes include the optional cover page and table of contents. Support for some attributes depends on the selected report format: PDF, HTML, or CSV. The following table provides further details on attribute support by format.

Table 57-7 Document Attribute Support

Attribute

PDF Support?

HTML Support?

CSV Support?

Cover page

yes, with optional logo and custom appearance

yes, with optional logo and custom appearance

no

Table of contents

yes

yes

no

Page headers and footers

yes, with optional text or logo in any field

no

no

Custom starting page number

yes

no

no

Option to suppress numbering of first page

yes

no

no

To set the document attributes for PDF and HTML reports:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the report template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears.

Step 5 Select Include Cover Page to add a cover page.

field to edit the cover page design.

For more information, see Customizing a Cover Page.

Step 7 Select Include Table of Contents to add a table of contents.

Step 8 Configure the header and footer using the drop-downs of the three Header and Footer fields. You select header and footer content from the drop-down menus: logo, date, page number, and so on.

If you select Logo, the default logo image appears in the selected field. To change the default logo image, see Managing Logos.

Step 9 In the Page Number Start field, select the page number of the report’s first page.

Select Number First Page? to show the page number on the first page following the cover page. If selected, the cover page is not numbered.

Step 10 Click OK.

The document attributes are saved and the Report Sections page reappears.

Customizing a Cover Page

License: Any

You can customize a report template’s cover page. Cover pages can have rich text with multiple font sizes and styles (bold, italic, and so on) as well as input parameters and imported images. For information on input parameters, see Using Input Parameters.

To customize a report template cover page:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears and displays the list of templates.

) for a report template.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears.

.

The Edit Cover Page window appears, displaying the default cover page design.

Step 6 Edit the cover page design within the rich text editor.

Step 7 Click OK.

The cover page design is saved and the Advanced Settings window reappears.

Managing Logos

License: Any

You can store multiple logos on the Defense Center and associate them with different report templates. You set the logo association when you design the template. If you export the template, the export package contains the logo.

For information on where you can insert a logo in reports, see Editing Document Attributes in a Report Template.

See the following related procedures for more information:

- Adding a New Logo

- Changing the Logo for a Report Template

- Deleting a Logo

Adding a New Logo

License: Any

Logos uploaded to your Defense Center are available for all report templates on that Defense Center. Logo images must be in JPG format.

To add a logo to a Defense Center:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the report template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears. The logo currently associated with the template appears under Logo in General Settings.

) for the logo.

The Select Logo pop-up window appears with images of currently uploaded logos.

Step 6 Click Upload Logo.

The Upload Logo pop-up window appears.

Step 7 Select the logo file to upload by doing one of the following:

- type the location of the logo file

- click the Browse button and browse to the file’s location

Step 8 Click Upload.

The image is uploaded to the Defense Center and appears in the Select Logo pop-up window.

Step 9 Optionally, associate the new logo with the current template by selecting it and clicking OK.

The Advanced Settings window reappears with the associated logo image.

Changing the Logo for a Report Template

License: Any

You can change the logo in a report to any JPG image uploaded to your Defense Center. For example, if you reuse a template, you can associate a logo for a different organization with the report.

To change the logo for a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the report template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears. The logo currently associated with the template appears under Logo in General Settings.

) for the logo.

The Select Logo pop-up window appears with images of currently uploaded logos.

Step 6 Select the logo to associate with the report template.

The selected logo is highlighted.

Step 7 Click OK.

The Advanced Settings window reappears with the associated logo image.

Deleting a Logo

License: Any

You can delete logos from your Defense Center. Deleting a logo removes it from all templates where it is used. The deletion cannot be undone.

Note that you cannot delete the predefined Cisco logo.

To delete a logo from a Defense Center:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the report template you want to edit.

The Report Sections page appears.

Step 4 Click Advanced.

The Advanced Settings pop-up window appears. The logo currently associated with the template appears under Logo in General Settings.

) for the logo.

The Select Logo pop-up window appears with images of currently uploaded logos.

Step 6 Select the logo you want to delete.

The selected logo is highlighted.

Step 7 Click Delete Logo.

The deleted logo disappears from the Select Logo pop-up window.

Step 8 Click OK.

Your changes are saved and the Advanced Settings window reappears.

Generating and Viewing Reports

License: Any

After you create and customize your report template, you are ready to generate the report itself. The generation process lets you select the report’s format (HTML, PDF, or CSV). You can also adjust the report’s global time window, which applies a consistent time frame to all sections except those you exempt. For information on setting the report time window, see Setting the Time Window for a Template and Its Sections.

If the report template includes user input parameters in its search specification, the generation process prompts you to enter values, which tailor this run of the report to a subset of the data. For information on input parameters, see Using Input Parameters.

The Reports tab lists all previously generated reports, with report name, date and time of generation, generating user, and whether the report is stored locally or remotely. A status column indicates whether the report is already generated, is in the generation queue (for example, for scheduled tasks), or failed to generate (for example, due to lack of disk space).

The Reports tab page shows all locally stored reports. It shows remotely stored reports as well, if remote storage is currently configured. The location of your currently configured report storage appears at the bottom of the page, with disk usage for local, NFS, and SMB storage. If you access remote storage using SSH, disk usage data is not available. For information on setting up remote storage, see Using Remote Storage for Reports.

Note If you store remotely and then switch back to local storage, the reports in remote storage do not appear on the Reports tab list. Similarly, if you switch from one remote storage location to another, the reports in the previous location do not appear in the list.

File names using Unicode (UTF-8) characters are not supported in PDF reports. If you generate a report in PDF format, any report sections that include special Unic ode file names (such as those appearing in file or malware events) display these file names in transliterated form.

If you have a DNS server configured and IP address resolution enabled, reports contain host names if resolution was successful. For more information, see Configuring Management Interfaces and Event Preferences.

Use the following procedures to generate and view reports. Note that users with Administrator access can view all reports; other users can view only the reports they generated. For information about managing your report files, see Downloading Reports and Deleting Reports.

To generate a report from a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Click the Report Templates tab.

The Report Templates page appears.

) for the template you want to use.

The Generate Report pop-up dialog appears.

) to add one or more input parameters to the file name. For information on input parameters, see Using Input Parameters.

Step 5 Select the output format for the report by clicking the corresponding icon: HTML, PDF, or CSV.

).

The Events Time Window pop-up window appears. For information on setting the events time window, see Setting Event Time Constraints.

Note Setting the global time window affects the content of individual report sections only if they are configured to inherit the global setting. For information on report section inheritance of the global time window, see Setting the Time Window for a Template and Its Sections.

Step 7 Type values for any fields that appear in the Input Parameters section.

Tip You can ignore user parameters by typing the * wildcard character in the field. This eliminates the user parameter’s constraint on the search.

Step 8 Optionally, if an email relay host is configured in your system policy, click Email to automate email delivery of the report when it generates. For details about email delivery features, see Distributing Reports by Email at Generation Time.

Step 9 Click OK and confirm when prompted.

The Report Generation Complete pop-up window appears with a link to view your report.

Step 10 Click either:

- the report link, which opens a new window to display the report, or

- OK to return to the Report Section page, where you can modify your report design.

You can review completed reports after initial generation, as well.

Step 11 Optionally, manage your report files. For more information, see Downloading Reports and Deleting Reports.

To view a generated report:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Click the Reports tab.

The Reports page appears.

Step 3 Click the name of the report.

The default program on your local host opens the report in a new window.

Step 4 When finished viewing the document, use your browser to return to the Reports tab.

Using Report Generation Options

License: Any

You have several additional options when generating reports. You can automatically schedule report generation, send reports via email, and store generated reports remotely. For more information, see the following sections:

- Generating Reports Using the Scheduler

- Distributing Reports by Email at Generation Time

- Using Remote Storage for Reports

Generating Reports Using the Scheduler

License: Any

You can use the FireSIGHT System scheduler to automate report generation. You can customize the schedule on a full range of time frames such as daily, weekly, monthly, and so on. For more information, see Automating Report Generation.

If you also want to distribute email reports using the scheduler, you must configure your report template and a mail relay host before scheduling the task. For more information, see Distributing Reports by Email at Generation Time and Configuring a Mail Relay Host and Notification Address.

Distributing Reports by Email at Generation Time

License: Any

When you generate a report from its template, you can choose to automatically send the report as an email attachment to a list of recipients.

Note You must have a properly configured mail relay host to deliver a report by email. If you have not previously set up a mail host, see Configuring a Mail Relay Host and Notification Address.

To email a report at generation time:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) for the template you want to generate from.

The Generate Report pop-up window appears.

Step 4 Expand the Email section of the window.

Step 5 In the Email Options field, select Send Email.

Step 6 In the Recipient List, CC, and BCC fields, type recipients’ email addresses in comma-separated lists.

Step 7 In the Subject field, type a subject for your email.

Tip You can provide input parameters in the Subject field and the message body to dynamically generate information in the email, such as a timestamp or the name of the Defense Center. For further information, see Using Input Parameters.

Step 8 Type a cover letter in the email body as necessary. The available rich text features include a wide range of fonts, numbered and bullet lists, and so on.

Step 9 When all fields in the Generate Report window are correct, click OK and confirm.

The system distributes the generated report by email. You can configure the email’s From address under Email Notification in the system policy. For more information, see Managing System Policies.

Using Remote Storage for Reports

License: Any

You can configure the reporting system to place newly generated report files in your configured remote storage location. You can also move any locally stored report to your remote storage location.

Note You cannot move reports in remote storage back to local storage.

To use remote storage, you must first configure a remote storage location. When configured, the remote storage location appears at the bottom of the report list. The location includes current disk usage for NFS and SMB mounted storage, but not for SSH. For configuration information, see Managing Remote Storage.

To store reports remotely as they are generated:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Reports tab.

The Reports page appears.

Step 3 Select the Enable Remote Storage of Reports check box at the bottom of the page.

The Defense Center stores newly generated reports in the remote location indicated at the bottom of the page. The Location column data for these reports is Remote.

You can move your reports in local storage to a remote storage location in batch mode or singly.

To move generated reports from local to remote storage:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Reports tab.

The Reports page appears.

Step 3 Select the check boxes next to the reports you want to move, then click Move.

Tip Select the check box at the top left of the page to move all reports on the page. If you have multiple pages of reports, a second check box appears that you can select to move all reports on all pages.

Step 4 Confirm that you want to move the reports.

The reports are moved.

Managing Report Templates and Report Files

License: Any

In addition to creating and editing templates, you can perform the following template management tasks:

- Exporting and Importing Report Templates

- Deleting Report Templates

You can also perform the following management tasks for your generated report files:

- Downloading Reports

- Deleting Reports

Exporting and Importing Report Templates

License: Any

The file that you generate when you export a report template contains all necessary data to create the same report on another Defense Center. The export file, which is in a proprietary SFO format, includes:

- the report template, with all section design elements and document attributes

- all saved searches used in the report

- all images used in the report

- all custom tables used in the report

The only configuration that may be required after you import the template on another Defense Center is automatic report generation scheduling.

Note Importing and exporting report templates requires both Defense Centers to be at the same software version level.

To export a report template:

Access: Admin

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

).

The system produces a configuration package file with .sfo extension and opens an Opening Object pop-up window that displays the package’s file name.

Step 4 Select Save file and OK to save the file to your local computer.

Step 5 You can change the name of the .sfo package to a more descriptive one for your convenience. When you import the package, regardless of its name, the importing Defense Center will give the template the same name it had on the source Defense Center.

The SFO files exported from a Defense Center contain all elements necessary to add the report template to another Defense Center. The import process therefore requires only uploading the package to the second Defense Center and running the import process.

To import a report template:

Access: Admin

Step 1 Select System > Tools > Import/Export.

The Import/Export page appears, including a list of the report templates on the Defense Center.

Step 2 Click Upload Package.

The Package Name page appears.

Step 3 You have two options:

- Type the path to the package you want to upload.

- Click Browse to locate the package.

Step 4 Click Upload.

The Report Template section of the configuration list appears, showing the template to be imported.

Step 5 Select the check box next to the template and click Import.

The template appears in the list of configurations on the destination Defense Center.

Deleting Report Templates

License: Any

Report templates remain listed on the Report Templates tab for reuse until you delete them. Note that you cannot delete Cisco-provided report templates.

Note Security Analysts can delete only report templates they created.

To delete a report template:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Report Templates tab.

The Report Templates page appears.

) and confirm.

The template name disappears from the list.

Downloading Reports

License: Any

You can download any report file to your local computer. From there, you can email it or distribute it electronically by other available means. For information on distributing reports automatically by email at generation time, see Distributing Reports by Email at Generation Time.

To download reports:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Reports tab.

The Reports page appears.

Step 3 Select the check boxes next to the reports you want to download, then click Download.

Tip Select the check box at the top left of the page to download all reports on the page. If you have multiple pages of reports, a second check box appears that you can select to download all reports on all pages.

Step 4 Follow your browser’s prompts to download the reports.

If you select multiple reports, they are downloaded in a single .zip file.

Deleting Reports

License: Any

You can delete your report files at any time. The procedure completely removes the files, and no recovery is possible. Although you still have the report template that generated the report, it may be difficult to regenerate a particular report file if the time window was expanding or sliding. For information on the time window, see Editing the Sections of a Report Template. Regeneration may also be difficult if your template uses input parameters. For information on using input parameters, see Using Input Parameters.

To delete reports:

Access: Admin/Any Security Analyst

Step 1 Select Overview > Reporting.

Step 2 Select the Reports tab.

The Reports page appears.

Step 3 Select the check boxes next to the reports you want to delete, then click Delete.

Tip Select the check box at the top left of the page to delete all reports on the page. If you have multiple pages of reports, a second check box appears that you can select to delete all reports on all pages.

Step 4 Confirm the deletion.

The reports are deleted.

Understanding and Using Workflows

A workflow is a tailored series of data pages on the Defense Center web interface that analysts can use to evaluate events generated by the system. The Defense Center provides three types of workflows:

- Predefined workflows , which are preset workflows installed on the system that you cannot modify or delete.

- Saved custom workflows , which are predefined custom workflows that you can modify or delete.

- Custom workflows , which are workflows that you create and customize for your specific needs.

For example, when you analyze intrusion events, you can choose from several predefined workflows specifically created for the task.

Note that the data displayed in a workflow often depends on such factors as how you license and deploy your managed devices, whether you configure features that provide the data and, in the case of Series 2 appliances and Cisco NGIPS for Blue Coat X-Series, whether the appliance supports a feature that provides the data. For example, because neither the DC500 Defense Center nor Series 2 devices support URL filtering by category and reputation, the DC500 Defense Center does not display data for this feature and Series 2 devices do not detect this data.

See the following sections for more information about using predefined and custom workflows:

- Components of a Workflow

- Using Workflows

- Using Custom Workflows

Tip You can also use custom workflows as the basis for event reports. See Working with Reports for more information.

Components of a Workflow

License: Any

Workflows can include several types of pages, as described in the following sections.

Table Views

Table views include a column for each of the fields in the database on which your workflow is based.

For example, the table view of discovery events includes the Time, Event, IP Address, User, MAC Address, MAC Vendor, Port, Description, and Device columns.

By contrast, the table view of servers includes the Last Used, IP Address, Port, Protocol, Application Protocol, Vendor, Version, Web Application, Application Risk, Business Relevance, Hits, Source Type, Device, and Current User columns.

Drill-Down Pages

Drill-down pages contain a subset of columns that are available in the database.

For example, a drill-down page for discovery events might include only the IP Address, MAC Address, and Time columns. A drill-down page for intrusion events, on the other hand, might include the Priority, Impact Flag, Inline Result, and Message columns.

Generally, drill-down pages are intermediate pages that you use to narrow your investigation to a few events before moving to a table view page.

Graphs

Workflows based on connection data can include graph pages, also called connection graphs.

For example, a connection graph might display a line graph that shows the number of connections detected by the system over time. Generally, connection graphs are, like drill-down pages, intermediate pages that you use to narrow your investigation. For more information, see Working with Connection Graphs.

Final Pages

The final page of a workflow depends on the type of event on which the workflow is based:

– The host view is the final page for workflows based on applications, application details, discovery events, hosts, indications of compromise (IOC), servers, or any type of vulnerabilities. Viewing host profiles from this page allows you to easily view data on all IP addresses associated with hosts that have multiple addresses. For more information, see Using Host Profiles.

– The user detail view is the final page for workflows based on users and user activity. For more information, see Understanding User Details and Host History.

– The vulnerability detail view is the final page for workflows based on Cisco vulnerabilities. For more information, see Viewing Vulnerability Details.

– The packet view is the final page for workflows based on intrusion events. For more information, see Using the Packet View.

Workflows based on other kinds of events (for example, audit log events or malware events) do not have final pages.

See the following sections for more information on workflows:

- Comparing Predefined and Custom Workflows

- Comparing Workflows for Predefined and Custom Tables

- Predefined Intrusion Event Workflows

- Predefined Malware Workflows

- Predefined File Workflows

- Predefined Captured File Workflows

- Predefined Connection Data Workflows

- Predefined Security Intelligence Workflows

- Predefined Host Workflows

- Predefined Indications of Compromise Workflows

- Predefined Applications Workflows

- Predefined Application Details Workflows

- Predefined Servers Workflows

- Predefined Host Attributes Workflows

- Predefined Discovery Events Workflows

- Predefined User Workflows

- Predefined Vulnerabilities Workflows

- Predefined Third-Party Vulnerabilities Workflows

- Predefined Correlation and White List Workflows

- Predefined System Workflows

- Saved Custom Workflows

Comparing Predefined and Custom Workflows

License: Any

The FireSIGHT System is delivered with a set of predefined workflows (described in the sections that follow) that you can use to analyze the events and other data it collects.

Custom workflows are workflows that you create to meet the unique needs of your organization. When you create a custom workflow, you choose the kind of event (or database table) on which the workflow is based. On the Defense Center, you can base a custom workflow on a custom table. You can also choose the pages a custom workflow contains; custom workflows can contain drill-down, table view, and host or packet view pages.

The Defense Center is delivered with several saved custom workflows, which are based on the saved custom tables that are also delivered with the Defense Center. The differences between workflows based on predefined and custom tables is described in the next section, Comparing Workflows for Predefined and Custom Tables.

Comparing Workflows for Predefined and Custom Tables

License: FireSIGHT

You can use the custom tables feature to create tables that use the data from two or more types of events. This is useful because you can, for example, create tables and workflows that correlate intrusion event data with discovery data to allow simple searches for events that affect critical systems. See Using Custom Tables for information about creating custom tables.

Each custom table has, by default, a workflow that you can use to view the events associated with the table. The features in the workflow differ depending on which type of table you use. For example, custom table workflows based on the intrusion event table always end with the packet view. However, custom table workflows based on discovery events end with the host view.

Unlike workflows based on the predefined event tables, workflows based on custom tables do not have links to other types of workflows.

Predefined Intrusi on Event Workflows

License: Protection

The following table describes the predefined intrusion event workflows included with the FireSIGHT System. For information on accessing these workflows, see Viewing Intrusion Events and Reviewing Intrusion Events.

:

Table 58-1 Predefined Intrusion Event Workflows

Workflow Name

Description

Destination Port

Because destination ports are usually tied to an application, this workflow can help you detect applications that are experiencing an uncommonly high volume of alerts. The Destination Port column can also help you identify applications that should not be present on your network.

This workflow begins with a page showing the destination ports associated with the intrusion events, followed by a page showing the event types that were generated. You can then see a tabular view of event information, called the table view of events, followed by a packet view that shows the decoded contents of the packets associated with each event.

Event-Specific

This workflow provides two useful features. Events that occur frequently may indicate:

- false positives

- a worm

- a badly misconfigured network

Events that occur infrequently are most likely evidence of a targeted attack and warrant special attention.

This workflow begins with a page showing the event types that were generated. You can then view a page with two tables, one listing the source IP addresses associated with the events, the other showing the destination IP addresses associated with the events. The last pages in the workflow are the table view of events and the packet view.

Events by Priority and Classification

This workflow lists events and their type in order of event priority, along with a count showing how many times each event has occurred.

This workflow begins with a drill-down page that contains the priority level, classification and count of each listed event. The last pages in the workflow are the table view of events and the packet view.

Events to Destinations

This workflow provides a high-level view of which host IP addresses are being attacked and the nature of the attack; where available, you can also see information about the countries involved in attacks.

This workflow begins with a page of paired event types and destination IP addresses that you can use to investigate what types of events are directed towards specific IP addresses. The last pages in the workflow are the table view of events and the packet view.

IP-Specific

This workflow shows which host IP addresses are generating the most alerts. Hosts with the greatest number of events are either public-facing and receiving worm-type traffic (indicating a good place to look for tuning) or require further investigation to determine the cause of the alerts. Hosts with the lowest counts also warrant investigation as they could be the subject of a targeted attack. Low counts may also indicate that a host may not belong on the network.

This workflow begins with a page showing two tables, one each for the source and destination IP addresses that are associated with the events. The next page shows the event types that were generated. The last pages in the workflow are the table view of events and the packet view.

Impact and Priority

This workflow lets you find high-impact recurring events quickly. The reported impact level is shown with the number of times the event has occurred. Using this information, you can identify the high-impact events that recur most often, which might be an indicator of a widespread attack on your network.

This workflow begins with a page showing the impact level, priority, and count associated with each event. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Impact and Source

This workflow can help you identify the source of an attack in progress. The reported impact level is shown with the associated source IP address for the event. If, for example, events with a level 1 impact are coming from the same source IP address repeatedly, they may indicate an attacker who has identified vulnerable systems and is targeting them.

This workflow begins with a page showing the impact level, source IP address, priority, and count associated with each event. Within each event level, events are sorted by count, then priority. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Impact to Destination

You can use this workflow to identify events repeatedly occurring on vulnerable computers, so you can address the vulnerabilities on those systems and stop any attacks in progress.

This workflow begins with a page showing the impact level, inline result (whether the packet was or would have been dropped), destination IP address, priority, and count associated with each event. Within each event level, events are sorted by count, then priority. Next, a drill-down page appears with the source and destination IP addresses for each event. Events on the second page are sorted by count. The last pages in the workflow are the table view of events and the packet view.

Source Port

This workflow indicates which servers are generating the most alerts. You can use this information to identify areas that require tuning, and to decide which servers require attention.

This workflow begins with a page showing the source ports associated with the intrusion events, followed by a page showing the types of events that were generated. The last pages in the workflow are the table view of events and the packet view.

Source and Destination

This workflow identifies host IP addresses sharing high levels of alerts. Pairs at the top of the list could be false positives, and may identify areas that require tuning. You can check pairs at the bottom of the list for targeted attacks, for users accessing resources they should not be accessing, or for hosts that do not belong on the network.

This workflow begins with a page showing the source and destination IP addresses for each event, followed by a page showing the types of events that were generated. The last pages in the workflow are the table view of events and the packet view.

Predefined Malware Workflows

License: Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The following table describes the predefined malware workflows included on the Defense Center. All predefined malware workflows use the table view of malware events.

Note that because the DC500 Series 2 Defense Center, Series 2 devices, and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, the DC500 Defense Center does not display data for this feature and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect this data.

For information on accessing malware events, see Working with Malware Events.

Table 58-2 Predefined Malware Workflows

Workflow Name

Description

Malware Summary

This workflow provides a list of the malware detected in network traffic or by endpoint-based FireAMP Connectors, grouped by individual threat.

Malware Event Summary

This workflow provides a quick breakdown of the different malware event types and subtypes.

Hosts Receiving Malware

This workflow provides a list of host IP addresses that have received malware, grouped by the malware files’ associated dispositions.

Hosts Sending Malware

This workflow provides a list of host IP addresses that have sent malware, grouped by the malware files’ associated dispositions.

Applications Introducing Malware

This workflow provides a list of host IP addresses that have received files, grouped by the associated malware dispositions for those files.

Predefined File Workflows

License: Protection

Table 58-3 Predefined File Workflows

Workflow Name

Description

File Summary

This workflow provides a quick breakdown of the different file event categories and types, along with any associated malware dispositions.

Hosts Receiving Files

This workflow provides a list of host IP addresses that have received files, grouped by the associated malware dispositions for those files.

Hosts Sending Files

This workflow provides a list of host IP addresses that have sent files, grouped by the associated malware dispositions for those files.

Predefined Captured File Workflows

License: Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The following table describes the predefined captured file workflows included on the Defense Center. All predefined captured file workflows use the table view of captured files.

Note that because the DC500 Series 2 Defense Center, Series 2 devices, and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, the DC500 Defense Center does not display data for this feature and Series 2 devices and Cisco NGIPS for Blue Coat X-Series do not detect this data.

Table 58-4 Predefined Captured File Workflows

Workflow Name

Description

Captured File Summary

This workflow provides a breakdown of captured files based on type, category, and threat score.

Dynamic Analysis Status

This workflow provides a count of captured files based on whether they have been submitted for dynamic analysis.

Predefined Connection Data Workflows

License: FireSIGHT

Table 58-5 Predefined Connection Data Workflows

Workflow Name

Description

Connection Events

This workflow provides a summary view of basic connection and detected application information, which you can then use to drill down to the table view of events.

Connections by Application

This workflow contains a graph of the 10 most active applications on the monitored network segment, based on the number of detected connections.

Connections by Initiator

This workflow contains a graph of the 10 most active host IP addresses on the monitored network segment, based on the number of connections where the host initiated the connection transaction.

Connections by Port

This workflow contains a graph of the 10 most active ports on the monitored network segment, based on the number of detected connections.

Connections by Responder

This workflow contains a graph of the 10 most active host IP addresses on the monitored network segment, based on the number of connections where the host IP was the responder in the connection transaction.

Connections over Time

This workflow contains a graph of the total number of connections on the monitored network segment over time.

Traffic by Application

This workflow contains a graph of the 10 most active applications on the monitored network segment, based on the number of kilobytes transmitted.

Traffic by Initiator

This workflow contains a graph of the 10 most active host IP addresses on the monitored network segment, based on the total number of kilobytes transmitted from each address.

Traffic by Port

This workflow contains a graph of the 10 most active ports on the monitored network segment, based on the number of kilobytes transmitted.

Traffic by Responder

This workflow contains a graph of the 10 most active host IP addresses on the monitored network segment, based on the total number of kilobytes received by each address.

Traffic over Time

This workflow contains a graph of the total kilobytes transmitted on the monitored network segment over time.

Unique Initiators by Responder

This workflow contains a graph of the 10 most active responding host IP addresses on the monitored network segment, based on the number of unique initiators that contacted each address.

Unique Responders by Initiator

This workflow contains a graph of the 10 most active initiating host IP addresses on the monitored network segment, based on the number of unique responders that the addresses contacted.

Predefined Security Intelligence Workflows

License: Protection

Supported Devices: Any except Series 2

Supported Defense Centers: Any except DC500

Table 58-6 Predefined Security Intelligence Workflows

Workflow Name

Description

Security Intelligence Events

This workflow provides a summary view of basic Security Intelligence and detected application information, which you can then use to drill down to the table view of events.

Security Intelligence Summary

This workflow is identical to the Security Intelligence Events workflow, but begins with the Security Intelligence Summary page, which lists security intelligence events by category and count only.

Predefined Host Workflows

License: FireSIGHT

Table 58-7 Predefined Host Workflows

Workflow Name

Description

Hosts

This workflow contains a table view of hosts followed by the host view. Workflow views based on the Hosts table allow you to easily view data on all IP addresses associated with a host. See Viewing Hosts for more information.

Operating System Summary

You can use this workflow to analyze the operating systems in use on your network. This workflow provides a series of pages that start with a list of the operating systems and operating system vendors on your network, continuing with the number of hosts running each version of that operating system. The next page lists hosts by criticality, IP address, and NetBIOS name, with their associated operating systems and operating system vendors. The workflow finishes with a table view of hosts, followed by the host view. See Viewing Hosts for more information.

Predefined Indications of Compromise Workflows

License: FireSIGHT

Table 58-8 Predefined Indications of Compromise Workflows

Workflow Name

Description

Indications of Compromise

This workflow begins with a summary view of IOC data grouped by count and category, followed by a detail view that further subdivides the summary data by event type. Next is a full table view of IOC data. The workflow concludes with the host view. For more information on viewing and interpreting IOC data, see Working with Indications of Compromise.

Indications of Compromise by Host

You can use this workflow to gauge which hosts on your network are most likely to be compromised (based on IOC data). This workflow contains a view of host IP addresses by IOC data count, followed by a table view of IOC data and concluding with the host view. For more information on viewing and interpreting IOC data, see Working with Indications of Compromise.

Predefined Applications Workflows

License: FireSIGHT

Table 58-9 Predefined Applications Workflows

Workflow Name

Description

Application Business Relevance

You can use this workflow to analyze running applications of each estimated business relevance level on your network, so you can monitor appropriate use of your network resources. This workflow begins with a count of hosts running applications of each relevance level, followed by a table of individual applications with their business relevance levels and host counts, a table view of applications, and the host view. See Viewing Applications for more information.

Application Category

You can use this workflow to analyze running applications of each category (such as email, search engine, or social networking) on your network, so you can monitor appropriate use of your network resources. This workflow begins with a count of hosts running applications of each category, followed by a count of hosts running individual applications, a table view of applications, and the host view. See Viewing Applications for more information.

Application Risk

You can use this workflow to analyze running applications of each estimated security risk level on your network, so you can estimate the potential risk of users’ activity and take appropriate action. This workflow begins with a count of hosts running applications of each risk level, followed by a table of individual applications with their business relevance levels and host counts, a table view of applications, and the host view. See Viewing Applications for more information.

Application Summary

You can use this workflow to obtain detailed information about the applications and associated hosts on your network, so you can closely examine host application activity. This workflow begins with a list of individual host IP addresses running applications, followed by a table view of applications and the host view.

Applications

You can use this workflow to analyze running applications on your network, so you can gain an overview of how the network is being used. This workflow begins with a count of hosts running individual applications, followed by a table view of applications and the host view. See Viewing Applications for more information.

Predefined Application Details Workflows

License: FireSIGHT

Table 58-10 Predefined Application Details Workflows

Workflow Name

Description

Application Details

You can use this workflow to analyze the client applications on your network in more detail. This workflow contains a series of pages that begin with a list of the client applications and application products on your network and a count of the number of hosts running each application. You can then view the number of hosts running each version of that application. The next page lets you identify which applications have been accessed most frequently on specific hosts. The workflow then provides a table view of client applications, followed by the host view. See Viewing Application Details for more information.

Clients

This workflow contains a table view of client applications, followed by the host view. See Viewing Application Details for more information.

Predefined Servers Workflows

License: FireSIGHT

Table 58-11 Predefined Servers Workflows

Workflow Name

Description

Network Applications by Count

You can use this workflow to analyze the most frequently used applications on your network. This workflow contains a series of pages that show applications with a count of hosts where each application occurs, then add the vendor and version of each application. The workflow then concludes with a table view listing the applications per host, followed by the host view. See Viewing Servers for more information.

Network Applications by Hit

You can use this workflow to analyze the most active applications on your network. This workflow contains a series of pages that show applications with a count of how often each application is accessed, then add the vendor and version information for each application. The workflow finishes with a page containing a table view listing the applications per host, followed by the host view. See Viewing Servers for more information.

Server Details

You can use this workflow to analyze the vendors and versions of detected server application protocols in detail. The workflow contains a list of servers associated with their vendors, then a list of servers correlated with both vendor and version, finishing with a table view of servers and the host view.

Servers

This workflow contains a table view of applications followed by the host view. See Viewing Servers for more information.

Predefined Host Attributes Workflows

License: FireSIGHT

Table 58-12 Predefined Host Attributes Workflows

Workflow Name

Description

Attributes

You can use this workflow to monitor IP addresses of hosts on your network and the hosts’ status. This workflow begins with a table view of host attributes that lists individual IP addresses with current user, host criticality, notes, and white list compliance. It finishes with the host view. For more information, see Viewing Host Attributes.

Predefined Discovery Events Workflows

License: FireSIGHT

Table 58-13 Predefined Discovery Event Workflows

Workflow Name

Description

Discovery Events

This workflow provides a detailed list, in table view form, of discovery events, followed by the host view. For more information, see Understanding the Discovery Events Table.

Predefined User Workflows

License: FireSIGHT

Table 58-14 Predefined User Workflows

Workflow Name

Description

Users

This workflow provides a list of user information collected from user events or from the LDAP server connection. For details about the user identity workflow, see Viewing Users.

Predefined Vulnerabilities Workflows

License: FireSIGHT

Table 58-15 Predefined Vulnerabilities Workflows

Workflow Name

Description

Vulnerabilities

You can use this workflow to review s a table view of vulnerabilities showing all the vulnerabilities in the database, followed by a table view of only those active vulnerabilities that apply to the detected hosts on your network.The workflow ends in a vulnerability detail view, which contains a detailed description for every vulnerability that meets your constraints. For more information, see Viewing Vulnerabilities.

Predefined Third-Party Vulnerabilities Workflows

License: FireSIGHT

Table 58-16 Predefined Third-Party Vulnerabilities Workflows

Workflow Name

Description

Vulnerabilities by IP Address

You can use this workflow to see quickly how many third-party vulnerabilities you have detected per host IP address on your monitored network. The workflow concludes with a table view of third-party vulnerabilities, followed by the host view. For more information, see Viewing Third-Party Vulnerabilities.

Vulnerabilities by Source

You can use this workflow to see quickly how many third-party vulnerabilities you have detected per third-party vulnerability source, such as the QualysGuard Scanner. This workflow provides some details about those vulnerabilities on an intermediate drill-down page, then concludes with a table view of third-party vulnerabilities and the host view. For more information, see Viewing Third-Party Vulnerabilities.

Predefined Correlation and White List Workflows

License: FireSIGHT

Table 58-17 Predefined Correlation Workflows

Workflow Name

Description

Correlation Events

This workflow contains a table view of correlation events. See Working with Correlation Events for more information.

White List Events

This workflow contains a table view of white list events. See Working with White List Events for more information.

Host Violation Count

This workflow provides a series of pages that list all the host IP addresses that violate at least one white list. The first page sorts the addresses based on the number of violations per address, with the IP addresses with the most number of violations at the top of the list. If a host IP address violates more than one white list, there is a separate row for each violated white list. The workflow also contains a table view of white list violations that lists all violations, with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation. See Working with White List Violations for more information.

White List Violations

This workflow includes a table view of white list violations that lists all violations with the most recently detected violation at the top of the list. Each row in the table contains a single detected violation. See Working with White List Violations for more information.

Status

This workflow contains a table view of remediation status, which includes the name of the policy that was violated and the name and status of the remediation that was applied. See Working with Remediation Status Events for more information.

Predefined System Workflows

License: Any

Table 58-18 Additional Predefined Workflows

Workflow Name

Description

Audit Log

This workflow contains a table view of the audit log that lists audit events. See Viewing Audit Records for more information.

Health Events

This workflow displays events triggered by the health monitoring policy. See Working with the Health Events Table View for more information.

Rule Update Import Log

This workflow contains a table view listing information about both successful and failed rule update imports. For more information, see Importing Rule Updates and Local Rule Files.

Scan Results

This workflow contains a table view listing each completed scan. For more information, see Working with Active Scan Results.

Saved Custom Workflows

License: Protection + FireSIGHT

Table 58-19 Saved Custom Workflows

Workflow Name

Description

Events by Impact, Priority, and Host Criticality

You can use this workflow to quickly pick out and focus in on hosts that are important to your network, currently vulnerable, and possibly currently under attack.

By default, this workflow starts with a summary of events sorted by impact level, then by host criticality, and then by the number of occurrences of the event. You can use the second page of the workflow to drill down and view the source and destination addresses where specific events occur. The workflow concludes with a table view of Intrusion Events with Destination Criticality, then the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables.

Events by Priority and Classification

This workflow lists events and their type in order of event priority, along with a count showing how many times each event has occurred.

This workflow begins with a drill-down page that contains the priority level, classification and count of each listed event. The last pages in the workflow are the table view of events and the packet view. This workflow is based on the Intrusion Events custom table. For more information, see Understanding Custom Tables.

Events with Destination, Impact, and Host Criticality

You can use this workflow to find the most recent attacks on hosts that are important to your network and currently vulnerable.

By default, this workflow starts with a list of the most recent events, sorted by impact level. The next page of the workflow provides a table view of Intrusion Events with Destination Criticality, followed by the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables.

Hosts with Servers Default Workflow

You can use this workflow to quickly view the basic information in the Hosts with Servers custom table.

By default, this workflow begins with a table view of hosts with servers, followed by the host view. This workflow is based on the Hosts with Servers custom table. For more information, see Understanding Custom Tables.

Intrusion Events with Destination Criticality Default Workflow

You can use this workflow to quickly view the basic information in the Intrusion Events with Destination Criticality custom table.

By default, this workflow starts with a table view of Intrusion Events with Destination Criticality, followed by the packet view. This workflow is based on the Intrusion Events with Destination Criticality custom table. For more information, see Understanding Custom Tables.

Intrusion Events with Source Criticality Default Workflow

You can use this workflow to quickly view the basic information in the Intrusion Events with Source Criticality custom table.

By default, this workflow starts with a table view of Intrusion Events with Source Criticality, followed by the packet view. This workflow is based on the Intrusion Events with Source Criticality custom table. For more information, see Understanding Custom Tables.

Server and Host Details

You can use this workflow to determine what servers are most frequently used on your network and which hosts are running those servers.

By default, this workflow begins with a summary of servers with the frequency of access for each service. The next page lists servers by operating system vendor and version. The workflow concludes with a table view of hosts with servers, followed by the host view. This workflow is based on the Hosts with Servers custom table. For more information, see Understanding Custom Tables.

Using Workflows

License: Any

The drill-down and table view pages in workflows allow you to quickly narrow your view of the data so you can zero in on events that are significant to your analysis. Although the data in each type of workflow is different, all workflows share a common set of features. The following sections describe these features and explain how to use them:

- Selecting Workflows describes the workflow selection page and how to select a workflow to use.

- Understanding the Workflow Toolbar describes the toolbar options available in workflows.

- Using Workflow Pages describes the features that appear on all workflow pages and explains how to use them.

- Setting Event Time Constraints describes how to set the time range for event-based workflows. The workflow includes events generated in the specified time range.

- Constraining Events describes features that are used in workflows to constrain, or narrow, the view of data in workflows and to advance through workflow pages.

- Using Compound Constraints explains how compound constraints can be used and provides examples.

- Sorting Drill-Down Workflow Pages describes features for sorting the data displayed in workflows, and for removing and restoring table columns to view.

- Selecting Rows on a Workflow Page describes how to select data rows in the displayed table that you want to analyze or on which you want to perform some other action.

- Navigating to Other Pages in the Workflow describes how to open other workflows using the constraints, including any selected events, from the current workflow.

- Navigating Between Workflows describes the Jump to drop-down list and explains how you can use it to apply the current constraints to a different workflow.

- Searching for Events provides information about the feature used to search event data.

- Using Bookmarks describes how to create, manage, and use bookmarks.

Selecting Workflows

License: Any

The FireSIGHT System provides predefined workflows for the types of data listed in the following table.

Table 58-20 Features Using Workflows

Feature

Menu Path

Option

Intrusion events

Analysis > Intrusions

Events

Reviewed Events

Clipboard

Incidents

Malware events

Analysis > Files

Malware Events

File events

Analysis > Files

File Events

Captured files

Analysis > Files

Captured Files

Connection events

Analysis > Connections

Events

Security Intelligence events

Analysis > Connections

Security Intelligence Events

Host events

Analysis > Hosts

Network Map

Hosts

Indications of Compromise

Applications

Application Details

Servers

Host Attributes

Discovery Events

User events

Analysis > Users

User Activity

Users

Vulnerability events

Analysis > Vulnerabilities

Vulnerabilities

Third-Party Vulnerabilities

Correlation events

Analysis > Correlation

Correlation Events

White List Events

White List Violations

Status

Audit events

System > Monitoring

Audit

Health events

Health > Health Events

n/a

Rule Update Import Log

System > Updates

n/a

Scan Results

Policies > Actions > Scanners

n/a

When you view any of the kinds of data described in the above table, events appear on the first page of the default workflow for that data.

Also note that workflow access depends on your user role (see Configuring User Roles), as follows:

- Administrator users can access any workflow, and are the only users who can access the audit log, scan results, and the rule update import log.

- Maintenance Users can access health events.

- Security Analyst and Security Analyst (Read Only) users can access intrusion, malware, file, connection, discovery, vulnerability, correlation, and health workflows.

To view the data using a workflow other than the default:

Access: Admin/Any Security Analyst

Step 1 Select the appropriate menu path and option as described in the Features Using Workflows table.

The first page of the default workflow for that data type appears. For information on specifying a different default workflow, see Configuring Event View Settings.

Step 2 Optionally, use a different workflow. Click (switch workflow) next to the workflow title, then select the workflow you want to use.

Step 3 The first page of your selected workflow appears.

Understanding the Workflow Toolbar

License: Any

Each page in a workflow includes a toolbar that offers quick access to related features. The following table describes each of the links on the toolbar.

Table 58-21 Workflow Toolbar Links

Feature

Description

Bookmark This Page

Bookmarks the current page so you can return to it later. Bookmarking captures the constraints in effect on the page you are viewing so you can return to the same data (assuming the data still exists) at a later time. See Using Bookmarks for information about creating bookmarks.

Report Designer

Opens the report designer with the currently constrained workflow as the selection criteria. See Creating a Report Template from an Event View for information about creating reports.

Dashboard

Opens a dashboard relevant to your current workflow. For example, Connection Events workflows link to the Connection Summary dashboard. See Using Dashboards for information about using dashboards.

View Bookmarks

Displays a list of saved bookmarks from which you can select. See Using Bookmarks for information about creating and managing bookmarks.

Search

Displays a Search page where you can perform advanced searches on data in the workflow. You can also click the down arrow icon to select and use a saved search. See Searching for Events for information about searching workflows.

Using Workflow Pages

License: Any

The actions you can perform on a workflow page depend on the type of page. Table view pages and drill-down pages contain many features you can use to constrain the set of events you want to view or to navigate the workflow. For more information on the features available on each type of page, see the following sections:

- Using Common Table View or Drill-Down Page Functionality

- Using Geolocation

- Using Table View Pages

- Using Drill-Down Pages

- Using the Host View, Packet View, or Vulnerability Detail Pages

Using Common Table View or Drill-Down Page Functionality

License: Any

Table view and drill-down workflow pages provide a set of icons and other features in the table header and table rows that you can use to perform actions on the displayed data.

The features are described in the following table.

To remove a single constraint, click it. To remove a compound constraint, click Compound Constraints.

Click Edit Search or Save Search to open a search page pre-populated with the current single constraints. See Constraining Events for more information.

Table 58-22 Table View and Drill-Down Page Features

Feature

Description

Click the blue down-arrow icon to display the corresponding row in the next page of the workflow.

(clean) (malware) (custom detection) (unknown) (unavailable)

Click the network file trajectory icon, which appears in file name and SHA-256 hash value columns, to view the file’s trajectory map in a new window. For more information, see Analyzing Network File Trajectory.

Note that because the DC500 Defense Center, Series 2 devices, and Cisco NGIPS for Blue Coat X-Series do not support advanced malware protection, you cannot view network file trajectory for network-based malware and file events on these appliances.

(potentially compromised) (blacklisted) (blacklisted, set to monitor)

Click the host profile icon, which appears in IP address columns, to display the host profile associated with that IP address in a pop-up window. For more information, see Using Host Profiles.

Hosts that have been tagged as potentially compromised by triggered indications of compromise (IOC) rules appear with the compromised host icon instead of the usual icon. For more information on IOC, see Understanding Indications of Compromise.

If the host profile icon is grayed out, you cannot view the host profile because that host cannot be in the network map (for example, 0.0.0.0).

If you are performing traffic filtering based on Security Intelligence data, host icons next to blacklisted and monitored IP addresses in the connection event view look slightly different. This helps you identify which host in a connection was blacklisted. Note that neither the DC500 Defense Center nor Series 2 devices support Security Intelligence data.

(Low threat score) (Medium threat score) (High threat score) (Very High threat score)

Click the threat score icon, which appears in threat score columns, to view the Dynamic Analysis Summary report for the highest threat score associated with a file.

Note that because the DC500 Defense Center, Series 2 devices, and Cisco NGIPS for Blue Coat X-Series support advanced malware protection, you cannot view the Dynamic Analysis Summary report on these appliances.

Click the user icon, which appears in user identity columns, to view user profile information. For more information, see Understanding User Details and Host History.

If the user icon is grayed out, you cannot view the user profile because that user cannot be in the database (FireAMP Connector user).

Click the vulnerability icon, which appears in third-party vulnerability ID columns, to view vulnerability details for third-party vulnerabilities. For more information, see Viewing Vulnerability Details.

Check boxes

Select the check boxes by two or more rows on a page to indicate which rows you want to affect, then click one of the buttons at the bottom of the page (for example, the View button). You can also select the check box at the top of the row to select all the rows on the page.

Country flags and codes

In some workflow pages, such as those for connection events, intrusion events, file events, and malware events, routable IP addresses include information about the associated country. When this geolocation information is available, the country’s flag and ISO code appear in the appropriate column (such as Source Country). Hover your pointer over the flag to view the country name. When viewing individual (rather than aggregated) data points, you can click the flag icon to view further geolocation details. See Using Geolocation for more information.

Note that the DC500 Defense Center does not support geolocation data.

Search Constraints

) to hide the list from view. By default, this list is collapsed, which is useful when the list of constraints is long and takes up too much of the screen. Note Compound constraints are constraints created based on rows with multiple non-count values. You cannot perform a search or save a search on a compound constraint.

Time Range

The date range located in the upper right corner of the page sets a time range for events to include in the workflow. See Setting Event Time Constraints for more information.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

Workflow Page Links

Workflow page links appear in the upper left corner of predefined workflow table view and drill-down pages, above events and below the workflow name. Click a workflow page link to display that page using any active constraints.

Workflow Name

The name of the workflow appears at the top of the page. Beside it, when applicable, is the (switch workflows) link, which you can use to select other workflows of the same type.

Using Geolocation

License: FireSIGHT

Supported Devices: feature dependent

Supported Defense Centers: Any except DC500

While monitoring your network, the geolocation feature provides you with additional data about the geographical sources of routable IP addresses (country, continent, and so on). You can use this data to determine if, for example, connections are originating from or terminating in countries unconnected with your organization.

Geolocation information is available for intrusion events, connection events, file events, malware events, host profiles, and user profiles. Geolocation information is also available in the Context Explorer and the dashboard.

You can use geolocation data (source and destination country/continent) as conditions for access control rules, as well as create custom geolocation objects for this purpose. You can also use source/destination country data as conditions for correlation rules and traffic profiles. For more information, see Working with Geolocation Objects, Controlling Traffic by Network or Geographical Location, Creating Rules for Correlation Policies, and Specifying Traffic Profile Conditions.

By installing geolocation database (GeoDB) updates, you can view a Geolocation Details page with granular information available for an IP address, such as postal code, coordinates, time zone, Autonomous System Number (ASN), Internet service provider (ISP), use type (home or business), organization, domain name, connection type, and proxy information. You can also pinpoint the detected location with any of four third-party map tools. Without a GeoDB update, only the flag icon and country name appear; you cannot view the Geolocation Details page. For information on installing and updating the GeoDB, see Updating the Geolocation Database. You can view the current version of your GeoDB update by clicking Help > About.

Table 58-23 Geolocation Detail Fields

Field

Contents

Country

Country associated with the host’s IP address, accompanied by the country’s flag. The continent is listed in parentheses. Examples: United States (North America), Equatorial Guinea (Africa)

Region

State, province, or other subregion of the country where the host is located. Examples: VA, 35

City

City where the host is located. Examples: Seattle, Fukuoka

Postal Code

Postal code of the region where the host is located. Examples: 361000, 90210

Latitude/Longitude

Exact coordinates of the host’s location. Examples: 40.0375, -76.1053; 53.4050, -0.5484

Maps

Links to external mapping sites (Google Maps, Yahoo Maps, Bing Maps, and OpenStreetMap). Click any link to view a contextual map of the host’s approximate location.

Timezone

Time zone of the host’s location, with Daylight Savings Time noted where applicable. Examples: GMT+8:00, GMT-4:00 (In DST)

ASN

Autonomous System Number (ASN) associated with the host’s IP address, and any additional information about that ASN. Examples: 14618 (Amazon.com Inc.); 4837 (Cncgroup China169 Backbone)

ISP

Internet service provider (ISP) associated with the host’s IP address. Examples: Atlantic Broadband; China Unicom Ip Network

Home/Business

Whether the host’s connection is used for Home or Business purposes.

Organization

Organization associated with the host’s IP address. Examples: Amazon.com, Bank of America

Domain Name

Domain name associated with the host’s IP address. Examples: amazonaws.com, xmcnc.net

Connection Type

Connection type associated with the host’s IP address. Examples: Broadband, DSL

Proxy Type

The type of proxy used. Examples: Anonymous, Corporate

To view geolocation details:

Access: Any

Step 1 In an event view, host profile, or other geolocation-supporting page, click the small country flag icon or ISO country code that appears by an individual data point. (You cannot view geolocation details for aggregate geolocation information, such as on the Connection Summary dashboard, despite the presence of flag icons.)

Tip In event views, hover your pointer over the flag icon to view a tooltip with the country’s name.

The Geolocation Details page appears in a new window.

Using Table View Pages

License: Any

Table views include a column for each of the fields in the database if the column is enabled by default. Note that when you disable a column on a table view, the FireSIGHT System adds the Count column to the event view if disabling the column would create two or more identical rows. When you click on a value in a table view page, you constrain by that value. When you create a custom workflow, you add a table view to it by clicking Add Table View.

Table 58-24 Additional Table View Page Features

Feature

Description

Click this icon in the column heading that you want to hide. In the pop-up window that appears, click Apply.
.

Disabled Columns list

When you remove columns from a page, or columns are disabled by default, the column names appear in the Disabled Columns list, which is located above the table and hidden by default.
) to expand the search constraints, then click the column name under Disabled Columns.
See Sorting Drill-Down Workflow Pages for more information.

Using Drill-Down Pages

License: Any

Drill-down pages contain a subset of columns that are available in the database. Note that drill-down pages for predefined workflows always have a Count column. Drill-down pages allow you to narrow the scope of events you are viewing and to move forward in the workflow. If you click on a value in a drill-down page, for example, you constrain by that value and move to the next page in the workflow, focusing more closely on events that match your selected values. Clicking a value in a drill-down page does not disable the column where the value is, even if the page you advance to is a table view. When you create a custom workflow, you add a drill-down page to it by clicking Add Page.

For more information on using features on drill-down pages to constrain the set of events as you go through a workflow, see Using Common Table View or Drill-Down Page Functionality.

Using the Host View, Packet View, or Vulnerability Detail Pages

License: Any

The final page in a discovery event, host, host attributes, indications of compromise, servers, client applications, or connection data workflow is the host view. The final page in a vulnerability workflow is the vulnerability detail page. An intrusion event workflow always ends with the packet view. On the final page of a workflow, you can expand detail sections to view specific information about each object in the set you focused on over the course of the workflow. Although the web interface does not list the constraints on the final page of a workflow, previously set constraints are retained and applied to the set of data.

Setting Event Time Constraints

License: Any

Each event has a time stamp that indicates when the event occurred. You can constrain the information that appears in some workflows by setting the time window, sometimes called the time range.

By default, workflows on Cisco appliances use an expanding time window set to the past hour. For example, if you log in at 11:30 AM, you will see events that occurred between 10:30 AM and 11:30 AM. As time moves forward, the time window expands. At 12:30 PM, you will see events that occurred between 10:30 AM and 12:30 PM.

You can change this behavior by setting your own default time window, which governs three properties:

- time window type (static, expanding, or sliding)

- time window length

- the number of time windows (either multiple time windows or a single global time window)

For general information on the default time window, see Default Time Windows.

Regardless of the default time window setting, you can manually change the time window during your event analysis by clicking the time range at the top of the page, which displays the Date/Time pop-up window. Depending on the number of time windows you configured and the type of appliance you are using, you can also use the Date/Time window to change the default time window for the type of event you are viewing.

Finally, you can pause the time window, which allows you to examine the data provided by the workflow without the time window changing and removing or adding events that you are not interested in. Note that to avoid displaying the same events on different workflow pages, the time window automatically pauses when you click a link at the bottom of the page to display another page of events; you can unpause the time window when you are ready.

For more information, see the following sections:

- Changing the Time Window

- Changing the Default Time Window for Your Event Type

- Pausing the Time Window

Changing the Time Window

License: Any

Regardless of the default time window, you can manually change the time window during your event analysis.

Note Manual time window settings are valid for only the current session. When you log out and then log back in, time windows are reset to the default.

Depending on the number of time windows you configured, changing the time window for one workflow may affect other workflows on the appliance. For example, if you have a single, global time window, changing the time window for one workflow changes it for all other workflows on the appliance. On the other hand, if you are using multiple time windows, changing the audit log or health event workflow time windows has no effect on any other time window, while changing the time window for other kinds of events affects all events that can be constrained by time (with the exception of audit events and health events).

Note that because not all workflows can be constrained by time, time window settings have no effect on workflows based on hosts, host attributes, applications, application details, vulnerabilities, users, or white list violations.

Use the Time Window tab on the Date/Time window to manually configure a time window. Depending on the number of time windows you configured in your default time window settings, the tab’s title is one of the following:

- Events Time Window , if you configured multiple time windows and are setting the time window for a workflow other than the audit log or health events workflow

- Health Monitoring Time Window , if you configured multiple time windows and are setting the time window for the health events workflow

- Audit Log Time Window , if you configured multiple time windows and are setting the time window for the audit log

- Global Time Window , if you configured a single time window

The first decision you must make when configuring a time window is the type of time window you want to use:

- A static time window displays all the events generated from a specific start time to a specific end time.

- An expanding time window displays all the events generated from a specific start time to the present; as time moves forward, the time window expands and new events are added to the event view.

- A sliding time window displays all the events generated from a specific start time (for example, one week ago) to the present; as time moves forward, the time window “slides” so that you see only the events for the range you configured (in this example, for the last week).

Note The FireSIGHT System uses a 24-hour clock based on the time you specified in your time zone preferences. See Setting Your Default Time Zone for information about configuring a time zone.

Table 58-25 Time Window Settings

Setting

Time Window Type

Description

time window type drop-down list

n/a

Select the type of time window you want to use: static, expanding, or sliding.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

Start Time calendar

static and expanding

Specify a start date and time for your time window. The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM on January 19, 2038 (UTC).

Tip Instead of using the calendar, you can use the Presets options, described below.

End Time calendar

static

Specify an end date and time for your time window. The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM on January 19, 2038 (UTC).

Note that If you are using an expanding time window, the End Time calendar is grayed out and specifies that the end time is “Now.”

Tip Instead of using the calendar, you can use the Presets options, described below.

Show the Last field and drop-down list

sliding

Configure the length of the sliding time window.

Presets: Last

all

Click one of the time ranges in the list to change the time window, based on the local time of the appliance. For example, clicking 1 week changes the time window to reflect the last week. Clicking a preset changes the calendars to reflect the preset you choose.

Presets: Current

static and expanding

Click one of the time ranges in the list to change the time window, based on the local time and date of the appliance. Clicking a preset changes the calendars to reflect the preset you choose.

Note that:

- the current day begins at midnight

- the current week begins at midnight Sunday

- the current month begins at midnight on the first of the month

Presets: Synchronize with

all (not available if you are using a global time window)

Click one of:

- Events Time Window to synchronize the current time window with the events time window

- Health Monitoring Time Window to synchronize the current time window with the health monitoring time window

- Audit Log Time Window to synchronize the current time window with the audit log time window

To change the time window during event analysis:

Access: Admin/Maint/Any Security Analyst

).

The Date/Time window appears.

Step 2 On the Time Window tab, set the time window as described in the Time Window Settings table.

Tip Click Reset to change the time window back to the default settings.

Step 3 Click Apply.

The window closes and the event view page displays events from the new time range.

Changing the Default Time Window for Your Event Type

License: Any

During your event analysis, you can use the Preferences tab on the Date/Time window to change the default time window for the type of event you are viewing without having to use the event view settings (see Default Time Windows).

Keep in mind that changing the default time window in this way changes the default time window for only the type of event you are viewing. For example, if you configured multiple time windows, changing the default time window on the Preferences tab changes the settings for either the events, health monitoring, or audit log window, in other words, whichever time window is indicated by the first tab. If you configured a single time window, changing the default time window on the Preferences tab changes the default time window for all types of events.

The following graphic shows the Defense Center version of the Preferences tab, on an appliance that has multiple time windows configured.

Table 58-26 Time Window Preferences

Preference

Description

Refresh Interval

Sets the refresh interval for event views, in minutes. Entering zero disables the refresh option.

Number of Time Windows

Specify how many time windows you want to use:

- Select Multiple to configure separate default time windows for the audit log, for health events, and for workflows based on events that can be constrained by time.

- Select Single to use a global time window that applies to all events,

Default Time Window: Show the Last - Sliding

This setting allows you to configure a sliding default time window of the length you specify.

The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to the present. As you change event views, the time window “slides” so that you always see events from the last hour.

Default Time Window: Show the Last - Static/Expanding

This setting allows you to configure either a static or expanding default time window of the length you specify.

For static time windows (enable the Use End Time check box), the appliance displays all the events generated from a specific start time (for example, 1 hour ago), to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows (disable the Use End Time check box), the appliance displays all the events generated from a specific start time (for example, 1 hour ago), to the present. As you change event views, the time window expands to the present time.

Default Time Window: Current Day - Static/Expanding

This setting allows you to configure either a static or expanding default time window for the current day. The current day begins at midnight, based on the time zone setting for your current session.

For static time windows (enable the Use End Time check box), the appliance displays all the events generated from midnight to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows (disable the Use End Time check box), the appliance displays all the events generated from midnight to the present. As you change event views, the time window expands to the present time. Note that if your analysis continues for over 24 hours before you log out, this time window can be more than 24 hours.

Default Time Window: Current Week - Static/Expanding

This setting allows you to configure either a static or expanding default time window for the current week. The current week begins at midnight on the previous Sunday, based on the time zone setting for your current session.

For static time windows (enable the Use End Time check box), the appliance displays all the events generated from midnight to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows (disable the Use End Time check box), the appliance displays all the events generated from midnight Sunday to the present. As you change event views, the time window expands to the present time. Note that if your analysis continues for over 1 week before you log out, this time window can be more than 1 week.

To change time window preferences during event analysis:

Access: Admin/Maint/Any Security Analyst

).

The Date/Time window appears.

Step 2 Select the Preferences tab and change your preferences, as described in the Time Window Preferences table.

Step 3 Click Save Preferences.

Your preferences are saved.

Step 4 You have two options:

- To apply your new default time window settings to the event view you are using, click Apply to close the Date/Time window and refresh the event view.

- To continue with your analysis without applying the default time window settings, close the Date/Time window without clicking Apply .

Pausing the Time Window

License: Any

You can pause the time window, which allows you to examine a snapshot of the data provided by the workflow. This is useful because when an unpaused workflow updates, it may remove events that you want to examine or add events that you are not interested in.

Note that you cannot pause a static time window. In addition, pausing an event time window has no effect on dashboards, nor does pausing a dashboard have any effect on pausing an event time window.

When you are finished with your analysis, you can unpause the time window. Unpausing the time window updates it according to your preferences, and also updates the event view to reflect the unpaused time window.

If the database contains more events than can be displayed on a single workflow page, you can click the links at the bottom of the page to display more events (see Navigating to Other Pages in the Workflow). When you do this, the time window automatically pauses so that you do not see the same events twice. You can unpause the time window when you are ready.

To pause the time window:

Access: Admin/Maint/Any Security Analyst

).

The time window is paused until you unpause it.

To unpause the time window:

Access: Admin/Maint/Any Security Analyst

).

The time window is unpaused and updates according to your preferences. The event view updates to reflect the current time window.

Constraining Events

License: Any

The information that you see on a workflow page is determined by the constraints that you impose. For example, when you initially open an event workflow, the information is constrained to events that were generated in the previous hour.

To advance to the next page in the workflow and constrain the data you are viewing by specific values, select the rows with those values on the page and click View. To advance to the next page in the workflow retaining the current constraints and carrying forward all events, select View All.

Note If you select a row with multiple non-count values and click View, you create a compound constraint. For more information on compound constraints, see Using Compound Constraints.

There is a third method for constraining data in a workflow. To constrain the page to the rows with values that you selected and also add the selected value to the list of constraints at the top of the page, click a value within a row on the page.

For example, if you click 10.10.60.119 in the Initiator IP column on a page with the following events:

You can also use searches to constrain the information in a workflow. The search criteria you enter on the search page are listed as the constraints at the top of the page, with the resulting events constrained accordingly. On the Defense Center, the current constraints are also applied when navigating to other workflows, unless they are compound constraints (see Navigating Between Workflows).

When searching, you must pay careful attention to whether your search constraints apply to the table you are searching. For example, client data is not available in connection summaries. If you search for connection events based on the detected client in the connection and then view the results in a connection summary event view, the Defense Center displays connection data as if you had not constrained it at all. Invalid constraints are labeled as not applicable (N/A) and are marked with a strikethrough.

Table 58-27 Search Constraint Functions

To...

Click...

constrain the view to events that match a single value

the value in the table.

For example, if you are viewing a list of logged connections and want to constrain the list to only those you allowed using access control, click Allow in the Action column. As another example, if you are viewing intrusion events and want to constrain the list to only events where the destination port is 80, click 80 (http)/tcp in the DST Port/ICMP Code column.

constrain the view to events that match multiple values

the check box for events with those values and click View.

Note that a compound constraint is added if the row contains multiple non-count values. For more information on compound constraints, see Using Compound Constraints.

remove a constraint

the name of the constraint in the Search Constraints box.

edit constraints using the search page

Edit Search in the Search Constraints box.

Use this feature when you want to constrain against multiple values in a single column. For example, if you want to view the events related to two IP addresses, click Edit Search, then modify the appropriate IP address field on the Search page to include both addresses, and then click Search.

save constraints as a saved search

Save Search in the Search Constraints box and give the query a name.

Note that you cannot save queries containing compound constraints. For more information on compound constraints, see Using Compound Constraints.

use the same constraints with another event view

Jump to and select the event view. See Navigating Between Workflows for more information.

Note that you do not retain compound constraints when you switch to another workflow. For more information on compound constraints, see Using Compound Constraints.

toggle the display of constraints

). This is useful when the list of constraints is large and takes up most of the screen.

Using Compound Constraints

License: Any

Compound constraints are based on all non-count values for a specific event. When you select a row with multiple non-count values, you set a compound constraint that only retrieves events matching all the non-count values in that row on that page. For example, if you select a row that has a source IP address of 10.10.31.17 and a destination IP address of 10.10.31.15 and a row that has a source IP address of 172.10.10.17 and a destination IP address of 172.10.10.15, you retrieve all of the following:

- Events that have a source IP address of 10.10.31.17 AND a destination IP address of 10.10.31.15

OR

- Events that have a source IP address of 172.10.31.17 AND a destination IP address of 172.10.31.15

When you combine compound constraints with simple constraints, the simple constraints are distributed across each set of compound constraints. If, for example, you added a simple constraint for a protocol value of tcp to the compound constraints listed above, you retrieve all of the following:

- Events that have a source IP address of 10.10.31.17 AND a destination IP address of 10.10.31.15 AND a protocol of tcp

OR

- Events that have a source IP address of 172.10.31.17 AND a destination IP address of 172.10.31.15 AND a protocol of tcp

You cannot perform a search or save a search on a compound constraint. You also cannot retain compound constraints when you use the event view links or click (switch workflow) to switch to another workflow. If you bookmark an event view with compound constraints applied, the constraints are not saved with the bookmark.

To clear all compound constraints, click Compound Constraints.

Sorting Table View Pages and Changing Their Layout

License: Any

When viewing data in a workflow, you can sort the data based on any available column and remove and restore columns to view. You can sort data in ascending or descending order by column.

Tip If you create a custom workflow, you can fully customize the arrangement of columns on the pages and predefine the page sort order. See Creating Custom Workflows for more information.

When you disable a column, it is disabled for the duration of your session (unless you add it back later). Note that when you disable the first column, the Count column is added. You cannot disable the Count column.

Table 58-28 Sorting and Layout Functions

To...

Click...

sort a column

the column title. Click the column title again to reverse the sort order.
) indicates which column the data is sorted by, and whether the sort is ascending (upward-pointing icon) or descending (downward-pointing icon).

remove a column from a table view

. ) to expand the search constraints, then click the column name under Disabled Columns.

add a disabled column back to the view

the column name under Disabled Columns.

When you enable a column that is disabled by default, it is enabled for the duration of your session (unless you disable it later). Note that the Count column is removed if enabling results in no identical rows.

Sorting Drill-Down Workflow Pages

License: Any

) indicates which column the data is sorted by, and whether the sort is ascending (upward-pointing icon) or descending (downward-pointing icon).

Tip If you create a custom workflow, you can fully customize the arrangement of columns on the pages and predefine the page sort order. See Creating Custom Workflows for more information.

To sort a column:

Access: Admin/Maint/Any Security Analyst

Step 1 Click the column title.

To reverse the sort order:

Access: Admin/Maint/Any Security Analyst

Step 1 Click the column title again.

Selecting Rows on a Workflow Page

License: Any

There are several different ways to select and then act on the rows on workflow pages:

- To select all rows on the page, select the check box at the top of the page.

You can then click any of the buttons at the bottom of the page (View, Delete, and so on) to perform that action on all of the events on that page.

- To select a single row, select the check box next to the individual row.

You can then click any of the buttons at the bottom of the page to perform that action on only the events associated with that row.

- To select a single row and view its associated events on the next page of the workflow, click the arrow icon (

).

Note You cannot select rows from multiple pages at once.

Navigating to Other Pages in the Workflow

License: Any

If the database contains more events than can be displayed on a single workflow page, you can click the links at the bottom of the page to display more events.

When you click one of these links, the time window automatically pauses so that you do not see the same events twice; you can unpause the time window when you are ready. For more information, see Setting Event Time Constraints.

The following table describes how to use the navigation links.

Table 58-29 Navigating Pages

To...

Click...

view a different page

the page number, enter the page you wish to view, then press Enter

view the next page

>

view the previous page

<

jump to the last page

>|

jump to the first page

|<

Navigating Between Workflows

License: Any

You can navigate to other workflows using the links in the Jump to... drop-down list on a workflow page. Select the drop-down list to view and select additional workflows.

When you select a new workflow, properties shared by the rows you select and the constraints you set are used in the new workflow, if they are applicable. If configured constraints or event properties do not map to fields in the new workflow, they are dropped. In addition, compound constraints are not retained when you switch from one workflow to another. In addition, constraints from the captured files workflow only transfer to file and malware event workflows.

Note When you view event counts over a time range, the total number of events may not reflect the number of events for which more detailed data is available. This occurs because the system sometimes prunes older event details to manage disk space usage. To minimize the occurrence of event detail pruning, you can fine-tune event logging to log only those events most important to your deployment. For more information, see Logging Connections in Network Traffic.

Note that unless you have either paused the time window or have configured a static time window, the time window changes when you change workflows. For more information, see Setting Event Time Constraints.

The Jump to drop-down list provides quick access to workflows for the following tables:

- connection events

- security intelligence events

- intrusion events

- malware events

- file events

- hosts

- indications of compromise

- applications

- application details

- servers

- host attributes

- discovery events

- users

- vulnerabilities

- third-party vulnerabilities

- correlation events

- white list events

This feature enhances your ability to investigate suspicious activity. For example, if you are viewing connection data and notice that an internal host is transmitting an abnormally large amount of data to an external site, you can select the responder IP address and the port as constraints and then jump to the Applications workflow. The applications workflow will use the responder IP address and port as IP Address and Port constraints and display additional information about the application, such as what kind of application it is. You can also click Hosts at the top of the page to view the host profile for the remote host.

After finding more information about the application, you can select Correlation Events to return to the connection data workflow, remove the Responder IP from the constraints, add the Initiator IP to constraints, and select Application Details to see what client the user on the initiating host used when transferring data to the remote host. Note that the Port constraint is not transferred to the Application Details page. While keeping the local host as a constraint, you can also use other navigation buttons to find additional information:

- To discover if any policies have been violated by the local host, keep the IP address as a constraint and select Correlation Events from the Jump to drop-down list.

- To find out if an intrusion rule triggered against the host, indicating a compromise, select Intrusion Events from the Jump to drop-down list.

- To view the host profile for the local host and determine if the host is susceptible to any vulnerabilities that may have been exploited, select Hosts from the Jump to drop-down list.

Using Bookmarks

License: Any

Create a bookmark if you want to return quickly to a specific location and time in an event analysis. Bookmarks retain information about:

- the workflow you are using

- the part of the workflow you are viewing

- the page number within the workflow

- any search constraints

- any disabled columns

- the time range you are using

The bookmarks you create are available to all user accounts with bookmark access. This means that if you uncover a set of events that require more in-depth analysis, you can easily create a bookmark and turn over the investigation to another user with the appropriate privileges.

Note If the events that appear in a bookmark are deleted (either directly by a user or by automatic database cleanup), the bookmark no longer displays the original set of events.

See these sections for more information about using bookmarks:

- Creating Bookmarks describes how to create a new bookmark.

- Viewing Bookmarks describes how to view and use existing bookmarks.

- Deleting Bookmarks describes how to delete bookmarks.

Creating Bookmarks

License: Any

Use the following procedure to create a new bookmark.

To create a bookmark:

Access: Admin/Maint/Any Security Analyst

Step 1 During an event analysis, with the events of interest displayed, click Bookmark This Page.

The Create a Bookmark page appears.

Step 2 In the Bookmark Name field, type a name (up to 80 alphanumeric characters and spaces) for the bookmark, then click Save Bookmark.

The bookmark is saved and the event page you bookmarked appears again.

Viewing Bookmarks

License: Any

Use the following procedure to view and use existing bookmarks.

To view a bookmark:

Access: Admin/Maint/Any Security Analyst

Step 1 From any event view, click View Bookmarks.

The Bookmarks page appears.

Step 2 Next to the bookmark you want to use, click View.

The page you bookmarked appears.

Note If the events that originally appeared in a bookmark are deleted (either directly by a user or by automatic database cleanup), the bookmark no longer displays the original set of events.

Deleting Bookmarks

License: Any

Use the following procedure to delete bookmarks. Note that deleting a bookmark does not affect the events retrieved by that bookmark.

To delete a bookmark:

Access: Admin/Maint/Any Security Analyst

Step 1 From any event view, click View Bookmarks.

The Bookmarks page appears.

Step 2 Click Delete next to the bookmark you want to remove.

The bookmark is deleted.

Using Custom Workflows

License: Any

If the predefined and Cisco-provided custom workflows do not meet your needs, you can create custom workflows.

For more information, see:

- Creating Custom Workflows for a procedure to create custom workflows

- Creating Custom Connection Data Workflows for a procedure to create a custom workflow based on connection data

- Viewing Custom Workflows for procedures for viewing custom workflows based on event and custom tables

- Editing Custom Workflows for a procedure for editing custom workflows

- Deleting Custom Workflows for a procedure for deleting custom workflows

Creating Custom Workflows

License: Any

If the predefined and Cisco-provided custom workflows do not meet your needs, you can create custom workflows.

Tip Instead of creating a new custom workflow, you can export a custom workflow from another appliance and then import it onto your appliance. You can then edit the imported workflow to suit your needs. For more information, see Importing and Exporting Configurations.

When you create a custom workflow, you:

- select a table to be the source of the workflow

- provide a workflow name

- add drill-down pages and table view pages to the workflow

For each drill-down page in the workflow, you can:

- provide a name that appears at the top of the page in the web interface

- include up to five columns per page

- specify a default sort order, ascending or descending

You can add table view pages in any position in the sequence of workflow pages. They do not have any editable properties, such as a page name, sort order, or user-definable column positions.

The final page of a custom workflow depends on the table on which you base the workflow, as described in the following table. These final pages are added by default when you create the workflow.

Table 58-30 Custom Workflow Final Pages

Workflows based on...

Have this final page...

discovery events

hosts

vulnerabilities

vulnerability detail

third-party vulnerabilities

hosts

users

users

indications of compromise

hosts

intrusion events

packets

The appliance does not add a final page to custom workflows based on other kinds of events (for example, audit log or malware events).

Note The procedure for creating a custom workflow based on connection data is slightly different. For more information, see the next section, Creating Custom Connection Data Workflows.

To create a custom workflow:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Custom > Custom Workflows.

The Custom Workflows page appears.

Step 2 Click Create Custom Workflow.

The Edit Custom Workflow page appears.

Step 3 Type a name for the workflow in the Name field.

You can use up to 60 alphanumeric characters and spaces in the name.

Step 4 Optionally, type a description for the workflow in the Description field.

You can use up to 80 alphanumeric characters and spaces.

Step 5 Select the table you want to include from the Table drop-down list.

Step 6 Optionally, click Add Page to add one or more drill-down pages to the workflow.

A drill-down page section appears.

Begin by typing a name for the page in the Page Name field, using up to 80 alphanumeric characters, but no spaces.

Under Column 1, select a sort priority and a table column. This column will appear in the leftmost column of the page. For example, to create a page showing the destination ports that are targeted, and to sort the page by count, select 2 from the Sort Priority drop-down list and DST Port/ICMP Code from the Field drop-down list.

Continue selecting fields to include and setting their sort priority until all the fields to appear on the page have been specified. You can specify up to five fields per page.

Note If you selected Vulnerabilities as the Table Type in step 5, then add IP Address as a table column, the IP Address column does not appear when you are viewing vulnerabilities using your custom workflow, unless you use the search feature to constrain the workflow to view a specific IP address or block of addresses. For more information on searching for vulnerabilities, see Searching for Vulnerabilities.

Step 7 Optionally, click Add Table View to add a table view page to the workflow.

Note You must add at least one drill-down page or a table view of events to a custom workflow.

Step 8 Click Save.

The new workflow is saved and added to the list of custom workflows.

Creating Custom Connection Data Workflows

License: FireSIGHT

Custom workflows based on connection data are like other custom workflows, except you can include connection data graph pages as well as drill-down pages and table view pages. You can include as many of each type of page in the workflow as you want, in any order. Each connection data graph page contains a single graph, which can be a line graph, bar graph, or pie chart. On line and bar graphs, you may include more than one dataset. For more information on connection data, including connection summaries, connection graphs, and datasets, see Understanding Connection and Security Intelligence Data.

Tip Instead of creating a new custom workflow, you can export a custom workflow from another appliance and then import it onto your appliance. You can then edit the imported workflow to suit your needs. For more information, see Importing and Exporting Configurations.

To create a custom workflow based on connection data:

Access: Admin

Step 1 Select Analysis > Custom > Custom Workflow.

Step 2 Click Create Custom Workflow.

The Edit Custom Workflow page appears.

Step 3 Type a name for the workflow in the Name field.

You can use up to 60 alphanumeric characters and spaces.

Step 4 Optionally, type a description for the workflow in the Description field.

You can use up to 80 alphanumeric characters and spaces.

Step 5 From the Table drop-down list, select Connection Events.

Step 6 Optionally, add one or more drill-down pages to the workflow:

- To add a drill-down page that contains data on individual connections, click Add Page .

- To add a drill-down page that contains connection summary data, click Add Summary Page .

In either case, a drill-down page section appears.

Begin by typing a name for the page in the Page Name field using up to 80 alphanumeric characters, but no spaces.

Under Column 1, select a sort priority and a table column. This column will appear in the leftmost column of the page.

Continue selecting fields to include and setting their sort priority until all the fields to appear on the page have been specified. You can specify up to five fields per page.

For example, to create a page showing the amount of traffic transmitted over your monitored network and to sort the page by the responders that transmitted the most traffic, select 1 from the Sort Priority drop-down list and Responder Bytes from the Field drop-down list.

Step 7 Optionally, click Add Graph to add one or more graph pages to the workflow.

A graph section appears.

Begin by typing a name for the page in the Graph Name field using up to 80 alphanumeric characters, but no spaces.

Then, select the type of graph you want to include on the page: line graph, bar graph, or pie chart.

Then, specify what kind of data you want to graph by selecting the x- and y-axes of the graph. On a pie chart, the x-axis represents the independent variable and the y-axis represents the dependent variable.

Finally, select the datasets you want to include on the graph. Note that pie charts can only include one data set.

Step 8 Optionally, add a table view of connection data by clicking Add Table View.

Step 9 Click Save.

The new workflow is saved and added to the list of custom workflows.

Viewing Custom Workflows

License: Any

The method you use to view a workflow depends on whether the workflow is based on one of the predefined event tables or on a custom table.

If your custom workflow is based on a predefined event table, access it in the same way that you would access a workflow that ships with the appliance. For example, to access a custom workflow based on the Hosts table, select Analysis Hosts. If, on the other hand, your custom workflow is based on a custom table, you must access it from the Custom Tables page.

Tip You can set a custom workflow as the default workflow for any event type; see Configuring Event View Settings.

For more information, see:

- Viewing Custom Workflows for Predefined Tables

- Viewing Custom Workflows for Custom Tables

Viewing Custom Workflows for Predefined Tables

License: Any

Use the following procedure to view a custom workflow that is not based on a custom table. Keep in mind that workflow access depends on your platform and user role, as described in Selecting Workflows.

To view a custom workflow based on a predefined table:

Access: Admin/Any Security Analyst

Step 1 Select the appropriate menu path and option for the table on which you based your custom workflow, as described in the Features Using Workflows table.

The first page of the default workflow for that table appears. To use a different workflow, including a custom workflow, click (switch workflow) beside the current workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear and the workflow can be constrained by time, you may need to adjust the time range; see Setting Event Time Constraints.

Viewing Custom Workflows for Custom Tables

License: FireSIGHT

Use the following procedure to view a custom workflow that is based on a custom table.

To view a custom workflow based on a custom table:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears, listing the available custom tables.

Step 2 Click the view icon next to the custom table you want to view, or click the name of the custom table.

The first page of the default workflow for that table appears. To use a different workflow, including a custom workflow, click (switch workflow) beside the current workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear and the workflow can be constrained by time, you may need to adjust the time range; see Setting Event Time Constraints.

Editing Custom Workflows

License: Any

If your event evaluation process changes, you can edit custom workflows to meet your new needs. Note that you cannot edit any of the predefined workflows.

To edit a custom workflow:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Custom > Custom Workflows.

The Custom Workflows page appears, listing the existing custom workflows.

) next to the name of the workflow that you want to edit.

The Edit Workflow page appears.

Step 3 Make any changes that you want to the workflow and click Save.

The changes you made to the workflow are saved.

Deleting Custom Workflows

License: Any

The following procedure explains how to delete a custom workflow that you no longer need.

To delete a custom workflow:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Custom > Custom Workflows.

The Custom Workflows page appears, listing the available custom workflows.

) next to the name of the workflow that you want to delete.

The workflow is deleted.

Using Custom Tables

As the FireSIGHT System collects information about your network, the Defense Center stores it in a series of database tables. When you use a workflow to view the resulting information, the Defense Center pulls the data from one of these tables. For example, the columns on each page of the Network Applications by Count workflow are taken from the fields in the Applications table.

If you determine that your analysis of the activity on your network would be enhanced by combining fields from different tables, you can create a custom table. For example, you could combine the host criticality information from the predefined Host Attributes table with the fields from the predefined Connection Data table and then examine connection data in a new context.

Note that you can create custom workflows for either predefined or custom tables. For more information on creating custom workflows, see Creating Custom Workflows.

The following sections describe how to create and use your own custom tables:

- Understanding Custom Tables

- Creating a Custom Table

- Modifying a Custom Table

- Deleting a Custom Table

- Viewing a Workflow Based on a Custom Table

- Searching Custom Tables

Understanding Custom Tables

License: FireSIGHT

Custom tables contain fields from two or more predefined tables. The FireSIGHT System is delivered with a number of system-defined custom tables, but you can create additional custom tables that contain only information that matches your specific needs.

Table 59-1 System-Defined Custom Tables

Table

Description

Hosts with Servers

Includes fields from the Hosts and Servers tables, providing you with information about the detected applications running on your network, as well as basic operating system information about the hosts running those applications.

Intrusion Events with Destination Criticality

Includes fields from the Intrusion Events table and the Hosts table, providing you with information on the intrusion events, as well as the host criticality of the destination host involved in each intrusion event.

Tip Use this table to search for intrusion events involving destination hosts with high host criticality.

Intrusion Events with Source Criticality

Includes fields from the Intrusion Events table and the Hosts table, providing you with information on the intrusion events and the host criticality of the source host involved in each intrusion event.

Tip Use this table to search for intrusion events involving source hosts with high host criticality.

Understanding Possible Table Combinations

License: FireSIGHT + Protection

Table 59-2 Custom Table Combinations

You can combine fields from...

With fields from...

Applications

- Correlation Events

- Intrusion Events

- Connection Summary Data

- Host Attributes

- Application Details

- Discovery Events

- Connection Events

- Hosts

- Servers

- White List Events

Correlation Events

- Applications

- Host Attributes

- Hosts

Intrusion Events

- Applications

- Host Attributes

- Hosts

- Servers

Connection Summary Data

- Applications

- Host Attributes

- Hosts

- Servers

Indications of Compromise

- Applications

- Application Details

- Captured Files

- Connection Events

- Connection Summary Data

- Correlation Events

- Discovery Events

- Host Attributes

- Hosts

- Intrusion Events

- Security Intelligence Events

- Servers

- White List Events

Host Attributes

- Applications

- Correlation Events

- Intrusion Events

- Connection Summary Data

- Application Details

- Discovery Events

- Connection Events

- Hosts

- Servers

- White List Events

Application Details

- Applications

- Host Attributes

- Hosts

Discovery Events

- Applications

- Host Attributes

- Hosts

Connection Events

- Applications

- Host Attributes

- Hosts

- Servers

Security Intelligence Events

- Applications

- Host Attributes

- Hosts

- Servers

Hosts

- Applications

- Correlation Events

- Intrusion Events

- Connection Summary Data

- Host Attributes

- Application Details

- Discovery Events

- Connection Events

- Servers

- White List Events

Servers

- Applications

- Intrusion Events

- Connection Summary Data

- Host Attributes

- Connection Events

- Hosts

White List Events

- Applications

- Host Attributes

- Hosts

Sometimes a field in one table maps to more than one field in another table. For example, the predefined Intrusion Events with Destination Criticality custom table combines fields from the Intrusion Events table and the Hosts table. Each event in the Intrusion Events table has two IP addresses associated with it—a source IP address and a destination IP address. However, the “events” in the Hosts table each represent a single host IP address (hosts may have multiple IP addresses). Therefore, when you create a custom table based on the Intrusion Events table and the Hosts table, you must choose whether the data you display from the Hosts table applies to the host source IP address or the host destination IP address in the Intrusion Events table.

When you create a new custom table, a default workflow that displays all the columns in the table is automatically created. Also, just as with predefined tables, you can search custom tables for data that you want to use in your network analysis. You can also generate reports based on custom tables, as you can with predefined tables.

For more information on creating custom tables, see:

- Creating a Custom Table

- Modifying a Custom Table

- Deleting a Custom Table

- Viewing a Workflow Based on a Custom Table

- Searching Custom Tables

Creating a Custom Table

License: FireSIGHT

If you determine that your analysis of the activity on your network would be enhanced by combining fields from different tables, you can create a custom table.

Tip Instead of creating a new custom table, you can export a custom table from another Defense Center, then import it onto your Defense Center. You can then edit the imported custom table to suit your needs. For more information, see Importing and Exporting Configurations.

To create a custom table, decide which predefined tables delivered with the FireSIGHT System contain the fields you want to include in your custom table. You can then choose which fields you want to include and, if necessary, configure field mappings for any common fields.

Tip Data involving the Hosts table allows you to view data associated with all IP addresses from one host, rather than one specific IP address.

If you view the table view of events for this custom table, it displays correlation events, one per row. The following information is included:

- the date and time the event was generated

- the name of the correlation policy that was violated

- the name of the rule that triggered the violation

- the IP address associated with the source, or initiating, host involved in the correlation event

- the source host’s NetBIOS name

- the operating system and version the source host is running

- the source host criticality

Tip You could create a similar custom table that displays the same information for destination, or responding, hosts.

To build the custom table in the previous example:

Access: Admin

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears.

Step 2 Click Create Custom Table.

The Create Custom Table page appears.

Step 3 In the Name field, type a name for the custom table, such as Correlation Events with Host Information (Src IP).

Step 4 From the Tables drop-down list, select Correlation Events.

The fields in the Correlation Events table appear in the Fields list.

Step 5 Under Fields, select Time and click Add to add the date and time when a correlation event was generated.

Step 6 Repeat step 5 to add the Policy and Rule fields.

Tip You can use Ctrl or Shift while clicking to select multiple fields. You can also click and drag to select multiple adjacent values. However, if you want to specify the order the fields appear in the table view of events associated with the table, add the fields one at a time.

Step 7 From the Tables drop-down list, select Hosts.

The fields in the Hosts table appear in the Fields list. For more information on these fields, see Understanding the Hosts Table.

Step 8 Add the IP Address, NetBIOS Name, OS Name, OS Version, and Host Criticality fields to the custom table.

Step 9 Under Common Fields, next to Correlation Events, select Source IP.

Your custom table is configured to display the host information you chose in step 8 for the source, or initiating, hosts involved in correlation events.

Tip You could create a custom table that displays detailed host information for the destination, or responding, hosts involved in a correlation event by following this procedure but selecting Destination IP instead of Source IP.

Step 10 Click Save.

The custom table is saved.

Modifying a Custom Table

License: FireSIGHT

You can add or delete fields in a custom table as your needs change.

To modify a custom table:

Access: Any/Admin

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears.

) next to the table you want to edit.

The Edit Custom Table page appears. See Creating a Custom Table for information on the various configurations you can change.

) next to the fields you want to remove.

Note If you delete fields currently in use in reports, you will be prompted to confirm that you want to remove the sections using those fields from those reports.

Step 4 Make other changes as needed and click Save.

Your custom table is updated.

Deleting a Custom Table

License: FireSIGHT

You can delete a custom table that you no longer need. If you delete a custom table, saved searches that use the custom table are also deleted.

To delete a custom table:

Access: Any/Admin

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears.

) next to the custom table you want to delete.

The table is deleted.

Viewing a Workflow Based on a Custom Table

License: FireSIGHT

When you create a custom table, the system automatically creates a default workflow for it. The first page of this workflow displays a table view of events. If you include intrusion events in your custom table, the second page of the workflow is the packet view. Otherwise, the second page of the workflow is a hosts page. You can also create your own custom workflows based on your custom table.

Tip If you create a custom workflow based on a custom table, you can specify it as the default workflow for that table. For more information, see Configuring Event View Settings.

You can use the same techniques to view events in your custom table that you use for event views based on predefined tables. See Using Workflow Pages for more information.

To view a workflow based on a custom table:

Access: Any/Admin

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears.

) next to the custom table on which the workflow you want to see is based.

The first page of the default workflow for the custom table appears. To use a different workflow, click (switch workflow) by the workflow title. For information on how to specify a different default workflow, see Configuring Event View Settings. If no events appear and the workflow can be constrained by time, you may need to adjust the time range; see Setting Event Time Constraints.

Searching Custom Tables

License: FireSIGHT

You can create and save searches for a custom table. You may want to create searches customized for your network environment, then save them to reuse later. Note that if you delete a custom table, all searches you have saved for that custom table are also deleted.

The search criteria you can use are the same as the criteria for the predefined tables you used to build your custom table. See the sections listed in the following table for detailed information on the search criteria you can use.

Table 59-3 Table Search Criteria

For search criteria for...

See...

Audit Events

Searching Audit Records

Application Details

Searching for Application Details

Correlation Events

Searching for Correlation Events

Connection Data

Searching for Connection and Security Intelligence Data

Hosts

Searching for Hosts

Host Attributes

Searching for Host Attributes

Hosts with Applications

Searching for Hosts and Searching for Servers

Intrusion Events

Searching for Intrusion Events

Intrusion Events with Destination Criticality

Searching for Intrusion Events and Searching for Hosts

Intrusion Events with Source Criticality

Searching for Intrusion Events and Searching for Hosts

Status Events

Searching for Remediation Status Events

Discovery Events

Searching for Discovery Events

User Events

Searching for User Activity

Rule Update Import Log

Searching the Rule Update Import Log

Applications

Searching for Applications

Security Intelligence Events

Searching for Connection and Security Intelligence Data

Users

Searching for Users

Vulnerabilities

Searching for Vulnerabilities

White List Events

Searching for Compliance White List Events

White List Violations

Searching for White List Violations

To implement these criteria in a table search, see the following procedure.

To perform a search on a custom table:

Access: Any/Admin

Step 1 Select Analysis > Custom > Custom Tables.

The Custom Tables page appears.

) next to the custom table you want to search.

The first page of the default workflow for the custom table appears. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear and the workflow can be constrained by time, you may need to adjust the time range; see Setting Event Time Constraints.

Step 3 Click Search.

The custom table’s search page appears.

Tip To search the database for a different kind of event or data, select it from the table drop-down list.

Step 4 Enter your search criteria in the appropriate fields. For more information about choosing search criteria, see the Table Search Criteria table.

If you enter criteria for multiple fields, the search returns only the records that match search criteria specified for all fields.

Step 5 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 6 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 7 Click Search to start the search.

Your search results appear in the default workflow for the custom table, constrained by the current time range (if applicable). To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

Searching for Events

Cisco appliances generate information that is stored as events in database tables. Events contain multiple fields that describe the activity that caused the appliance to generate the event.

The FireSIGHT System provides predefined searches that serve as examples and can provide quick access to important information about your network. You can modify fields within the predefined searches for your network environment, then save the searches to reuse later. You can also use your own search criteria.

The search criteria you can use depends on the type of search, but the mechanics are the same. See the following sections for more information on how to perform a search and on the correct syntax to use in search fields:

- Performing and Saving Searches

- Using Wildcards and Symbols in Searches

- Using Objects and Application Filters in Searches

- Specifying Time Constraints in Searches

- Specifying IP Addresses in Searches

- Specifying Devices in Searches

- Specifying Ports in Searches

- Stopping Long-Running Queries

Performing and Saving Searches

License: Any

You can create and save searches for any of the different event types. When you create a search you give it a name and specify whether the search will be available to you alone or to all users of the appliance. If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

For more information, see the following sections:

- Performing a Search

- Loading a Saved Search

- Deleting a Saved Search

Note To search a custom table, follow a slightly different procedure; see Searching Custom Tables.

Performing a Search

License: Any

For some event types, the FireSIGHT System provides predefined searches that serve as examples and can provide quick access to important information about your network. You can modify fields within the predefined searches for your network environment, then save the searches to reuse later. You can also use your own search criteria.

To perform a search:

Access: Admin/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 From the table drop-down list, select the type of event or data to search.

The page updates with the appropriate search constraints.

Step 3 Enter your search criteria in the appropriate fields:

- All fields accept negation ( ! ).

- All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.

- All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E". This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B, or all of C, D, and E.

- Searches return only records that match the search criteria specified for all fields.

- Many fields accept one or more asterisks ( * ) as wild cards.

- Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.

- Click the add object icon (

) that appears next to a search field to use an object as a search criterion.

Step 4 See the following sections for detailed information on the search criteria you can use:

- Searching Audit Records

- Searching for Applications

- Searching for Application Details

- Searching for Captured Files

- Searching for Compliance White List Events

- Searching for Connection and Security Intelligence Data

- Searching for Correlation Events

- Searching for Discovery Events

- Searching for File Events

- Searching for Health Events

- Searching for Host Attributes

- Searching for Hosts

- Searching for Intrusion Events

- Searching for Malware Events

- Searching the Rule Update Import Log

- Searching for Remediation Status Events

- Searching for Scan Results

- Searching for Servers

- Searching for Third-Party Vulnerabilities

- Searching for Users

- Searching for User Activity

- Searching for Vulnerabilities

- Searching for White List Violations

Step 5 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 6 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 7 Click Search to start the search.

Your search results appear in the default workflow for the table you are searching, constrained by time (if applicable). To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. Note that you cannot use a different workflow for scan results.

Loading a Saved Search

License: Any

If you previously saved a search, you can load it, make any necessary modifications, and then start the search.

To load a saved search:

Access: Admin/Any Security Analyst

Step 1 You have the following options:

- From any page on a workflow, click Search .

- Select Analysis > Search , then select the type of events you want to search for.

The Search page appears.

Step 2 Select the search you want to load from the Custom Searches list or the Predefined Searches list.

Settings from the saved search populate the search constraints.

Step 3 Optionally, change the search constraints.

Step 4 Click Search.

The events that match your search constraints appear.

Deleting a Saved Search

License: Any

If you have saved searches, you can delete them from the Search page.

To delete a saved search:

Access: Admin/Any Security Analyst

Step 1 You have the following options:

- From any page on a workflow, click Search .

- Select Analysis > Search , then select the event type for the search that you want to delete.

The Search page appears.

) that appears next to the search name.

The search is deleted.

Using Wildcards and Symbols in Searches

License: Any

Many text fields on search pages allow you to use an asterisk (*) to match characters in a string. For example, specifying net* matches network, netware, netscape, and so on.

If you want to search for non-alphanumeric characters (including the asterisk character), enclose the search string in quotation marks. For example, to search for the string:

Find an asterisk (*)

enter:

"Find an asterisk (*)"

Note that in text fields that allow a wildcard, you must use the wildcard if you want to match a partial string. For example, if you are searching the audit log for all audit records that involve page views (that is, the message is Page View), searching for Page returns no results. Instead, specify Page*.

Using Objects and Application Filters in Searches

License: Any

The FireSIGHT System allows you to create named objects, object groups, and application filters that can be used as part of your network configuration. You can use these objects, groups, and filters as search criteria when performing or saving searches.

When you perform a search, objects, object groups, and application filters appear in the format, ${object_name}. For example, a network object with the object name ten_ten_network appears as ${ten_ten_network} in a search.

) that appears next to a search field where you can use an object as a search criterion.

Specifying Time Constraints in Searches

License: Any

You can use a number of formats for specifying time search constraints. You can enter a time you want to match, and, optionally, a less than (<) or greater than (>) operator to match times before or after the time you enter.

Table 60-1 Time Specification in Search Fields

Time Formats

Example

today [at HH:MMam|pm]

today

today at 12:45pm

YYYY-MM-DD HH:MM:SS

2006-03-22 14:22:59

Table 60-2 Time Specification Operators

Operator

Example

Explanation

<

< 2006-03-22 14:22:59

Returns events with a timestamp before 2:23 PM, March 22, 2006.

>

> today at 2:45pm

Returns events with a timestamp later than today at 2:45 PM.

Specifying IP Addresses in Searches

License: Any

When specifying IP addresses in searches, you can enter an individual IP address, a comma-separated list of addresses, an address block, or a range of IP addresses separated with a hyphen (-). You can also use negation.

For searches that support IPv6 (such as intrusion event, connection data, and correlation event searches) you can enter IPv4 and IPv6 addresses and CIDR/prefix length address blocks in any combination.

When you use CIDR or prefix length notation to specify a block of IP addresses, the FireSIGHT System uses only the portion of the network IP address specified by the mask or prefix length. For example, if you type 10.1.2.3/8, the FireSIGHT System uses 10.0.0.0/8.

) that appears next to an IP address search field to use a network object as an IP address search criterion. For more information, see Using Objects and Application Filters in Searches.

Table 60-3 Acceptable IP Address Syntax

To specify...

Type...

For example...

a single IP address

the IP address.

192.168.1.1

2001:db8::abcd

multiple IP addresses using a list

a comma-separated list of IP addresses. Do not add a space before or after the commas.

192.168.1.1,192.168.1.2

2001:db8::b3ff,2001:db8::0202

a range of IP addresses that can be specified with a CIDR block or prefix length

the IP address block in IPv4 CIDR or IPv6 prefix length notation.

192.168.1.0/24

This specifies any IP in the 192.168.1.0 network with a subnet mask of 255.255.255.0, that is, 192.168.1.0 through 192.168.1.255. For more information, see IP Address Conventions.

a range of IP addresses that cannot be specified with a CIDR block or prefix

the IP address range using a hyphen. Do not add a space before or after the hyphen.

192.168.1.1-192.168.1.5

2001:db8::0202-2001:db8::8329

negation of any of the other ways to specify IP addresses or ranges of IP addresses

an exclamation point in front of the IP address, block, or range.

192.168.0.0/32,!192.168.1.10

!2001:db8::/32

!192.168.1.10,!2001:db8::/32

Specifying Devices in Searches

License: Any

When creating a search using a managed device as a constraint, you can specify any of the following in the Device search criteria field:

- A managed device name, IP address, or host name

- A device group name

- A device stack name

- A device cluster name

If the system finds a match for a group, cluster, or stack, it replaces the group, cluster, or stack name with the appropriate member device names for the purpose of performing the search. When you save a search that uses a device group, cluster, or stack in the device field the system saves the name specified in the device field and performs the device name replacement again each time the search is executed.

See the following sections for more information:

- Working with Devices

- Managing Device Groups

- Managing Stacked Devices

- Clustering Devices

Specifying Ports in Searches

License: Any

The FireSIGHT System accepts specific syntax for port numbers in searches. You can enter:

- a single port number

- a comma-separated list of port numbers

- two port numbers separated by a dash to represent a range of port numbers

- a port number followed by a protocol abbreviation, separated by a forward slash (only when searching for intrusion events)

- a port number or range of port numbers preceded by an exclamation mark to indicate a negation of the specified ports

Note Do not use spaces when specifying port numbers or ranges.

The following table contains examples of valid ways to enter ports as search constraints.

\

Table 60-4 Port Syntax Examples

Example

Description

21

Returns all events on port 21, including TCP and UDP events.

!23

Returns all events except those on port 23.

25/tcp

Returns all TCP-related intrusion events on port 25.

21/tcp,25/tcp

Returns all TCP-related intrusion events on ports 21 and 25

21-25

Returns all events on ports 21 through 25.

Stopping Long-Running Queries

License: Any

Supported Devices: Any Defense Center

System administrators can use a shell-based query management tool to locate and stop long-running queries.

Note Leaving the search page in the web interface does not stop a query. Queries that take a long time to return results impact overall system performance while the query is running.

The query management tool allows you to locate queries running longer than a specified number of minutes and stop those queries. The tool logs an event to the audit log and to syslog when you stop a query.

Note that the only locally-created user with shell access on Defense Centers is the admin user. If you use an external authentication object which grants shell access, users matching the shell access filter can also log into the shell.

Usage:

query_manager [-v] [-l [minutes]] [-k query_id [...]]

[--kill-all minutes]

Options:

-h, --help

Prints a brief help message.

-l, --list [minutes]

Lists all queries taking longer than passed in minutes. By

default it will show all queries taking longer than 1 minute.

-k, --kill query_id [...]

Kills the query with the passed in id. The option can take

multiple ids.

--kill-all minutes

Kills all queries taking longer than passed in minutes.

-v, --verbose

Verbose output including full SQL queries.

Caution Shell access should be limited to system administrators.

To stop a query on the Defense Center:

Access: admin or other user granted shell access

Step 1 Connect to the Defense Center via ssh.

Step 2 Run query_manager under sudo using the syntax described above.

Managing Users

If your user account has Administrator access, you can manage the user accounts that can access the web interface on your Defense Center or managed device. On the Defense Center, you can also set up user authentication via an external authentication server, rather than through the internal database.

For more information, see the following sections:

- Understanding Cisco User Authentication

- Managing Authentication Objects

- Managing User Accounts

- Managing User Role Escalation

- Configuring Single Sign-on from Cisco Security Manager

Understanding Cisco User Authentication

License: Any

When a user logs into the web interface, the appliance looks for a match for the user name and password in the local list of users. This process is called authentication. There are two kinds of authentication: internal and external. If the user’s account uses internal authentication, the authentication process checks the local database for this list. If the account uses external authentication, the process checks the local database to see if the user exists there and, if the user is not found locally, it queries an external server, such as a Lightweight Directory Access Protocol (LDAP) directory server or a Remote Authentication Dial In User Service (RADIUS) authentication server, for a list of users.

For users with either internal or external authentication, you can control user permissions. Users with external authentication receive the permissions either for the group or access list they belong to, or based on the default user access role you set in the server authentication object or in a system policy on the managing Defense Center, unless you change the user permissions manually.

For more information, see the following sections:

- Understanding Internal Authentication

- Understanding External Authentication

- Understanding User Privileges

Understanding Internal Authentication

License: Any

By default, the FireSIGHT System uses internal authentication to check user credentials when a user logs in. Internal authentication occurs when the user name and password are verified against records in the internal FireSIGHT System database. If you do not enable external authentication when you create a user, the user credentials are managed in the internal database.

Because you manually create each internally authenticated user, you set the access rights when you create the user and you do not need to set default settings.

Note Note that an internally authenticated user is converted to external authentication if you enable external authentication, the same user name exists for the user on the external server, and the user logs in using the password stored for that user on the external server. After an internally authenticated user converts to an externally authenticated user, you cannot revert to internal authentication for that user.

Understanding External Authentication

License: Any

External authentication occurs when the Defense Center or managed device retrieves user credentials from an external repository, such as an LDAP directory server or RADIUS authentication server. LDAP authentication and RADIUS authentication are types of external authentication. Note that you can only use one form of external authentication for an appliance.

If you want to use external authentication, you must configure an authentication object for each external authentication server where you want to request user information. The authentication object contains your settings for connecting to and retrieving user data from that server. You can then enable that object in a system policy on the managing Defense Center and apply the policy to an appliance to enable authentication. When any externally authenticated user logs in, the web interface checks each authentication server to see if that user is listed, in the order the servers are listed in the system policy.

When you create a user, you can specify whether that user is internally or externally authenticated.

Note Before enabling external authentication on Series 3 managed devices, remove any internally-authenticated shell users that have the same user name as externally-authenticated users included in your shell access filter.

You can push a system policy to a managed device to enable external authentication on that device, but you cannot control the authentication object from the device’s web interface. The only configuration of external authentication on the device occurs when you select the type of authentication for a new user. If you want to disable external authentication on a managed device, disable it in the system policy on the managing Defense Center and reapply the policy to the device. If you apply a local system policy (created on the managed device) to the device itself, external authentication is also disabled.

Tip You can use the Import/Export feature to export system policies. When you export a policy with external authentication enabled, the authentication objects are exported with the policy. You can then import the policy and object on another Defense Center. Do not import policies with authentication objects onto managed devices.

For more information on specific types of external authentication, see the following sections:

- LDAP Authentication

- RADIUS Authentication

Understanding User Privileges

License: Any

The FireSIGHT System lets you allocate user privileges based on the user’s role. For example, an analyst typically needs access to event data to analyze the security of monitored networks, but might never require access to administrative functions for the FireSIGHT System itself. You can grant analysts predefined roles such as Security Analyst and Discovery Admin and reserve the Administrator role for the network administrator managing the FireSIGHT System. You can also create custom user roles with access privileges tailored to your organization’s needs.

In the system policy on the Defense Center, you set a default access role for all users who are externally authenticated. After an externally authenticated user logs in for the first time, you can add or remove access rights for that user on the User Management page. If you do not modify the user’s rights, the user has only the rights granted by default. Because you create internally authenticated users manually, you set the access rights when you create them.

If you configured management of access rights through LDAP groups, the access rights for users are based on their membership in LDAP groups. They receive the default access rights for the group that they belong to that has the highest level of access. If they do not belong to any groups and you have configured group access, they receive the default user access rights configured in the authentication object for the LDAP server. If you configure group access, those settings override the default access setting in the system policy.

Similarly, if you assign a user to specific user role lists in a RADIUS authentication object, the user receives all assigned roles, unless one or more of those roles are mutually incompatible. If a user is on the lists for two mutually incompatible roles, the user receives the role that has the highest level of access. If the user does not belong to any lists and you have configured a default access role in the authentication object, the user receives that role. If you configure default access in the authentication object, those settings override the default access setting in the system policy.

The FireSIGHT System supports the following predefined user roles, listed in order of precedence, depending on the features you have licensed:

- Access Admins can view and modify access control and file policies, but cannot apply their policy changes.

- Administrators can set up the appliance’s network configuration, manage user accounts and Collective Security Intelligence Cloud connections, and configure system policies and system settings. Users with the Administrator role have all rights and privileges of all other roles (with the exception of lesser, restricted versions of those privileges).

- Discovery Admins can review, modify and delete network discovery policies, but cannot apply their policy changes.

- External Database users can query the FireSIGHT System database using an external application that supports JDBC SSL connections. On the web interface, they can access the online help and user preferences.

- Intrusion Admins have access to all intrusion policy, intrusion rule, and network analysis policy features. Intrusion Admins have access to intrusion-related options in the Policies menu. Note that Intrusion Admins cannot apply intrusion or network analysis policies as part of access control policies.

- Maintenance Users can access monitoring functions (including health monitoring, host statistics, performance data, and system logs) and maintenance functions (including task scheduling and backing up the system).

Note that maintenance users do not have access to the functions in the Policies menu and can only access the dashboard from the Analysis menu.

- Network Admins can review, modify, and apply device configurations as well as review and modify access control policies.

- Security Approvers can view and apply, but not create, configuration and policy changes.

- Security Analysts can review, analyze, and delete intrusion, discovery, user activity, connection, correlation, and network change events. They can review, analyze, and (when applicable) delete hosts, host attributes, services, vulnerabilities, and client applications. Security Analysts can also generate reports and view (but not delete or modify) health events.

- Security Analysts (Read Only) have all the same rights as Security Analysts, except that they cannot delete events.

In addition to the above predefined roles, you can also configure custom user roles with specialized access privileges. Any role can be the default access role for externally authenticated users.

You can grant user role escalation privileges to externally authenticated user accounts; you can also use an externally authenticated user’s password as the escalation password. For more information, see Managing User Role Escalation.

Managing Authentication Objects

License: Any

Authentication objects are server profiles for external authentication servers, containing connection settings and authentication filter settings for those servers. You can create, configure, and delete authentication objects on the Defense Center and use them to manage external authentication to LDAP or RADIUS servers. See the following sections for details:

- LDAP Authentication

- RADIUS Authentication

- Deleting Authentication Objects

LDAP Authentication

License: Any

LDAP, or the Lightweight Directory Access Protocol, allows you to set up a directory on your network that organizes objects, such as user credentials, in a centralized location. Multiple applications can then access those credentials and the information used to describe them. If you ever need to change a user's credentials, you can change them in one place, rather than having to change them on each FireSIGHT System appliance.

See the following sections for more information:

- Understanding LDAP Authentication

- Understanding LDAP Authentication With CAC

- Preparing to Create an LDAP Authentication Object

- Creating Basic LDAP Authentication Objects

- Creating Advanced LDAP Authentication Objects

- LDAP Authentication Object Examples

- Editing LDAP Authentication Objects

Understanding LDAP Authentication

License: Any

You can create LDAP authentication objects on a Defense Center, but not on other FireSIGHT System appliances. However, you can use the external authentication object on any appliance (except virtual devices or Cisco NGIPS for Blue Coat X-Series) by applying a system policy where the object is enabled to the appliance. When you apply the policy, the object is copied to the appliance.

Note Before enabling external authentication on Series 3 managed devices, remove any internally-authenticated shell users that have the same user name as externally-authenticated users included in your shell access filter.

Note that you can use LDAP naming standards for address specification and for filter and attribute syntax in your authentication object. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type JoeSmith@security.example.com rather than the equivalent user distinguished name of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server.

Note Currently, the FireSIGHT System supports LDAP external authentication on LDAP servers running Microsoft Active Directory on Windows Server 2008, Oracle Directory Server Enterprise Edition 7.0 on and Windows Server 2008, or OpenLDAP on Linux. However, the FireSIGHT System does not support external authentication for virtual devices or Cisco NGIPS for Blue Coat X-Series.

For more information, see the following sections:

- Understanding Defaults

- Understanding Base DNs

- Understanding Base Filters

- Understanding Impersonation Accounts

- Understanding Your LDAP Connection

- Understanding User Name Templates

- Understanding Connection Timeouts

- Understanding Attributes to Manage Access

- Understanding Group Membership to Manage Access

- Understanding Shell Access

Understanding Defaults

License: Any

You can populate several fields using default values based on the server type you plan to connect to. Default values propagate the User Name Template, UI Access Attribute, Shell Access Attribute, Group Member Attribute, and Group Member URL Attribute fields when you select a server type and set defaults.

Understanding Base DNs

License: Any

When the local appliance searches the LDAP server to retrieve user information on the authentication server, it needs a starting point for that search. You can specify the tree that the local appliance should search by providing a base distinguished name, or base DN.

Typically, the base DN has a basic structure indicating the company domain and operational unit. For example, the Security organization of the Example company might have a base DN of ou=security,dc=example,dc=com.

After you identify a primary server, you can automatically retrieve a list of available base DNs from it and select the appropriate base DN.

Understanding Base Filters

License: Any

You can add a base filter (maximum 450 characters, including the enclosing parentheses) that sets a specific value for a specific attribute. The base filter focuses your search by only retrieving objects in the base DN that have the attribute value set in the filter. Enclose the base filter in parentheses. For example, to filter for only users with a common name starting with F, use the filter (cn=F*).

To test your base filter more specifically by entering a test user name and password, see Testing User Authentication.

Understanding Impersonation Accounts

License: Any

To allow the local appliance to access the user objects, you must supply user credentials for an impersonation account. The impersonation account is a user account with appropriate rights to browse the directory named by the base DN and retrieve the user objects you want to retrieve. Remember that the distinguished name for the user you specify must be unique to the tree for the server.

Understanding Your LDAP Connection

License: Any

You can manage the encryption method for your LDAP connection. You can choose no encryption, Transport Layer Security (TLS), or Secure Sockets Layer (SSL) encryption.

Note that if you are using a certificate to authenticate when connecting via TLS or SSL, the name of the LDAP server in the certificate must match the name that you use in the Host Name/IP Address field. For example, if you enter 10.10.10.250 in the external authentication settings and computer1.example.com in the certificate, the connection fails. Changing the name of the server in the external authentication settings to computer1.example.com causes the connection to succeed.

Understanding User Name Templates

License: Any

Selecting a user name template lets you indicate how user names entered on login should be formatted, by mapping the string conversion character (%s) to the value of the UI access attribute or shell access attribute for the user. The user name template is the format for the distinguished name used for authentication. When a user enters a user name into the login page, the name is substituted for the string conversion character and the resulting distinguished name is used to search for the user credentials.

For example, to set a user name template for the Security organization of the Example company, you might enter %s@security.example.com. If you want to use an object for CAC authentication and authorization, you must enter a value for the user name template that corresponds with your UI access attribute value. For more information, see Understanding LDAP Authentication With CAC.

Understanding Connection Timeouts

License: Any

If you specify a backup authentication server, you can set a timeout for the connection attempt to the primary server. If the timeout period elapses without a response from the primary authentication server, the appliance then queries the backup server. For example, if the primary server has LDAP disabled, the appliance queries the backup server.

If LDAP is running on the port of the primary LDAP server and for some reason refuses to service the request (due to misconfiguration or other issues), however, the failover to the backup server does not occur.

Understanding Attributes to Manage Access

License: Any

Different types of LDAP servers use different attributes to store user data. See the following sections for an explanation of UI and shell access attributes.

UI Access Attributes

If your LDAP server uses a UI access attribute of uid, the local appliance checks the uid attribute value for each object in the tree indicated by the base DN you set. If you do not set a specific UI access attribute, the local appliance checks the distinguished name for each user record on the LDAP server to see if it matches the user name. If one of the objects has a matching user name and password, the user login request is authenticated.

You can substitute a different LDAP attribute to make the local appliance match a user name with that attribute rather than the value of the distinguished name. Selecting a server type and setting defaults fills in a UI access attribute appropriate for that type of server. If one of the objects has a matching user name and, for non-CAC objects, a password as a value for the attribute you specify, the user login request is authenticated. You can use any attribute, if the value of the attribute is a valid user name for the FireSIGHT System web interface. Valid user names are unique, and can include underscores (_), periods (.), hyphens (-), and alphanumeric characters. If you want to use an object for CAC authentication and authorization, you must enter a value for the UI access attribute that corresponds with the user name template value. For more information, see Understanding LDAP Authentication With CAC.

Shell Access Attributes

If your LDAP server uses uid as your shell access attribute, the local appliance checks the user name entered on login against the attribute value of uid. You can also set a custom shell access attribute other than uid.

Note that selecting a server type and setting defaults prepopulates a shell access attribute typically appropriate for that type of server. You can use any attribute, if the value of the attribute is a valid user name for shell access. Valid user names are unique, and can include underscores (_), periods (.), hyphens (-), and alphanumeric characters.

Understanding Group Membership to Manage Access

License: Any

If you prefer to base default access rights on a user’s membership in an LDAP group, you can specify distinguished names for existing groups on your LDAP server for each of the access roles used by your FireSIGHT System. When you do so, you can configure a default access setting for those users detected by LDAP that do not belong to any specified groups. When a user logs in, the FireSIGHT System dynamically checks the LDAP server and assigns access rights according to the user’s current group membership.

When a user authenticated by an LDAP server logs into a local FireSIGHT System appliance for the first time, the user receives the access rights for groups the user belongs to, or if groups are not configured, the default access setting you selected in the system policy.

You can then modify those settings, unless the settings are granted through group membership.

Understanding Shell Access

License: Any

You can use the LDAP server to authenticate accounts for shell access on a managed device or Defense Center. Specify a search filter that retrieves entries for users to whom you want to grant shell access. Note that you can only configure shell access for the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.

With the exception of the admin account, shell access is controlled entirely though the shell access attribute you set. Shell users are configured as local users on the appliance. The filter you set here determines which set of users on the LDAP server can log into the shell.

Note that a home directory for each shell user is created on login, and when an LDAP shell access user account is disabled (by disabling the LDAP connection), the directory remains, but the user shell is set to /bin/false in /etc/password to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.

If all users qualified in the base DN are also qualified for shell access privileges, you can configure the shell access filter to search more efficiently by selecting Same as Base Filter. Normally, the LDAP query to retrieve users combines the base filter with the shell access filter. If you type the same shell access filter as the base filter, the same query runs twice, which is unnecessarily time-consuming.

Shell users can log in using user names with lowercase letters.Login authentication for the shell is case sensitive.

Caution On Series 3 Defense Centers, all shell users have sudoers privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the Configuration level of command line access, which also grants sudoers privileges.

Understanding LDAP Authentication With CAC

License: Any

If your organization uses Common Access Cards (CACs), you can configure LDAP authentication to authenticate users logging into the web interface and authorize access to specific functionality based on group membership or default access rights. With CAC authentication and authorization configured, users have the option to log in directly without providing a separate username and password for the appliance.

Note You must have a valid user certificate present in your browser (in this case, a certificate passed to your browser via your CAC) to enable user certificates as part of the CAC configuration process. After you configure CAC authentication and authorization, users on your network must maintain the CAC connection for the duration of their browsing session. If you remove or replace a CAC during a session, your web browser terminates the session and the system logs you out of the web interface.

For more information about configuring and managing CAC authentication and authorization, see the following sections:

- Configuring CAC Authentication and Authorization

- Managing CAC Authentication and Authorization

Configuring CAC Authentication and Authorization

License: Any

Supported Devices: Any except virtual or X-Series

Supported Defense Centers: Any except virtual or X-Series

Before users on your network can log in using their CAC credentials, a user with appropriate permissions must complete the multi-step configuration process for CAC authentication and authorization.

To configure and enable CAC authentication and authorization:

Access: Admin/Network Admin

Step 1 Insert a CAC as directed by your organization.

Step 2 Direct your browser to https://hostname/, where hostname corresponds to the host name of your Defense Center.

Step 3 If prompted, enter the PIN associated with the CAC you inserted in step 1.

Your PIN is accepted.

Step 4 If prompted, select the appropriate certificate from the drop-down list.

The browser accepts your selection and the Login page appears.

Step 5 In the Username and Password fields, log in as a user with Administrator privileges. User names are case sensitive.

Tip You cannot log in using your CAC credentials until you have fully configured CAC authentication and authorization.

The default start page appears.

Step 6 Navigate to System > Local > User Management and click the External Authentication tab. Create an LDAP authentication object exclusively for CAC authentication and authorization, following the procedures outlined in Preparing to Create an LDAP Authentication Object and Creating Advanced LDAP Authentication Objects. You must configure the following:

- the User Name Template in the advanced options of the LDAP-Specific Parameters section. For more information, see Understanding User Name Templates.

- the UI Access Attribute in the Attribute Mapping section. For more information, see Understanding Attributes to Manage Access.

- the distinguished names for existing LDAP groups in the Group Controlled Access Roles section, if you want to preconfigure access rights through LDAP group membership. For more information, see Understanding Group Membership to Manage Access.

Tip Note that you cannot configure both CAC authentication and shell access in the same authentication object. If you also want to authorize users for shell access, create separate authentication objects and enable them separately in your system policy.

Step 7 Click Save.

The External Authentication page appears, with the new object listed.

Step 8 Navigate to System > Local > System Policy. Enable external authentication, then CAC authentication in your system policy, following the procedure outlined in Enabling External Authentication.

Caution Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. See Applying a System Policy for more information.

Step 9 Navigate to System > Local > Configuration and click HTTPS Certificate. Import a HTTPS server certificate, if necessary, following the procedure outlined in Uploading Server Certificates.

Note The same certificate authority (CA) must issue the HTTPS server certificate and the user certificates on the CACs you plan to use for authentication and authorization.

The Current HTTPS Certificate Page updates to reflect the new certificate.

Step 10 Under HTTPS User Certificate Settings, select Enable User Certificates. For more information, see Requiring User Certificates.

Step 11 Optionally, after a user logs in for the first time, navigate to System > Local > User Management to manually add or remove access rights for that user. If you do not modify the user’s rights, the user has only the rights granted by default. For more information, see Understanding User Privileges and Modifying User Privileges and Options.

For more information about changing a CAC user’s role after their initial login, see the following section, Managing CAC Authentication and Authorization.

Managing CAC Authentication and Authorization

After you configure and enable CAC authentication and authorization, users on your network can log into the web interface of an appliance using their CAC credentials. For more information, see Logging into the Appliance.

CAC-authenticated users are identified in the system by their electronic data interchange personal identifier (EDIPI) numbers. After users log in using their CAC credentials for the first time, you can manually add or remove access privileges for those users on the User Management page. If you did not preconfigure a user’s privileges using group-controlled access roles, the user has only the privileges granted by default in your system policy. For more information, see Understanding User Privileges, Understanding Group Membership to Manage Access, and Modifying User Privileges and Options.

Note that the system purges manually configured access privileges when it purges CAC-authenticated users from the User Management page after 24 hours of inactivity. The users are restored to the page after each subsequent login, but you must reconfigure any manual changes to their access privileges.

Preparing to Create an LDAP Authentication Object

License: Any

Before you configure a connection to your LDAP server, you should collect the information that you need to create the LDAP authentication object. For more information on specific aspects of configuration, see Understanding LDAP Authentication.

You need the following for any authentication object:

- the server name or IP address for the server where you plan to connect

- the server type of the server where you plan to connect

- the user name and password for a user account with sufficient privileges to browse the LDAP tree

- if there is a firewall between the appliance and the LDAP server, an entry in the firewall to allow outgoing connections

- if possible, the base distinguished name for the server directory where the user names reside

Note that you can use a third-party LDAP client to browse the LDAP tree and see base DN and attribute descriptions. You can also use that client to confirm that your selected user can browse the base DN you select. Ask your LDAP administrator to recommend an approved LDAP client for your LDAP server.

Depending on how you plan to customize your LDAP authentication object configuration, you might also need the information in the following table.

Table 61-1 Additional LDAP Configuration Information

To...

You need...

connect over a port other than 389

the port number

connect via an encrypted connection

the certificate for the connection

filter the users who can access your appliance based on an attribute value

the attribute-value pair to filter by

use an attribute as a UI access attribute rather than checking the user distinguished name

the name of the attribute

use an attribute as a shell login attribute rather than checking the user distinguished name

the name of the attribute

filter the users who can access your appliance via the shell based on an attribute value

the attribute-value pair to filter by

associate groups with specific user roles

the distinguished name of each group, as well as the group member attribute if the groups are static groups or the group member URL attribute if the groups are dynamic groups

use CACs for authentication and authorization

your CAC, a server certificate signed by the same CA that issued your CAC, and the certificate chain for both certificates

Creating Basic LDAP Authentication Objects

License: Any

You can set up an LDAP authentication object where you customize many of the values. However, if you just want to authenticate all the users in a particular directory, you can create a basic authentication object with the base DN for that directory. If you set defaults to those for your server type and supply authentication credentials for the account used to retrieve user data from the server, you can quickly create an authentication object. Follow the procedure below to do so.

Note If you prefer to consider and possibly customize each authentication setting when creating the authentication object (to configure CAC authentication and authorization, for example), use the procedure in Creating Advanced LDAP Authentication Objects to create the object. You should also use the advanced procedure if you plan to encrypt your connection to the server, set user timeouts, customize the user name template, or assign FireSIGHT System user roles based on LDAP group membership.

Before you configure a connection to your LDAP server, you should collect the information that you need to create the LDAP authentication object. For more information on specific aspects of configuration, see Understanding LDAP Authentication.

To create a basic authentication object, you need the following:

- the server name or IP address for the server where you plan to connect

- the server type of the server where you plan to connect

- the user name and password for a user account with sufficient privileges to browse the LDAP tree; Cisco recommends that you use a domain admin user account for this purpose

Optionally, if you want to constrain your user search further, you can add a base filter to set a specific value for a specific attribute. The base filter focuses your search by only retrieving objects in the base DN that have the attribute value set in the filter. Enclose the base filter in parentheses. For example, to filter for only users with a common name starting with F, use the filter (cn=F*). When you save the authentication object, the local appliance queries using the base filter to test it and indicates whether or not the filter appears to be correct.

To create an LDAP authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

Step 3 Click Create External Authentication Object.

Step 4 Select LDAP from the Authentication Method drop-down list.

LDAP configuration options appear.

Step 5 Type a name and description for the authentication server in the Name and Description fields.

Step 6 Select your server type from the Server Type drop-down list, then click the Set Defaults button to configure default settings for that type. You have the following options:

- If you are connecting to a Microsoft Active Directory Server, select MS Active Directory , then click Set Defaults .

- If you are connecting to a Sun Java Systems Directory Server or Oracle Directory Server, select Oracle Directory , then click Set Defaults .

- If you are connecting to an OpenLDAP server, select OpenLDAP , then click Set Defaults .

- If you are connecting to a server other than those listed above and want to clear default settings, select Other , then click Set Defaults .

Step 7 Type the IP address or host name for the primary server where you want to obtain authentication data in the Primary Server Host Name/IP Address field.

Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.

Step 8 To fetch a list of all base DNs, click Fetch DNs and select the appropriate base DN from the drop-down list.

For example, to authenticate names in the Security organization at the Example company, select ou=security,dc=example,dc=com.

Step 9 Optionally, to set a filter that retrieves only specific objects within the directory you specified as the Base DN, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Base Filter field (maximum 450 characters, including the enclosing parentheses).

For example, if the user objects in a tree have a physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of NewYork for that attribute, to retrieve only users in the New York office, type (physicalDeliveryOfficeName=NewYork).

Step 10 In the User Name and Password fields, type the distinguished name and password for a user who has sufficient credentials to browse the LDAP server.

For example, if you are connecting to an OpenLDAP server where user objects have a uid attribute and the object for the administrator in the Security division at our example company has a uid value of NetworkAdmin, you might type uid=NetworkAdmin,ou=security,dc=example,dc=com.

Caution If you are connecting to a Microsoft Active Directory Server, you cannot provide a server user name that ends with the $ character.

Step 11 Retype the password in the Confirm Password field.

Step 12 Optionally, to retrieve users for shell access, type the attribute type you want to filter on in the Shell Access Attribute field.

For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve shell access users by typing sAMAccountName in the Shell Access Attribute field.

Note IPv6 addresses are not supported for shell authentication.

Step 13 In the User Name and Password fields, type the uid value or shell access attribute value and password for the user whose credentials should be used to validate access to the LDAP server. Note, again, that server user names associated with a Microsoft Active Directory Server cannot end with the character $.

For example, to test to see if you can retrieve the JSmith user credentials at the Example company, type JSmith.

Step 14 Click Test to test the connection.

A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. If the test succeeds, the test output appears at the bottom of the page, including a list of the users retrieved by the connection. If the number of users that appear in the test output is limited by the number of user records your LDAP server returns, the test output indicates this limitation.

Step 15 You have two options:

- If the test succeeds, click Save .

The External Authentication page appears, with the new object listed.

To enable LDAP authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.

- If the test fails, or if you want to refine the list of users retrieved, continue with the next section, Tuning Your Basic LDAP Authentication Connection.

Tuning Your Basic LDAP Authentication Connection

License: Any

If you create an LDAP authentication object and it either does not succeed in connecting to the server you select, or does not retrieve the list of users you want, you can tune the settings in the object.

If the connection fails when you test it, try the following suggestions to troubleshoot your configuration:

- Use the messages displayed at the top of the screen and in the test output to determine which areas of the object are causing the issue.

- Check that the user name and password you used for the object are valid:

- Check that the user has the rights to browse to the directory indicated in your base distinguished name by connecting to the LDAP server using a third-party LDAP browser.

- Check that the user name is unique to the directory information tree for the LDAP server.

- Check that the user name contains only underscores, periods, hyphens, and alphanumeric characters.

- If you see an LDAP bind error 49 in the test output, the user binding for the user failed. Try authenticating to the server through a third-party application to see if the binding fails through that connection as well.

- Check that you have correctly identified the server:

- Check that the server IP address or host name is correct.

- Check that you have TCP/IP access from your local appliance to the authentication server where you want to connect.

- Check that access to the server is not blocked by a firewall and that the port you have configured in the object is open.

- If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used for the server.

- Check that you have not used an IPv6 address for the server connection if you are authenticating shell access.

- If you used server type defaults, check that you have the correct server type and click Set Defaults again to reset the default values.

For more information, see Identifying the LDAP Authentication Server.

- If you typed in your base distinguished name, click Fetch DNs to retrieve all the available base distinguished names on the server, and select the name from the list.

- If you are using any filters, access attributes, or advanced settings, check that each is valid and typed correctly.

- If you are using any filters, access attributes, or advanced settings, try removing each setting and testing the object without it.

- If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses and that you are using a valid comparison operator. For more information, see Understanding Base Filters and Understanding Shell Access.

- To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve just that user.

- If you are using an encrypted connection:

- Check that the name of the LDAP server in the certificate matches the host name that you use to connect.

- Check that you have not used an IPv6 address with an encrypted server connection.

- If you are using a test user, make sure that the user name and password are typed correctly.

- If you are using a test user, remove the user credentials and test the object.

- Test the query you are using by connecting to the LDAP server via the command line on the appliance you want to connect from using this syntax:

ldapsearch -x -b 'base_distinguished_name'

-h LDAPserver_ip_address -p port -v -D

'user_distinguished_name' -W 'base_filter'

For example, if you are trying to connect to the security domain on myrtle.example.com using the domainadmin@myrtle.example.com user and a base filter of (cn=*), you could test the connection using this statement:

ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'

-h myrtle.example.com -p 389 -v -D

'domainadmin@myrtle.example.com' -W '(cn=*)'

If you can test your connection successfully but authentication does not work after you apply a system policy, check that authentication and the object you want to use are both enabled in the system policy that is applied to the appliance.

If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or change a base filter or shell access filter or use a more restrictive or less restrictive base DN. For more information, see the following topics:

- Understanding Base DNs

- Understanding Base Filters

- Configuring LDAP-Specific Parameters

Creating Advanced LDAP Authentication Objects

License: Any

You can create LDAP authentication objects to provide user authentication services for an appliance.

When you create an authentication object, you define settings that let you connect to an authentication server. You also select the directory context and search criteria you want to use to retrieve user data from the server. Optionally, you can configure shell access authentication.

Make sure you have TCP/IP access from your local appliance to the authentication server where you want to connect.

Although you can use the default settings for your server type to quickly set up a basic LDAP configuration, you can also customize advanced settings to control whether the appliance makes an encrypted connection to the LDAP server, the timeout for the connection, and which attributes the server checks for user information.

For the LDAP-specific parameters, you can use LDAP naming standards and filter and attribute syntax. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type JoeSmith@security.example.com rather than the equivalent user distinguished name of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server.

Note If you are configuring an LDAP authentication object for use with CAC authentication, do not remove the CAC inserted in your computer. You must have a CAC inserted at all times after enabling user certificates. For more information, see Requiring User Certificates and Understanding LDAP Authentication With CAC.

To create an advanced authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

Step 3 Click Create External Authentication Object.

The Create External Authentication Object page appears.

Step 4 Identify the authentication server where you want to retrieve user data for external authentication. For more information, see Identifying the LDAP Authentication Server.

Step 5 Configure authentication settings to build a search request that retrieves the users you want to authenticate. Specify a user name template to format the user names that users enter on login. For more information, see Configuring LDAP-Specific Parameters.

Step 6 Optionally, configure LDAP groups to use as the basis for default access role assignments. For more information, see Configuring Access Rights by Group.

Tip If you plan to use this object for CAC authentication and authorization, Cisco recommends configuring LDAP groups to manage access role assignments. For more information, see Managing CAC Authentication and Authorization.

Step 7 Optionally, configure authentication settings for shell access. For more information, see Configuring Shell Access.

Step 8 Test your configuration by entering the name and password for a user who can successfully authenticate. For more information, see Testing User Authentication.

Your changes are saved. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.

Identifying the LDAP Authentication Server

License: Any

When you create an authentication object, you first specify the primary and backup server and server port where you want the managed device or Defense Center to connect for authentication.

To identify an LDAP authentication server:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

Step 3 Click Create External Authentication Object.

The Create External Authentication Object page appears.

Step 4 Select LDAP from the Authentication Method drop-down list.

LDAP configuration options appear.

Step 5 Optionally, select the check box for CAC if you plan to use this authentication object for CAC authentication and authorization.

For an overview of configuring CAC authentication and authorization, see Understanding LDAP Authentication With CAC.

Step 6 Type a name and description for the authentication server in the Name and Description fields.

Step 7 Optionally, in the Server Type field, select the type of LDAP server you plan to connect to and click Set Defaults to populate the User Name Template, UI Access Attribute, Shell Access Attribute, Group Member Attribute, and Group Member URL Attribute fields with default values. You have the following options:

- If you are connecting to a Microsoft Active Directory server, select MS Active Directory and click Set Defaults .

- If you are connecting to a Sun Java Systems Directory Server or Oracle Directory Server, select Oracle Directory and click Set Defaults .

- If you are connecting to an OpenLDAP server, select OpenLDAP and click Set Defaults .

- If you are connecting to a LDAP server other than those listed above and want to clear default settings, select Other and click Set Defaults .

Step 8 Type the IP address or host name for the primary server where you want to obtain authentication data in the Primary Server Host Name/IP Address field.

Note If you are using a certificate to connect via TLS or SSL, the host name in the certificate must match the host name used in this field. In addition, IPv6 addresses are not supported for encrypted connections.

Step 9 Optionally, modify the port used by the primary authentication server in the Primary Server Port field.

Step 10 Optionally, type the IP address or host name for the backup server where you want to obtain authentication data in the Backup Server Host Name/IP Address field.

Step 11 Optionally, modify the port used by the primary authentication server in the Backup Server Port field.

Continue with Configuring LDAP-Specific Parameters.

Configuring LDAP-Specific Parameters

License: Any

The settings in the LDAP-specific parameters section determine the area of the LDAP directory where the appliance searches for user names, and control details of how the appliance connects to the LDAP server.

When configuring these settings, note that valid user names are unique, and can include underscores (_), periods (.), and hyphens (-), but otherwise only alphanumeric characters are supported.

In addition for most LDAP-specific settings, you can use LDAP naming standards and filter and attribute syntax. For more information, see the RFCs listed in the Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377. Examples of syntax are provided throughout this procedure. Note that when you set up an authentication object to connect to a Microsoft Active Directory Server, you can use the address specification syntax documented in the Internet RFC 822 (Standard for the Format of ARPA Internet Text Messages) specification when referencing a user name that contains a domain. For example, to refer to a user object, you might type JoeSmith@security.example.com rather than the equivalent user distinguished name of cn=JoeSmith,ou=security, dc=example,dc=com when using Microsoft Active Directory Server.

Table 61-2 LDAP-Specific Parameters

Setting

Description

Examples

Base DN

Supplies the base distinguished name of the directory where the appliance searches for user information on the LDAP server.

Typically, the base DN has a basic structure indicating the company domain and operational unit.

Note that after you identify a primary server, you can automatically retrieve a list of available base DNs from the server and select the appropriate base DN.

The Security organization of the Example company might have a base DN of ou=security, dc=example,dc=com

Base Filter

Focuses your search by only retrieving objects in the base DN that have the specific attribute-value pair set in the filter. Note that you must enclose the base filter in parentheses.

To test your base filter more specifically by entering a test user name and password, see Testing User Authentication.

To filter for only users with a common name starting with F, use the filter (cn=F*).

User Name/ Password

Allow the local appliance to access the user objects. Supply user credentials for a user with appropriate rights to the authentication objects you want to retrieve. The distinguished name for the user you specify must be unique to the directory information tree for the LDAP server. Note that server user names associated with a Microsoft Active Directory Server cannot end with the $ character.

The user name for the admin user in the Security organization of the Example company might have a user name of cn=admin,

ou=security,

dc=example,dc=com

Encryption

Determines whether and how the communications are encrypted. You can choose no encryption, Transport Layer Security (TLS), or Secure Sockets Layer (SSL) encryption. Note that if you are using a certificate to authenticate when connecting via TLS or SSL, the name of the LDAP server in the certificate must match the name that you use to connect.

If you change the encryption method after specifying the port, the port resets to the default value for the selected server type.

If you enter 10.10.10.250 in the external authentication settings and computer1.

example.com in the certificate, the connection fails, even if computer1.

example.com has an IP address of 10.10.10.250. Changing the name of the server in the external authentication settings to computer1.

example.com causes the connection to succeed.

SSL Certificate Upload Path

Indicates the path on your local computer to the certificate to be used for encryption.

c:/server.crt

User Name Template

Indicates how user names entered on login should be formatted, by mapping the string conversion character (%s) to the value of the shell access attribute for the user. The user name template is the format for the distinguished name used for authentication. When a user enters a user name into the login page, the appliance substitutes the name for the string conversion character and uses the resulting distinguished name to search for the user credentials.

If you want to use this object for CAC authentication and authorization, you must enter a value that corresponds with your UI Access Attribute value. For more information, see Understanding LDAP Authentication With CAC.

%s@security.example.com,

%s@mail.com,

%s@mil,

%s@smil.mil,

Timeout

Sets a timeout for the connection attempt to the primary server, so the connection rolls over to the backup server. If the number of seconds indicated in this field (or the timeout on the LDAP server) elapses without a response from the primary authentication server, the appliance then queries the backup server.

However, if LDAP is running on the port of the primary LDAP server and for some reason refuses to service the request, the failover to the backup server does not occur.

If the primary server has LDAP disabled, the appliance queries the backup server.

UI Access Attribute

Tells the local appliance to match the value of a specific attribute rather than the value of the user distinguished name. You can use any attribute, if the value of the attribute is a valid user name for the FireSIGHT System web interface. If one of the objects has a matching user name and password, the user login request is authenticated.

Selecting a server type and setting defaults prepopulates the UI Access Attribute with a value typically appropriate for that type of server.

If you leave this field blank, the local appliance checks the user distinguished name value for each user record on the LDAP server to see if it matches the user name.

If you want to use this object for CAC authentication and authorization, you must enter a value that corresponds with your User Name Template value. For more information, see Understanding LDAP Authentication With CAC.

sAMAccountName,

userPrincipalName,

mail

Shell Access Attribute

If you want to check a specific attribute for shell access credentials, you must explicitly set this field to match the attribute. You can use any attribute if the value of the attribute is a valid user name for shell access.

If you leave this field blank, the user distinguished name is used for shell access authentication.

Note that selecting a server type and setting defaults prepopulates this field with an attribute typically appropriate for that type of server.

sAMAccountName

To configure the LDAP-specific parameters for a server:

Access: Admin

Step 1 In the LDAP-Specific Parameters section of the Create External Authentication Object page, you have two options for setting the base DN:

- To fetch a list of all available domains, click Fetch DNs and select the appropriate base domain name from the drop-down list.

- Type the base distinguished name for the LDAP directory you want to access in the Base DN field.

For example, to authenticate names in the Security organization at the Example company, type or select ou=security,dc=example,dc=com.

Step 2 Optionally, to set a filter that retrieves only specific objects within the directory you specified as the Base DN, type the attribute type, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Base Filter field.

For example, if the user objects in a directory tree have a physicalDeliveryOfficeName attribute and users in the New York office have an attribute value of NewYork for that attribute, to retrieve only users in the New York office, type (physicalDeliveryOfficeName=NewYork).

Step 3 Type the distinguished name and password for the user whose credentials should be used to validate access to the LDAP directory in the User Name and Password fields.

For example, if you are connecting to an OpenLDAP server where user objects have a uid attribute and the object for the administrator in the Security division at our example company has a uid value of NetworkAdmin, you might type uid=NetworkAdmin,ou=security,dc=example,dc=com.

Caution If you are connecting to a Microsoft Active Directory Server, you cannot provide a server user name that ends with the $ character.

Step 4 Retype the password in the Confirm Password field.

Step 5 After you configure the basic LDAP-specific parameters, you have several options:

- To access advanced options, click the arrow next to Show Advanced Options and continue with the next step.

- If you want to configure user default roles based on LDAP group membership, continue with Configuring Access Rights by Group.

- If you are not using LDAP groups for authentication, continue with Configuring Shell Access.

Step 6 Optionally, select one of the following encryption modes:

- To connect using Secure Sockets Layer (SSL), select SSL .

- To connect using Transport Layer Security (TLS), select TLS .

- To connect without encryption, select None .

Note Note that if you change the encryption method after specifying a port, you reset the port to the default value for that method. For none or TLS, the port uses the default value of 389. If you select SSL encryption, the port uses the default of 636.

Step 7 If you selected TLS or SSL encryption and you want to use a certificate to authenticate, click Browse to browse to the location of a valid TLS or SSL certificate or, in the SSL Certificate Upload Path field, type the path to the certificate.

A message appears, indicating a successful certificate upload.

Note If you previously uploaded a certificate and want to replace it, upload the new certificate and reapply the system policy to your appliances to copy over the new certificate.

Step 8 Optionally, in the User Name Template field, type the string conversion character (%s) used to determine the user name from the value found in the UI Access Attribute.

For example, to authenticate all users who work in the Security organization of our example company by connecting to an OpenLDAP server where the shell access attribute is uid, you might type uid=%s,ou=security,dc=example,dc=com in the User Name Template field. For a Microsoft Active Directory server, you could type %s@security.example.com.

If you want to use CAC credentials for authentication and authorization, you must enter a value in the User Name Template field. For more information, see Understanding LDAP Authentication With CAC.

Step 9 Optionally, in the Timeout field, type the number of seconds that should elapse before rolling over to the backup connection.

Step 10 Optionally, to retrieve users based on an attribute instead of the Base DN and Base Filter, you have two options:

- Click Fetch Attrs to retrieve a list of available attributes and select the appropriate attribute.

- Type the attribute in the UI Access Attribute field.

For example, on a Microsoft Active Directory Server, you may want to use the UI Access Attribute to retrieve users, because there may not be a uid attribute on Active Directory Server user objects. Instead, you can search the userPrincipalName attribute by typing userPrincipalName in the UI Access Attribute field.

If you want to use CAC credentials for authentication and authorization, you must enter a value in the UI Access Attribute field. For more information, see Understanding LDAP Authentication With CAC.

Step 11 Optionally, to retrieve users for shell access, type the attribute to filter by in the Shell Access Attribute field.

For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute to retrieve shell access users by typing sAMAccountName in the Shell Access Attribute field.

Note You cannot configure CAC authentication and authorization and shell access in the same authentication object. Selecting the CAC check box disables the shell access configuration options on the page. Instead, create separate authentication objects and enable them separately in your system policy. For more information, see Enabling External Authentication.

Step 12 For the next step, you have three choices:

- If you want to configure user default roles based on LDAP group membership, continue with Configuring Access Rights by Group.

- If you are not using LDAP groups for authentication but you want to configure shell access, continue with Configuring Shell Access.

- If you are not using LDAP groups for authentication and you do not want to configure shell access, continue with Testing User Authentication.

Configuring Access Rights by Group

License: Any

If you prefer to base default access rights on a user’s membership in an LDAP group, you can specify distinguished names for existing groups on your LDAP server for each of the access roles used by your FireSIGHT System. When you do so, you can configure a default access setting for those users detected by LDAP that do not belong to any specified groups. When a user logs in, the FireSIGHT System dynamically checks the LDAP server and assigns default access rights according to the user’s current group membership.

If you plan to use an object for CAC authentication and authorization, Cisco recommends configuring LDAP groups to manage access role assignments for CAC-authenticated users. For more information, see Managing CAC Authentication and Authorization.

Any group you reference must exist on the LDAP server. You can reference static LDAP groups or dynamic LDAP groups. Static LDAP groups are groups where membership is determined by group object attributes that point to specific users, and dynamic LDAP groups are groups where membership is determined by creating an LDAP search that retrieves group users based on user object attributes. Group access rights for a role only affect users who are members of the group.

The access rights granted when a user logs into the FireSIGHT System depend on the LDAP configuration:

- If no group access rights are configured for your LDAP server, when a new user logs in, the FireSIGHT System authenticates the user against the LDAP server and then grants user rights based on the default minimum access role set in the system policy.

- If you configure any group settings, new users belonging to specified groups inherit the minimum access setting for the groups where they are members.

- If a new user does not belong to any specified groups, the user is assigned the default minimum access role specified in the Group Controlled Access Roles section of the authentication object.

- If a user belongs to more than one configured group, the user receives the access role for the group with the highest access as a minimum access role.

You cannot use the FireSIGHT System user management page to remove the minimum access rights for users assigned an access role because of LDAP group membership. You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of External - Locally Modified.

Note If you use a dynamic group, the LDAP query is used exactly as it is configured on the LDAP server. For this reason, the FireSIGHT System limits the number of recursions of a search to four to prevent search syntax errors from causing infinite loops. If a user’s group membership is not established in those recursions, the default access role defined in the Group Controlled Access Roles section is granted to the user.

To configure default roles based on group membership:

Access: Admin

Step 1 On the Create External Authentication Object page, click the down arrow next to Group Controlled Access Roles.

The section expands.

Step 2 Optionally, configure access defaults by group membership.

In the DN fields that correspond to FireSIGHT System user roles, type the distinguished name for the LDAP groups that contain users who should be assigned to those roles.

For example, you might type the following in the Administrator field to authenticate names in the information technology organization at the Example company:

cn=itgroup,ou=groups, dc=example,dc=com

For more information on user access roles, see Adding New User Accounts.

Step 3 From the Default User Role list, select the default minimum access role for users that do not belong to any of the specified groups.

Tip Press the Ctrl key while clicking role names to select multiple roles.

Step 4 If you used static groups, in the Group Member Attribute field, type the LDAP attribute that designates membership in a static group.

For example, if the member attribute is used to indicate membership in the static group you reference for default Security Analyst access, type member.

Step 5 If you used dynamic groups, in the Group Member URL Attribute field, type the LDAP attribute that contains the LDAP search string used to determine membership in a dynamic group.

For example, if the memberURL attribute contains the LDAP search that retrieves members for the dynamic group you specified for default Admin access, type memberURL.

Step 6 Continue with Configuring Shell Access.

Configuring Shell Access

License: Any

You can also use the LDAP server to authenticate accounts for shell access on your managed device or Defense Center. Specify a search filter that retrieves entries for users you want to grant shell access.

You cannot configure CAC authentication and authorization and shell access in the same authentication object. Instead, create separate authentication objects and enable them separately in your system policy. The authentication object for shell access must be the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.

Note Cisco does not support external authentication for virtual devices or Cisco NGIPS for Blue Coat X-Series. In addition, IPv6 is not supported for shell access authentication.

With the exception of the admin account, shell access is controlled entirely though the shell access attribute you set. The shell access filter you set determines which set of users on the LDAP server can log into the shell.

Note that a home directory for each shell user is created on login, and when an LDAP shell access user account is disabled (by disabling the LDAP connection), the directory remains, but the user shell is set to /bin/false in /etc/password to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.

The Same as Base Filter check box allows you to search more efficiently if all users qualified in the base DN are also qualified for shell access privileges. Normally, the LDAP query to retrieve users combines the base filter with the shell access filter. If the shell access filter was the same as the base filter, the same query runs twice, which is unnecessarily time-consuming. You can use the Same as Base Filter option to run the query only once for both purposes.

Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.

Caution On Series 3 Defense Centers, all shell users have sudoers privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the Configuration level of command line access, which also grants sudoers privileges.

To configure shell account authentication:

Access: Admin

Step 1 Optionally, on the Create External Authentication Object page, set a shell access account filter. You have multiple options:

- To retrieve administrative user entries based on attribute value, type the attribute name, a comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses, in the Shell Access Filter field.

- To use the same filter you specified when configuring authentication settings, select Same as Base Filter .

- To prevent LDAP authentication of shell access, leave the field blank. If you choose not to specify a shell access filter, a warning displays when you save the authentication object to confirm that you meant to leave the filter blank.

For example, if all network administrators have a manager attribute which has an attribute value of shell, you can set a base filter of (manager=shell).

Step 2 Continue with Testing User Authentication.

Testing User Authentication

License: Any

After you configure LDAP server and authentication settings, you can specify user credentials for a user who should be able to authenticate to test those settings.

For the user name, you can enter the value for the uid attribute for the user you want to test with. If you are connecting to a Microsoft Active Directory Server and supplied a shell access attribute in place of uid, use the value for that attribute as the user name. You can also specify a fully qualified distinguished name for the user.

The test output lists valid and invalid user names. Valid user names are unique, and can include underscores (_), periods (.), and hyphens (-), but otherwise only alphanumeric characters are supported. Invalid user names are user names containing other non-alphanumeric characters, such as spaces.

Note that testing the connection to servers with more than 1000 users only returns 1000 users because of web interface page size limitations.

Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct. Test the server configuration without the additional test parameters first. If that succeeds supply a user name and password to test with the specific user.

To test user authentication:

Access: Admin

Step 1 In the User Name and Password fields, type the uid value or shell access attribute value and password for the user whose credentials should be used to validate access to the LDAP server.

For example, to test to see if you can retrieve the JSmith user credentials at the Example company, type JSmith.

Step 2 Click Test.

A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. You have two options:

- If the test succeeds, the test output appears at the bottom of the page. Click Save . The External Authentication page appears, with the new object listed.

To enable LDAP authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.

- If the test fails, see Tuning Your Basic LDAP Authentication Connection for suggestions for troubleshooting the connection. Note that the error message that appears indicates what caused the connection to fail.

LDAP Authentication Object Examples

License: Any

The following sections provide an example of LDAP configuration using basic settings and an example using more advanced configuration options:

- Example: Basic LDAP Configuration

- Example: Advanced LDAP Configuration

Example: Basic LDAP Configuration

License: Any

The following figures illustrate a basic configuration of an LDAP login authentication object for a Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4. The connection uses port 389 for access.

However, because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to store user names rather than the uid attribute. Selecting the MS Active Directory server type and clicking Set Defaults sets the UI Access Attribute to sAMAccountName. As a result, the FireSIGHT System checks the sAMAccountName attribute for each object for matching user names when a user attempts to log into the FireSIGHT System.

In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to be checked for all objects in the directory for matches when a user logs into a shell account on the appliance.

Note that because no base filter is applied to this server, the FireSIGHT System checks attributes for all objects in the directory indicated by the base distinguished name. Connections to the server time out after the default time period (or the timeout period set on the LDAP server).

Example: Advanced LDAP Configuration

License: Any

The connection to the server is encrypted using SSL and a certificate named certificate.pem is used for the connection. In addition, connections to the server time out after 60 seconds because of the Timeout setting.

Because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to store user names rather than the uid attribute. Note that the configuration includes a UI Access Attribute of sAMAccountName. As a result, the FireSIGHT System checks the sAMAccountName attribute for each object for matching user names when a user attempts to log into the FireSIGHT System.

In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to be checked for all objects in the directory for matches when a user logs into a shell account on the appliance.

This example also has group settings in place. The Maintenance User role is automatically assigned to all members of the group with a member group attribute and the base domain name of CN=SFmaintenance,DC=it,DC=example,DC=com.

Editing LDAP Authentication Objects

License: Any

You can edit an existing authentication object. Your changes do not take effect until you reapply the policy.

To edit an authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

) next to the object you want to edit.

The Create External Authentication Object page appears.

Step 4 Modify the object settings as needed.

Step 5 Click Test.

A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected. If the test succeeds, the test output appears at the bottom of the page.

If the test fails, see Tuning Your Basic LDAP Authentication Connection for suggestions for troubleshooting the connection. Note that the error message that appears indicates what caused the connection to fail.

Step 6 Click Save.

Your changes are saved and the External Authentication page appears. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.

RADIUS Authentication

The Remote Authentication Dial In User Service (RADIUS) is an authentication protocol used to authenticate, authorize, and account for user access to network resources. You can create an authentication object for any RADIUS server that conforms to RFC 2865.

See the following sections for more information:

- Understanding RADIUS Authentication

- Creating RADIUS Authentication Objects

- Configuring RADIUS Connection Settings

- Configuring RADIUS User Roles

- Configuring Administrative Shell Access

- Defining Custom RADIUS Attributes

Understanding RADIUS Authentication

License: Any

When a user authenticated on a RADIUS server logs in for the first time, the user receives the roles specified for that user in the authentication object. If the user is not listed for any of the user roles, they receive the default access role you selected in the authentication object. If no default access role is selected in the authentication object, they receive the default access role from the system policy. You can modify a user’s roles, if needed, unless the settings are granted through the user lists in the authentication object. Note that when a user authenticated on a RADIUS server using attribute matching attempts to log in for the first time, the login is rejected as the user account is created. The user must log in a second time.

Note Before enabling external authentication on Series 3 managed devices, remove any internally-authenticated shell users that have the same user name as externally-authenticated users included in your shell access filter.

The FireSIGHT System implementation of RADIUS supports the use of SecurID® tokens. When you configure authentication by a server using SecurID, users authenticated against that server append the SecurID token to the end of their SecurID PIN and use that as their password when they log into a Cisco appliance. As long as SecurID is configured correctly to authenticate users outside the FireSIGHT System, those users can log into a FireSIGHT System appliance using their PIN plus the SecurID token without any additional configuration on the appliance.

Creating RADIUS Authentication Objects

License: Any

When you create a RADIUS authentication object, you define settings that let you connect to an authentication server. You also grant user roles to specific and default users. If your RADIUS server returns custom attributes for any users you plan to authenticate, you must define those custom attributes. Optionally, you can also configure shell access authentication.

Note that to create an authentication object, you need TCP/IP access from your local appliance to the authentication server where you want to connect.

To create an authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

Step 3 Click Create External Authentication Object.

The Create External Authentication Object page appears.

Step 4 Identify the primary and backup authentication servers where you want to retrieve user data for external authentication and set timeout and retry values. For more information, see Configuring RADIUS Connection Settings.

Step 5 Set the default user role. Optionally, specify the users or user attribute values for users that you want to receive specific FireSIGHT System access roles. For more information, see Configuring RADIUS User Roles.

Step 6 Optionally, configure administrative shell access. For more information, see Configuring Administrative Shell Access.

Step 7 If the profiles for any of the users to authenticate return custom RADIUS attributes, define those attributes. For more information, see Defining Custom RADIUS Attributes.

Step 8 Test your configuration by entering the name and password for a user who should successfully authenticate. For more information, see Testing User Authentication.

Your changes are saved. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.

Configuring RADIUS Connection Settings

License: Any

When you create a RADIUS authentication object, you first specify the primary and backup server and server port where you want the local appliance (managed device or Defense Center) to connect for authentication.

Note For RADIUS to function correctly, you must open its authentication and accounting ports (by default, 1812 and 1813) on your firewall.

If you specify a backup authentication server, you can set a timeout for the connection attempt to the primary server. If the number of seconds indicated in the Timeout field (or the timeout on the LDAP server) elapses without a response from the primary authentication server, the appliance then re-queries the primary server.

After the appliance re-queries the primary authentication server the number of times indicated by the Retries field and the number of seconds indicated in the Timeout field again elapses without a response from the primary authentication server, the appliance then rolls over to the backup server.

If, for example, the primary server has RADIUS disabled, the appliance queries the backup server. If RADIUS is running on the port of the primary RADIUS server and for some reason refuses to service the request (due to misconfiguration or other issues), however, the failover to the backup server does not occur.

To identify a RADIUS authentication server:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

Step 3 Click Create External Authentication Object.

The Create External Authentication Object page appears.

Step 4 Select RADIUS from the Authentication Method drop-down list.

RADIUS configuration options appear.

Step 5 Type a name and description for the authentication server in the Name and Description fields.

Step 6 Type the IP address or host name for the primary RADIUS server where you want to obtain authentication data in the Primary Server Host Name/IP Address field.

Note IPv6 addresses are not supported for shell authentication. To allow shell authentication when using an IPv6 address for your primary RADIUS server, set up an authentication object using an IPv4 address for the server and use that IPv4 object as the first authentication object in your system policy.

Step 7 Optionally, modify the port used by the primary RADIUS authentication server in the Primary Server Port field.

Note If your authentication port and accounting port numbers are not sequential, leave this field blank. The system then determines RADIUS port numbers from the radius and radacct data in your appliance’s /etc/services file.

Step 8 Type the secret key for the primary RADIUS authentication server in the RADIUS Secret Key field.

Step 9 Type the IP address or host name for the backup RADIUS authentication server where you want to obtain authentication data in the Backup Server Host Name/IP Address field.

Step 10 Optionally, modify the port used by the backup RADIUS authentication server in the Backup Server Port field.

Note If your authentication port and accounting port numbers are not sequential, leave this field blank. The system then determines RADIUS port numbers from the radius and radacct data in your appliance’s /etc/services file.

Step 11 Type the secret key for the backup RADIUS authentication server in the RADIUS Secret Key field.

Step 12 Type the number of seconds that should elapse before retrying the connection in the Timeout field.

Step 13 Type the number of times the primary server connection should be tried before rolling over to the backup connection in the Retries field.

Step 14 Continue with Configuring RADIUS User Roles.

Configuring RADIUS User Roles

License: Any

You can specify the access roles for existing users on your RADIUS server by listing the user names for each of the access roles used by your FireSIGHT System. When you do so, you can also configure a default access setting for those users detected by RADIUS that are not specified for a particular role.

When a user logs in, the FireSIGHT System checks the RADIUS server and grants access rights depending on the RADIUS configuration:

- If specific access rights are not configured for a user and a default access role is not selected, when a new user logs in, the FireSIGHT System authenticates the user against the RADIUS server and then grants user rights based on the default access role (or roles) set in the system policy.

- If a new user is not specified on any lists and default access roles are selected in the Default User Role list of the authentication object, the user is assigned those access roles.

- If you add a user to the list for one or more specific role, that user receives all assigned access roles.

You can also use attribute-value pairs, rather than user names, to identify users who should receive a particular user role. For example, if you know all users who should be Security Analysts have the value Analyst for their User-Category attribute, you can type User-Category=Analyst in the Security Analyst List field to grant that role to those users. Note that you need to define any custom attributes before you use them to set user role membership. For more information, see Defining Custom RADIUS Attributes.

You can assign a default user role (or roles) to be assigned to any users that are authenticated externally but not listed for a specific role. You can select multiple roles on the Default User Role list.

For more information on the user roles supported by the FireSIGHT System, see Configuring RADIUS User Roles.

You cannot remove the minimum access rights for users assigned an access role because of RADIUS user list membership through the FireSIGHT System user management page. You can, however, assign additional rights.

Caution If you want to change the minimum access setting for a user, you must not only move the user from one list to another in the RADIUS Specific Parameters section or change the user’s attribute on the RADIUS server, you must reapply the system policy, and you must remove the assigned user right on the user management page.

To base access on user lists:

Access: Admin

Step 1 In the fields that correspond to FireSIGHT System user roles, type the name of each user or identifying attribute-value pair that should be assigned to those roles. Separate usernames and attribute-value pairs with commas.

For example, to grant the Administrator role to the users jsmith and jdoe, type jsmith, jdoe in the Administrator field.

As another example, to grant the Maintenance User role to all users with a User-Category value of Maintenance, type User-Category=Maintenance in the Maintenance User field.

For more information on user access roles, see Configuring User Roles.

Step 2 Select the default minimum access role for users that do not belong to any of the specified groups from the Default User Role list.

Tip Press the Ctrl key while clicking role names to select multiple roles.

Step 3 Continue with Configuring Administrative Shell Access.

Configuring Administrative Shell Access

License: Any

You can also use the RADIUS server to authenticate accounts for shell access on your local appliance (managed device or Defense Center). Specify user names for users you want to grant shell access. Note that you can only configure shell access for the first authentication object in your system policy. For more information on managing authentication object order, see Enabling External Authentication.

Note IPv6 addresses are not supported for shell authentication. If you configure a primary RADIUS server with an IPv6 address and also configure administrative shell access, the shell access settings are ignored. To allow shell authentication when using an IPv6 address for your primary RADIUS server, set up another authentication object using an IPv4 address for the server and use that object as the first authentication object in your system policy.

With the exception of the admin account, the shell access list you set on the RADIUS authentication object entirely controls shell access on the appliance. Shell users are configured as local users on the appliance when the system policy is applied. Note that when a user authenticated on a RADIUS server using attribute matching attempts to log in for the first time, the login is rejected as the user account is created. The user must log in a second time.

Note that a home directory for each shell user is created on login, and when an RADIUS shell access user account is disabled (by disabling the RADIUS connection), the directory remains, but the user shell is set to /bin/false in /etc/password to disable the shell. If the user then is re-enabled, the shell is reset, using the same home directory.

Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.

Caution On Series 3 Defense Centers, all shell users have sudoers privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the Configuration level of command line access, which also grants sudoers privileges.

To configure shell account authentication:

Access: Admin

Step 1 Type the user names, separated by commas, in the Administrator Shell Access User List field.

Note If you choose not to specify a shell access filter, a warning displays when you save the authentication object to confirm that you meant to leave the filter blank.

Step 2 Continue with Defining Custom RADIUS Attributes.

Defining Custom RADIUS Attributes

License: Any

If your RADIUS server returns values for attributes not included in the dictionary file in /etc/radiusclient/ and you plan to use those attributes to set user roles for users with those attributes, you need to define those attributes in the login authentication object.

You can locate the attributes returned for a user by looking at the user’s profile on your RADIUS server.

When you define an attribute, you provide the name of the attribute, which consists of alphanumeric characters. Note that words in an attribute name should be separated by dashes rather than spaces. You also provide the attribute ID, which should be an integer and should not conflict with any existing attribute IDs in the etc/radiusclient/dictionary file. You also specify the type of attribute: string, IP address, integer, or date.

As an example, if a RADIUS server is used on a network with a Cisco router, you might want to use the Ascend-Assign-IP-Pool attribute to grant a specific role to all users logging in from a specific IP address pool. Ascend-Assign-IP-Pool is an integer attribute that defines the address pool where the user is allowed to log in, with the integer indicating the number of the assigned IP address pool. To declare that custom attribute, you create a custom attribute with an attribute name of Ascend-IP-Pool-Definition, an attribute ID of 218, and an attribute type of integer. You could then type Ascend-Assign-IP-Pool=2 in the Security Analyst (Read Only) field to grant read-only security analyst rights to all users with an Ascend-IP-Pool-Definition attribute value of 2.

When you create a RADIUS authentication object, a new dictionary file for that object is created on the FireSIGHT System appliance in the /var/sf/userauth directory. Any custom attributes you add to the authentication object are added to the dictionary file.

To define a custom attribute:

Access: Admin

Step 1 Click the arrow to expand the Define Custom RADIUS Attributes section.

The attribute fields appear.

Step 2 Type an attribute name consisting of alphanumeric characters and dashes, with no spaces, in the Attribute Name field.

Step 3 Type the attribute ID, in integer form, in the Attribute ID field.

Step 4 Select the type of attribute from the Attribute Type drop-down list.

Step 5 Click Add to add the custom attribute to the authentication object.

Tip You can remove a custom attribute from an authentication object by clicking Delete next to the attribute.

Step 6 Continue with Testing User Authentication.

Testing User Authentication

License: Any

After you configure RADIUS connection, user role, and custom attribute settings, you can specify user credentials for a user who should be able to authenticate to test those settings.

For the user name, you can enter the user name for the user you want to test with.

Note that testing the connection to servers with more than 1000 users only returns 1000 users because of UI page size limitations.

Tip If you mistype the name or password of the test user, the test fails even if the server configuration is correct. To verify that the server configuration is correct, click Test without entering user information in the Additional Test Parameters field first. If that succeeds, supply a user name and password to test with the specific user.

To test user authentication:

Access: Admin

Step 1 In the User Name and Password fields, type the user name and password for the user whose credentials should be used to validate access to the RADIUS server.

For example, to test to see if you can retrieve the jsmith user credentials at our example company, type jsmith.

Step 2 Select Show Details and click Test.

A message appears, either indicating success of the test or detailing what settings are missing or need to be corrected.

Step 3 If the test succeeds, click Save.

The External Authentication page appears, with the new object listed.

To enable RADIUS authentication using the object on an appliance, you must apply a system policy with that object enabled to the appliance. For more information, see Enabling External Authentication and Applying a System Policy.

RADIUS Authentication Object Examples

License: Any

This section provides examples of RADIUS server authentication objects to show how FireSIGHT System RADIUS authentication features can be used. See the following sections for more information:

- Example: Authenticating a User Using RADIUS

- Example: Authenticating a User with Custom Attributes

Example: Authenticating a User Using RADIUS

License: Any

The following figure illustrates a sample RADIUS login authentication object for a server running FreeRADIUS with an IP address of 10.10.10.98. Note that the connection uses port 1812 for access, and note that connections to the server time out after 30 seconds of disuse, then retry three times before attempting to connect to a backup authentication server.

This example illustrates important aspects of RADIUS user role configuration:

- Users ewharton and gsand are granted administrative access to FireSIGHT System appliances where this authentication object is enabled.

- The user cbronte is granted Maintenance User access to FireSIGHT System appliances where this authentication object is enabled.

- The user jausten is granted Security Analyst access to FireSIGHT System appliances where this authentication object is enabled.

- The user ewharton can log into the appliance using a shell account.

The following graphic depicts the role configuration for the example:

Example: Authenticating a User with Custom Attributes

License: Any

You can use an attribute-value pair to identify users who should receive a particular user role. If the attribute you use is a custom attribute, you must define the custom attribute.

The following figure illustrates the role configuration and custom attribute definition in a sample RADIUS login authentication object for the same FreeRADIUS server as in the previous example.

In this example, however, the MS-RAS-Version custom attribute is returned for one or more of the users because a Microsoft remote access server is in use. Note the MS-RAS-Version custom attribute is a string. In this example, all users logging in to RADIUS through a Microsoft v. 5.00 remote access server should receive the Security Analyst (Read Only) role, so you type the attribute-value pair of MS-RAS-Version=MSRASV5.00 in the Security Analyst (Read Only) field.

Editing RADIUS Authentication Objects

License: Any

You can edit an existing authentication object. If the object is in use in a system policy, the settings in place at the time the policy was applied stay in effect until you reapply the policy.

To edit an authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

) next to the object you want to edit.

The Create External Authentication Object page appears.

Step 4 Modify the object settings as needed.

Step 5 Click Save.

Your changes are saved and the External Authentication page reappears. Remember that you must apply a system policy with the object enabled to an appliance before the authentication changes take place on that appliance. For more information, see Enabling External Authentication and Applying a System Policy.

Deleting Authentication Objects

License: Any

You can delete an authentication object if it is not currently enabled in a system policy.

To delete an authentication object:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the External Authentication tab.

The External Authentication page appears.

) next to the object you want to delete.

The object is deleted and the External Authentication page appears.

Managing User Accounts

License: Any

If you have Administrator access, you can use the web interface to view and manage user accounts on a Defense Center or a managed device, including adding, modifying, and deleting accounts. You can also create and modify custom user roles and configure user role escalation. User accounts without Administrator access are restricted from accessing management features. The navigation menu differs in appearance for each type of user.

See the following sections for more information about managing user accounts:

- Viewing User Accounts explains how to access the User Management page, where you can add, activate, deactivate, edit, and delete user accounts.

- Adding New User Accounts describes the different options you can use when you add a new user account.

- Managing Command Line Access describes how to assign command line interface access to local device users on Series 3 or virtual devices.

- Managing Externally Authenticated User Accounts explains how externally authenticated users are added and what aspects of the user configuration you can manage within the FireSIGHT System.

- Modifying User Privileges and Options explains how to access and modify an existing user account.

- Understanding Restricted User Access Properties explains how to restrict the data available to a user account with restricted data access.

- Deleting User Accounts explains how to delete user accounts.

- User Account Privileges contains tables that list the menus and options each type of user account can access.

Viewing User Accounts

License: Any

From the User Management page, you can view, edit, and delete existing accounts. You can view the type of authentication for a user from the Authentication Method column. The Password Lifetime column indicates the days remaining on each user’s password. The icons in the Action column allow you to edit users in more detail and set users active or inactive. Note that for externally authenticated users, if the authentication object for the server is disabled, the Authentication Method column displays External (Disabled).

To access the User Management page:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears, showing each user, with options to activate, deactivate, edit, or delete the user account.

See the following sections for information about the actions you can perform on the User Management page:

- Adding New User Accounts

- Configuring User Roles

- Modifying User Privileges and Options

- Understanding Restricted User Access Properties

- Modifying User Passwords

- Deleting User Accounts

Adding New User Accounts

License: Any

Supported Devices: feature dependent

When you set up a new user account, you can control which parts of the system the account can access. You can set password expiration and strength settings for the user account during creation. For a local account on a Series 3 device, you can also configure the level of command line access the user will have.

To add a new user:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click Create User.

The Create User page appears.

Step 3 In the User Name field, type a name for the new user.

New user names must contain alphanumeric or hyphen characters with no spaces, and must be no more than 32 characters. User names are case sensitive.

Step 4 If you want this user to authenticate to an external directory server on login, select Use External Authentication Method.

If you enable this option, the password management options disappear. Skip to step 8 to continue with configuring an access role for the user.

Note that for users to authenticate to an external directory server, you must use the Defense Center to create an authentication object for the server you want to use, then apply a system policy with authentication enabled. In addition, the external authentication server must be available in order for those users to log into FireSIGHT System appliances. For more information, see Managing Authentication Objects and Enabling External Authentication.

Step 5 In the Password and Confirm Password fields, type a password (up to 32 alphanumeric characters).

If you enable password strength checking, the password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character and one special character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.

Note If you enable STIG compliance on an appliance, see the FireSIGHT System STIG Release Notes for more information on password settings for shell access users.

Step 6 Configure the remaining user account login options.

For more information, see the User Account Login Options table.

Step 7 If you are creating a local user through the web interface of a Series 3 device, you can assign the level of Command-Line Interface Access for the user:

- Select None to disable access to the command line for the user.

- Select Basic to allow the user to log into the shell and to access a specific subset of commands.

- Select Configuration to allow the user to log into the shell and use any command line option, including expert mode if that is allowed on the appliance.

For more information on command line access, see Managing Command Line Access.

Step 8 Select access roles to grant to the user.

Note For all physical managed devices, the Cisco-provided predefined user roles are limited to Administrator, Maintenance User, and Security Analyst.

For more information, see Configuring User Roles.

Step 9 Click Save.

The user is created and the User Management page appears again.

Tip Click the slider next to the name of an internally authenticated user on the User Management page to reactivate a deactivated user, or to disable an active user account without deleting it.

Managing Command Line Access

License: Any

Supported Devices: Series 3, virtual

On a Series 3 or virtual device, you can assign command line interface access to local device users.

Note that you can also assign command line access for users on a virtual device, but you use commands from the command line interface. For more information, see Command Line Reference.

Table 61-3 Basic Command Line Commands

configure password

interfaces

end

lcd

exit

link-state

help

log-ips-connection

history

managers

logout

memory

?

model

??

mpls-depth

access-control-config

NAT

alarms

network

arp-tables

network-modules

audit-log

ntp

bypass

perfstats

clustering

portstats

cpu

power-supply-status

database

process-tree

device-settings

processes

disk

routing-table

disk-manager

serial-number

dns

stacking

expert

summary

fan-status

time

fastpath-rules

traffic-statistics

gui

version

hostname

virtual-routers

hyperthreading

virtual-switches

inline-sets

When you set Command-Line Interface Access to Configuration, the user can access any of the command line options. Exercise caution in assigning this level of access to users.

Caution Shell access granted to externally authenticated users defaults to the Configuration level of command line access, granting rights to all command line utilities. For more information on shell access for externally authenticated users, see Understanding Shell Access and Configuring Shell Access.

Managing Externally Authenticated User Accounts

License: Any

When an externally authenticated user logs into an appliance that has external authentication enabled, the appliance grants the user the default access role you set by specifying group membership in the authentication object. If you did not configure access group settings, the appliance grants the default user role you set in the system policy. However, if you add users locally before they log into the appliance, the user privileges you configure on the User Management page override the default settings.

For more information on selecting a default user role, see Enabling External Authentication and Understanding User Privileges. Note that you can set both predefined and custom user roles as the default user role for externally authenticated users. For more information, see Configuring User Roles.

An internally authenticated user is converted to external authentication when all of the following conditions exist:

- You enable LDAP (with or without CAC) or RADIUS authentication.

- The same user name exists for the user on the LDAP or RADIUS server.

- The user logs in using the password stored for that user on the LDAP or RADIUS server.

Note that you can only enable external authentication in a system policy on a Defense Center. You must use the Defense Center to apply the policy to managed devices if you want to use external authentication on them.

After an externally authenticated user logs in to an appliance for the first time, the appliance associates those credentials with a set of permissions by creating a local user record. For more information about user login, see Logging into the Appliance. After initial login, the permissions for that local user record can be modified unless they are granted through group or list membership, as follows:

- If the default role for externally authenticated user accounts is set to a specific access role, users can log into the appliance using their external account credentials without any additional configuration by the system administrator.

- If an account is externally authenticated and by default receives no access privileges, users can log in but cannot access any functionality. You (or your system administrator) can then change the permissions to grant the appropriate access to user functionality.

Tip The system does not create a local user account for shell access users. Shell access is controlled entirely through either the shell access filter or PAM login attribute set for an LDAP server, or the shell access list on a RADIUS server.

For more information on modifying user access, see Modifying User Privileges and Options. Note that you cannot manage passwords for externally authenticated users or deactivate externally authenticated users through the FireSIGHT System interface. For externally authenticated users, you cannot remove the minimum access rights through the FireSIGHT System user management page for users assigned an access role because of LDAP group or RADIUS list membership or attribute values. On the Edit User page for an externally authenticated user, rights granted because of settings on an external authentication server are marked with a status of Externally Modified.

You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of External - Locally Modified.

Shell users can log in using user names with lowercase letters. Login authentication for the shell is case sensitive.

Caution On Series 3 Defense Centers, all shell users have sudoers privileges. Make sure that you restrict the list of users with shell access appropriately. On Series 3 and virtual devices, shell access granted to externally authenticated users defaults to the Configuration level of command line access, which also grants sudoers privileges. For more information on setting up shell access, see Understanding Shell Access and Configuring Shell Access.

Managing User Login Settings

License: Any

You can control how and when the password for each user account is changed, as well as when user accounts are disabled. If you configured a timeout for web interface login sessions, you can exempt users from this timeout. The following table describes some of the options you can use to regulate passwords and account access.

Note that for locally authenticated users on Series 3 managed devices, changing a user’s password for the web interface also changes that password for the command line interface.

If you enable the Check Password Strength option, the minimum password length is automatically set to 8 characters. If you also set a value for Minimum Password Length that exceeds 8 characters, the higher value applies.

Note After you enable Use External Authentication Method, login options no longer appear. Use the external authentication server to manage login settings.

Table 61-4 User Account Login Options

Option

Description

Use External Authentication Method

Select this check box if you want this user's credentials to be externally authenticated.

Note If you select this option for the user and the external authentication server is unavailable, that user can log into the web interface but cannot access any functionality.

Maximum Number of Failed Logins

Enter an integer, without spaces, that determines the maximum number of times each user can try to log in after a failed login attempt before the account is locked. The default setting is five tries; use 0 to allow an unlimited number of failed logins.

Minimum Password Length

Enter an integer, without spaces, that determines the minimum required length, in characters, of a user’s password. The default setting is 8. A value of 0 indicates that no minimum length is required.

Days Until Password Expiration

Enter the number of days after which the user’s password expires. The default setting is 0, which indicates that the password never expires.

Days Before Password Expiration Warning

Enter the number of warning days users have to change their password before their password actually expires. The default setting is 0 days.

Caution The number of warning days must be less than the number of days before the password expires.

Force Password Reset on Login

Select this option to force users to change their passwords the first time they log in.

Check Password Strength

Select this option to require strong passwords. A strong password must be at least eight alphanumeric characters of mixed case and must include at least one numeric character and one special character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.

Exempt from Browser Session Timeout

Select this option if you do not want a user’s login sessions to terminate due to inactivity. Users with the Administrator role cannot be made exempt. For more information on session timeouts, see Configuring User Interface Settings.

Configuring User Roles

License: Any

Each FireSIGHT System user has an associated user access role or roles. For example, an analyst needs access to event data to analyze the security of your network, but might not require access to administrative functions for the FireSIGHT System itself. Using user roles, you can, for example, grant Security Analyst access to analysts while reserving the Administrator role for the user or users managing the FireSIGHT System. The FireSIGHT System includes ten predefined user roles designed for a variety of administrators and analysts. You can also create custom user roles with specialized access privileges.

The menus and other options in the web interface that users can access depend on their roles. Predefined user roles have a set of predetermined access privileges, while custom user roles have granular access privileges that their creator determines.

You configure user roles on the User Roles page.

To access the User Roles page:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the User Roles tab.

The User Roles page appears, showing all predefined and custom user roles, with options to activate, deactivate, edit, copy, delete, and export roles.

For more information on configuring the two types of user roles, see the following sections:

- Managing Predefined User Roles

- Managing Custom User Roles

- Creating a Custom Copy of a Predefined User Role

- Deleting a Custom User Role

Managing Predefined User Roles

License: Any

The FireSIGHT System includes ten predefined user roles that provide a range of access privilege sets to meet the needs of your organization. On the User Roles page, predefined user roles are labeled “Cisco Provided”. Note that managed devices have access to only three of the ten predefined user roles: Administrator, Maintenance User, and Security Analyst.

Although you cannot edit predefined user roles, you can use their access privilege sets as the basis for custom user roles. For information on creating and editing custom user roles, see Managing Custom User Roles. In addition, because you cannot edit predefined user roles, you cannot configure them to escalate to another user role. For more information, see Managing User Role Escalation.

The following table briefly describes the predefined roles available to you. For a list of the menus and options available to each role, see User Account Privileges.

Table 61-5 Predefined User Roles

User Role

Privileges

Access Admin

Provides access to access control, SSL inspection, and file policy features. Note, however, that Access Admins cannot apply access control policies. Access Admins have access to access control, SSL inspection, and file-related options in the Policies menu.

Administrator

Provides access to analysis and reporting features, rule and policy configuration, system management, and all maintenance features. Administrators have access to all menu options; their sessions present a higher security risk if compromised, so you cannot make them exempt from login session timeouts.

Note that you should limit use of the Administrator role for security reasons.

This role is also available on managed devices.

Discovery Admin

Provides access to network discovery, correlation, and user activity features. Discovery Admins have access to relevant options in the Policies menu.

External Database User

Provides read-only access to the FireSIGHT System database using an application that supports JDBC SSL connections. Note that for the third-party application to authenticate to the FireSIGHT System appliance, you must enable database access in the system settings as described in Enabling Access to the Database. On the web interface, External Database Users have access only to online help-related options in the Help menu. Because this role’s function does not involve the web interface, access is provided only for ease of support and password changes.

Intrusion Admin

Provides access to all intrusion policy, intrusion rule, and network analysis policy features. Intrusion Admins have access to intrusion-related options in the Policies menu. Note that Intrusion Admins cannot apply intrusion or network analysis policies as part of access control policies.

Maintenance User

Provides access to monitoring and maintenance features. Maintenance Users have access to maintenance-related options in the Health and System menus.

This role is also available on managed devices.

Network Admin

Provides access to access control, SSL inspection, and device configuration features. Network Admins have access to access control, SSL inspection, and device-related options in the Policies and Devices menus.

Security Analyst

Provides access to security event analysis features, including event views, reports, hosts, host attributes, services, vulnerabilities, client applications, and read-only access to health events. Security Analysts have access to analysis-related options in the Overview, Analysis, Health, and System menus.

This role is also available on managed devices.

Security Analyst (Read Only)

Provides read-only access to security event analysis features, including event views, reports, hosts, host attributes, services, vulnerabilities, client applications, and health events. Security Analysts have access to analysis-related options in the Overview, Analysis, Health, and System menus.

Security Approver

Provides limited access to access control, intrusion, file, SSL, and network discovery policies. Security Approvers can view these policies and apply network discovery, intrusion, and access control policies, but cannot make policy changes. They have access to applicable policy-related options in the Policies menu.

Along with assigning an event analyst role to a user, you can restrict that user’s deletion rights to only allow deletion of report profiles, searches, bookmarks, custom tables, and custom workflows created by that user. For more information, see Adding New User Accounts.

Note that externally authenticated users, if assigned no other roles, have minimum access rights based on the settings in LDAP or RADIUS authentication objects and in the system policy. You can assign additional rights to these users, but to remove or change minimum access rights, you must perform the following tasks:

- Move the user from one list to another in the authentication object or change the user's attribute value or group membership on the external authentication server.

- Reapply the system policy.

- Use the User Management page to remove the access from that user account.

You cannot delete predefined user roles, but you can deactivate them. Deactivating a role removes that role and all associated permissions from any user who is assigned that role.

Caution If a deactivated role is the only role assigned to a given user, that user can log in and access the User Preferences menu, but is otherwise unable to access the FireSIGHT System.

To activate or deactivate a user role:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the User Roles tab.

The User Roles page appears.

Step 3 Click the slider next to the user role you want to activate or deactivate.

Note If you deactivate, then reactivate, a role with Lights-Out Management while a user with that role is logged in, or restore a user or user role from a backup during that user’s login session, that user must log back into the web interface to regain access to IPMItool commands. For more information, see Using Lights-Out Management.

Managing Custom User Roles

License: Any

In addition to the predefined user roles, you can also create custom user roles with specialized access privileges. Custom user roles can have any set of menu-based and system permissions, and may be completely original or based on a predefined user role. Like predefined user roles, custom roles can serve as the default role for externally authenticated users. Unlike predefined roles, you can modify and delete custom roles.

Selectable permissions are hierarchical, and are based on the FireSIGHT System menu layout. Permissions are expandable if they have sub-pages or if they have more fine-grained permissions available beyond simple page access. In that case, the parent permission grants page view access and the children granular access to related features of that page. For example, the Correlation Events permission grants access to the Correlation Events page, while the Modify Correlation Events check box allows the user to edit and delete the information available on that page. Permissions that contain the word “Manage” grant the ability to edit and delete information that other users create.

Tip For pages or features not included in the menu structure, privileges are granted by parent or related pages. For example, the Modify Intrusion Policy privilege also allows you to modify network analysis policies.

You can apply restricted searches to a custom user role. These constrain the data a user may see in the event viewer. You can configure a restricted search by first creating a private saved search and selecting it from the “Restricted Search” drop-down menu under the appropriate menu-based permission. For more information, see Performing a Search.

When you configure a custom user role on a Defense Center, all menu-based permissions are available for you to grant. When you configure a custom user role on a managed device, only some permissions are available — those relevant to device functions. For more information on the menu-based permissions you can configure and their relationship with predefined user roles, see:

- Analysis Menu

- Policies Menu

- Devices Menu

- Object Manager

- Health Menu

- System Menu

- Help Menu

The selectable options under System Permissions allow you to create a user role that can make queries to the external database or escalate to the permissions of a target user role. For more information, see Enabling Access to the Database and Managing User Role Escalation.

Optionally, instead of creating a new custom user role, you can export a custom user role from another appliance, then import it onto your appliance. You can then edit the imported role to suit your needs before you apply it. For more information, see Exporting Configurations and Importing Configurations.

To create a custom user role:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the User Roles tab.

The User Roles page appears.

Step 3 Click Create User Role.

The User Role Editor page appears.

Step 4 In the Name field, type a name for the new user role.

You can use alphanumeric or hyphen characters, without spaces. Role names must be no more than 75 characters. User role names are case sensitive.

Step 5 Optionally, add a description for the new role in the Description field.

Role descriptions must be no more than 255 characters.

Step 6 Select permissions for the new role.

When you select an unselected permission, all of its children are selected, and the multi-value permissions choose the first value. If you clear a high-level permission, all of its children are cleared also. Selected permissions without all children selected appear in italic text.

Note that choosing to copy a predefined user role to use as the base for your custom role preselects the permissions associated with that predefined role. For more information on copying predefined user roles, see Creating a Custom Copy of a Predefined User Role.

The current escalation target role is listed beside the role escalation check box. If you select this check box, you can then choose to authenticate escalations either with the assigned user’s password or with the password of another specified user role. For more information, see Managing User Role Escalation.

Step 7 Click Save.

The custom user role is created and the User Roles page appears again.

Creating a Custom Copy of a Predefined User Role

License: Any

You can copy an existing role to use as the basis for a new custom role. This preselects the existing role’s permissions in the User Role Editor so you can model one role on another.

To create a custom copy of a predefined user role:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the User Roles tab.

The User Roles page appears.

) next to the user role you want to copy.

The User Role Editor page appears with the copied role’s permissions preselected.

Note that you can copy both custom and predefined user roles in this way.

Deleting a Custom User Role

License: Any

Unlike predefined user roles, you can delete custom roles that are no longer necessary. If you want to disable a custom role without removing it entirely, you can deactivate it instead; for more information, refer to the procedure in Managing Predefined User Roles. Note that you cannot delete your own user role or a role that is set as a default user role in the system policy. For more information, see Enabling External Authentication.

To delete a custom user role:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click the User Roles tab.

The User Roles page appears.

) next to the custom role you want to delete.

The custom role is deleted.

If a deleted role is the only role assigned to a given user, that user can log in and access the User Preferences menu, but is otherwise unable to access the FireSIGHT System.

Modifying User Privileges and Options

License: Any

After adding user accounts to the system, you can modify access privileges, account options, or passwords at any time. Note that password management options do not apply to users who authenticate to an external directory server. You manage those settings on the external server. However, you must configure access rights for all accounts, including those that are externally authenticated.

For externally authenticated users, you cannot remove the minimum access rights through the FireSIGHT System user management page for users assigned an access role because of LDAP group or RADIUS list membership or attribute values. You can, however, assign additional rights. When you modify the access rights for an externally authenticated user, the Authentication Method column on the User Management page provides a status of External - Locally Modified.

Note that if you change the authentication for a user from externally authenticated to internally authenticated, you must supply a new password for the user.

To modify user account privileges:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

) next to the user you want to modify.

The Edit User page appears.

Step 3 Modify the account or accounts as needed:

- See Managing Externally Authenticated User Accounts for a description of how users can be authenticated through external servers.

- See Managing User Login Settings for information on changing password settings for internally authenticated users.

- See Configuring User Roles for more information on configuring roles to grant access for FireSIGHT System functions.

Understanding Restricted User Access Properties

License: Any

You can restrict the data that a user role can view in the event viewer by applying a restricted search to that role. You can specify this information when creating or editing the role assigned to a user. To create a custom role with restricted access, you must choose the tables you want to restrict from the Menu Based Permissions list, then select private saved searches from the Restrictive Search drop-down lists. For more information, see Managing Custom User Roles.

Modifying User Passwords

License: Any

You can modify user passwords from the User Management page for internally authenticated users. Note that you must manage externally authenticated user passwords on the LDAP or RADIUS server.

Note If you enable STIG compliance or Lights-Out Management (LOM) on an appliance, different password restrictions apply. For more information on password settings for shell access users on systems with STIG compliance enabled, see the FireSIGHT System STIG Release Notes. For more information on password settings for the system password for LOM users, see Enabling Lights-Out Management User Access.

To change a user’s password:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

).

The Edit User page appears.

Step 3 In the Password field, type the new password (up to 32 alphanumeric characters).

Step 4 In the Confirm Password field, retype the new password.

If password strength checking is enabled for the user account, the password must have at least eight alphanumeric characters of mixed case, with at least one number and one special character. It cannot be a word that appears in a dictionary or contain consecutive repeating characters.

Step 5 Make any other changes you want to make to the user configuration:

- For more information on password options, see Managing User Login Settings.

- For more information on user roles, see Configuring User Roles.

Step 6 Click Save.

The password is changed and any other changes saved.

Deleting User Accounts

License: Any

You can delete user accounts from the system at any time, with the exception of the admin account, which cannot be deleted.

To delete a user account:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

). The account is deleted.

User Account Privileges

License: Any

The following sections provide a list of the configurable user permissions in the FireSIGHT System and the user roles that can access them. The permissions listed here follow the order of the Menu Based Permissions list that appears when you create a custom user role. Not all permissions are available on managed devices; permissions available only on the Defense Center are marked accordingly. For more information, see Managing Custom User Roles.

Note that because the DC500 Defense Center and Series 2 devices support restricted features sets, not all permissions are applicable to these appliances. See the Supported Access Control Capabilities by Device Model table for a summary of Series 2 appliance features.

For more information on the access notations used in the tables that follow and throughout this documentation, see Access Conventions. The following sections refer to the user role privileges associated with each main menu in the web-based interface:

- Overview Menu

- Analysis Menu

- Policies Menu

- Devices Menu

- FireAMP

- Devices Menu

- Health Menu

- System Menu

- Help Menu

Overview Menu

License: Any

The following table lists, in order, the user role privileges required to access each option in the Overview menu and whether the user role has access to the sub-permissions within. The Security Approver, Discovery Admin, Intrusion Admin, Access Admin, Network Admin, and External Database User roles have no permissions in the Overview menu.

Table 61-6 Overview Menu

Permission

Admin

Maint User

Security Analyst

Security Analyst (RO)

Dashboards

yes

yes

yes

yes

Manage Dashboards

yes

no

no

no

Appliance Information Widget

yes

yes

yes

yes

Appliance Status Widget (Defense Center only)

yes

yes

yes

yes

Correlation Events Widget

yes

no

yes

yes

Current Interface Status Widget

yes

yes

yes

yes

Current Sessions Widget

yes

no

no

no

Custom Analysis Widget (Defense Center only)

yes

no

yes

yes

Disk Usage Widget

yes

yes

yes

yes

Interface Traffic Widget

yes

yes

yes

yes

Intrusion Events Widget (Defense Center only)

yes

no

yes

yes

Network Correlation Widget (Defense Center only)

yes

no

yes

yes

Product Licensing Widget (Defense Center only)

yes

yes

no

no

Product Updates Widget

yes

yes

no

no

RSS Feed Widget

yes

yes

yes

yes

System Load Widget

yes

yes

yes

yes

System Time Widget

yes

yes

yes

yes

White List Events Widget (Defense Center only)

yes

no

yes

yes

Reporting (Defense Center only)

yes

no

yes

yes

Manage Report Templates (Defense Center only)

yes

no

yes

yes

Summary

yes

no

yes

yes

Intrusion Event Statistics (Defense Center only)

yes

no

yes

yes

Intrusion Event Performance

yes

no

no

no

Intrusion Event Graphs (Defense Center only)

yes

no

yes

yes

Discovery Statistics (Defense Center only)

yes

no

yes

yes

Discovery Performance (Defense Center only)

yes

no

no

no

Connection Summary (Defense Center only)

yes

no

yes

yes

Analysis Menu

License: Any

The following table lists, in order, the user role privileges required to access each option in the Analysis menu and whether the user role has access to the sub-permissions within. Permissions that appear multiple times under different headings will be listed on the table only where they first appear, except to indicate submenu headings. The Security Approver, Intrusion Admin, Access Admin, Network Admin, and External Database User roles have no permissions in the Analysis menu. The Analysis menu is only available on the Defense Center.

Table 61-7 Analysis Menu

Menu

Admin

Discovery Admin

Maint User

Security Analyst

Security Analyst (RO)

Application Statistics

yes

no

no

yes

yes

Geolocation Statistics

yes

no

no

yes

yes

User Statistics

yes

no

no

yes

yes

URL Category Statistics

yes

no

no

yes

yes

URL Reputation Statistics

yes

no

no

yes

yes

SSL Statistics

yes

no

no

yes

yes

Intrusion Event Statistics by Application

yes

no

no

yes

yes

Intrusion Event Statistics by User

yes

no

no

yes

yes

Security Intelligence Category Statistics

yes

no

no

yes

yes

File Storage Statistics by Disposition

yes

no

no

yes

yes

File Storage Statistics by Type

yes

no

no

yes

yes

Dynamic File Analysis Statistics

yes

no

no

yes

yes

Context Explorer

yes

no

no

yes

yes

Connection Events

yes

no

no

yes

yes

Modify Connection Events

yes

no

no

yes

no

Connection Summary Events

yes

no

no

yes

yes

Modify Connection Summary Events

yes

no

no

yes

no

Security Intelligence Events

yes

no

no

yes

yes

Modify Security Intelligence Events

yes

no

no

yes

no

Intrusion

yes

no

no

yes

yes

Intrusion Events

yes

no

no

yes

yes

Modify Intrusion Events

yes

no

no

yes

no

View Local Rules

yes

no

no

yes

yes

Reviewed Events

yes

no

no

yes

yes

Clipboard

yes

no

no

yes

yes

Incidents

yes

no

no

yes

yes

Files

yes

no

no

yes

yes

Malware Events

yes

no

no

yes

yes

Modify Malware Events

yes

no

no

yes

no

File Events

yes

no

no

yes

yes

Modify File Events

yes

no

no

yes

no

Captured Files

yes

no

no

yes

yes

Modify Captured Files

yes

no

no

yes

no

File Trajectory

yes

no

no

yes

yes

File Download

yes

no

no

yes

yes

Dynamic File Analysis

yes

no

no

yes

no

Hosts

yes

no

no

yes

yes

Network Map

yes

no

no

yes

yes

Hosts

yes

no

no

yes

yes

Modify Hosts

yes

no

no

yes

no

Indications of Compromise

yes

no

no

yes

yes

Modify Indications of Compromise

yes

no

no

yes

no

Servers

yes

no

no

yes

yes

Modify Servers

yes

no

no

yes

no

Vulnerabilities

yes

no

no

yes

yes

Modify Vulnerabilities

yes

no

no

yes

no

Host Attributes

yes

no

no

yes

yes

Modify Host Attributes

yes

no

no

yes

no

Applications

yes

no

no

yes

yes

Application Details

yes

no

no

yes

yes

Modify Application Details

yes

no

no

yes

no

Host Attribute Management

yes

no

no

no

no

Discovery Events

yes

no

no

yes

yes

Modify Discovery Events

yes

no

no

yes

no

Users

yes

yes

no

yes

yes

User Activity

yes

yes

no

yes

yes

Modify User Activity Events

yes

yes

no

yes

no

Users

yes

yes

no

yes

yes

Modify Users

yes

yes

no

yes

no

Vulnerabilities

yes

no

no

yes

yes

Third-party Vulnerabilities

yes

no

no

yes

yes

Modify Third-party Vulnerabilities

yes

no

no

yes

no

Correlation

yes

yes

no

yes

yes

Correlation Events

yes

yes

no

yes

yes

Modify Correlation Events

yes

yes

no

yes

no

White List Events

yes

yes

no

yes

yes

Modify White List Events

yes

yes

no

yes

no

White List Violations

yes

yes

no

yes

yes

Remediation Status

yes

yes

no

no

no

Modify Remediation Status

yes

yes

no

no

no

Custom

yes

no

no

yes

yes

Custom Workflows

yes

no

no

yes

yes

Manage Custom Workflows

yes

no

no

yes

yes

Custom Tables

yes

no

no

yes

yes

Manage Custom Tables

yes

no

no

yes

yes

Search

yes

no

yes

yes

yes

Manage Search

yes

no

no

no

no

Bookmarks

yes

no

no

yes

yes

Manage Bookmarks

yes

no

no

yes

yes

Policies Menu

License: Any

The following table lists, in order, the user role privileges required to access each option in the Policies menu and whether the user roles has access to the sub-permissions within. The External Database User, Maintenance User, Security Analyst, and Security Analyst (Read Only) roles have no permissions in the Policies menu. The Policies menu is only available on the Defense Center.

Note that the Intrusion Policy and Modify Intrusion Policy privileges also allow you to create and modify network analysis policies.

Table 61-8 Policies Menu

Menu

Access Admin

Admin

Discovery Admin

Intrusion Admin

Network Admin

Security Approver

Access Control

yes

yes

no

no

yes

yes

Access Control List

yes

yes

no

no

yes

yes

Modify Access Control Policy

yes

yes

no

no

yes

no

Modify Administrator Rules

yes

yes

no

no

yes

no

Modify Root Rules

yes

yes

no

no

yes

no

Apply Intrusion Policies

no

yes

no

no

no

yes

Apply Access Control Policies

no

yes

no

no

no

yes

Intrusion

yes

yes

no

yes

no

yes

Intrusion Policy

no

yes

no

yes

no

yes

Rule Editor

no

yes

no

yes

no

no

Email

no

yes

no

yes

no

no

Modify Intrusion Policy

no

yes

no

yes

no

no

File Policy

yes

yes

no

no

no

no

Modify File Policy

yes

yes

no

no

no

no

Network Discovery

no

yes

yes

no

no

yes

Custom Fingerprinting

no

yes

yes

no

no

no

Custom Topology

no

yes

yes

no

no

no

Modify Network Discovery

no

yes

yes

no

no

no

Apply Network Discovery

no

yes

no

no

no

yes

SSL

yes

yes

no

no

yes

yes

Modify SSL Policy

yes

yes

no

no

yes

no

Modify Administrator Rules

yes

yes

no

no

yes

no

Modify Root Rules

yes

yes

no

no

yes

no

Apply SSL Policy

no

yes

no

no

no

yes

Application Detectors

no

yes

yes

no

no

no

User 3rd Party Mappings

no

yes

yes

no

no

no

Custom Product Mappings

no

yes

yes

no

no

no

Users

no

yes

no

no

no

no

Correlation

no

yes

no

no

no

no

Policy Management

no

yes

no

no

no

no

Rule Management

no

yes

no

no

no

no

White List

no

yes

no

no

no

no

Traffic Profiles

no

yes

no

no

no

no

Actions

no

yes

yes

no

no

no

Alerts

no

yes

yes

no

no

no

Impact Flag Alerts

no

yes

yes

no

no

no

Discovery Event Alerts

no

yes

yes

no

no

no

Scanners

no

yes

yes

no

no

no

Scan Results

no

yes

yes

no

no

no

Modify Scan Results

no

yes

yes

no

no

no

Groups

no

yes

no

no

no

no

Modules

no

yes

no

no

no

no

Instances

no

yes

no

no

no

no

Devices Menu

License: Any

The Devices menu table lists, in order, the user role privileges required to access each option in the Devices menu and the sub-permissions within. An X indicates that the user role has access. The Access Admin, Discovery Admin, External Database User, Intrusion Admin, Maintenance User, Security Approver, Security Analyst, and Security Analyst (Read Only) have no permissions in the Devices menu. The Devices menu is only available on the Defense Center.

Table 61-9 Devices Menu

Menu

Admin

Network Admin

Device Management

yes

yes

Modify Devices

yes

yes

Apply Device Changes

yes

yes

NAT

yes

yes

NAT List

yes

yes

Modify NAT Policy

yes

yes

Apply NAT Rules

yes

no

VPN

yes

yes

Modify VPN

yes

yes

Apply VPN Changes

yes

yes

Object Manager

License: Any

The Object Manager permission is available to the Access Admin, Administrator, and Network Admin user roles. The Object Manager permission is only available on the Defense Center.

FireAMP

License: Any

The FireAMP permission is available only to the Administrator user role. This permission is only available on the Defense Center.

Health Menu

License: Any

Table 61-10 Health Menu

Menu

Admin

Maint User

Security Analyst

Security Analyst (RO)

Health Policy

yes

yes

no

no

Modify Health Policy

yes

yes

no

no

Apply Health Policy

yes

yes

no

no

Health Events

yes

yes

yes

yes

Modify Health Events

yes

yes

no

no

System Menu

License: Any

The following table lists, in order, the user role privileges required to access each option in the System menu and whether the user role has access to the sub-permissions within. The Access Admin, Discovery Admin, Intrusion Admin, External Database User, and Security Analyst (Read Only) roles have no permissions in the System Menu.

Table 61-11 System Menu

Menu

Admin

Maint User

Network Admin

Security Approver

Security Analyst

Local

yes

no

no

no

no

Configuration

yes

no

no

no

no

Registration

yes

no

no

no

no

High Availability (DC1000, DC1500, DC2000, DC3000, DC3500, DC4000 only)

yes

no

no

no

no

eStreamer

yes

no

no

no

no

Host Input Client (Defense Center only)

yes

no

no

no

no

User Management

yes

no

no

no

no

Users

yes

no

no

no

no

User Roles

yes

no

no

no

no

Login Authentication (Defense Center only)

yes

no

no

no

no

System Policy (Defense Center only)

yes

no

no

no

no

Apply System Policy (Defense Center only)

yes

no

no

no

no

Modify System Policy (Defense Center only)

yes

no

no

no

no

Updates

yes

no

no

no

no

Rule Updates (Defense Center only)

yes

no

no

no

no

Rule Update Import Log (Defense Center only)

yes

no

no

no

no

Licenses

yes

no

no

no

no

Monitoring

yes

yes

yes

yes

yes

Audit

yes

no

no

no

no

Modify Audit Log

yes

no

no

no

no

Syslog

yes

yes

no

no

no

Task Status

yes

yes

yes

yes

yes

View Other Users’ Tasks

yes

no

no

no

no

Statistics

yes

yes

no

no

no

Tools

yes

yes

no

no

yes

Backup Management

yes

yes

no

no

no

Restore Backup

yes

yes

no

no

no

Scheduling

yes

yes

no

no

no

Delete Other Users’ Scheduled Tasks

yes

no

no

no

no

Import/Export

yes

no

no

no

no

Discovery Data Purge (Defense Center only)

yes

no

no

no

yes

Whois

yes

yes

no

no

yes

Help Menu

License: Any

The Help menu and its permissions are accessible to all user roles. You cannot restrict Help menu options.

Managing User Role Escalation

License: Any

You can give custom user roles the permission, with a password, to temporarily gain the privileges of another, targeted user role in addition to those of the base role. This allows you to easily substitute one user for another during an absence, or to more closely track the use of advanced user privileges.

For example, a user whose base role has very limited privileges may escalate to the Administrator role to perform administrative actions. You can configure this feature so that users can use their own passwords, or so they use the password of another user that you specify. The second option allows you to easily manage one escalation password for all applicable users. For more information, see Configuring a Custom User Role for Escalation.

Note that only one user role at a time can be the escalation target role. You can use a custom or predefined user role. Each escalation lasts for the duration of a login session and is recorded in the audit log.

For more information on configuring and using this feature, please see the following sections:

- Configuring the Escalation Target Role

- Configuring a Custom User Role for Escalation

- Escalating Your User Role

Configuring the Escalation Target Role

License: Any

You can assign any of your user roles, predefined or custom, to act as the system-wide escalation target role. This is the role to which any other role may escalate, if it has the ability.

To configure the escalation target role:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click User Roles.

The User Roles page appears.

Step 3 Click Configure Permission Escalation.

The Configure Permission Escalation dialog box appears.

Step 4 Select a user role from the drop-down list.

Step 5 Click OK to save your changes.

Your changes are saved and the User Roles page appears.

Note Changing the escalation target role is effective immediately. Users in escalated sessions now have the permissions of the new escalation target.

Configuring a Custom User Role for Escalation

License: Any

To use the user role escalation feature, you must first configure a custom user role with the escalation permission, select its escalation password, and assign that role to a user. For more information, see Adding New User Accounts and Configuring User Roles.

Consider the needs of your organization when you configure the escalation password for a custom role. If you want to easily manage many escalating users, you may want to select another user whose password serves as the escalation password. If you change that user’s password or deactivate that user, all escalating users who require that password are affected. This allows you to manage user role escalation more efficiently, especially if you select an externally authenticated user that you can manage centrally.

To configure a custom user role for escalation:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 Click User Roles.

The User Roles page appears.

) next to an existing custom user role.

The User Role Editor page appears.

Step 4 Choose a name, description and menu-based permissions for the custom user role.

For more information, see the procedure in Managing Custom User Roles.

Step 5 In System Permissions, select the Set this role to escalate to: check box.

The escalation password options appear.

Step 6 Select the password that this role uses to escalate. You have two options:

- If you want users with this role to use their own passwords when they escalate, select Authenticate with the assigned user’s password .

- If you want users with this role to use the password of another user, select Authenticate with the specified user’s password and type that username.

Note When authenticating with another user’s password, you can enter any username, even that of a deactivated or nonexistent user. Deactivating the user whose password is used for escalation makes escalation impossible for users with the role that requires it. You can use this feature to quickly remove escalation powers if necessary.

Step 7 Click Save.

Your changes are saved and the User Roles page appears again. Users with this role can now escalate to the target user role. For more information on assigning roles to a user, see Adding New User Accounts.

Escalating Your User Role

License: Any

When a user has an assigned custom user role with permission to escalate, that user may escalate to the target role’s permissions at any time. Note that escalation has no effect on user preferences. The Escalate Permissions option in the User menu does not appear if your assigned user role is not configured for user role escalation.

To escalate user permissions:

Access: Any

Step 1 Select Local > User > Escalate Permissions.

The Escalate User Permissions dialog box appears.

Step 2 Enter the authentication password.

Step 3 Click Escalate.

You now have all permissions of the escalation target role in addition to your current role.

Note that escalation lasts for the remainder of your login session. To return to the privileges of your base role only, you must log out, then begin a new session.

Configuring Single Sign-on from Cisco Security Manager

License: Any

Supported Devices: ASA FirePOWER

Single sign-on (SSO) enables integration between Cisco Security Manager (CSM) Version 4.7 or higher and the Defense Center, which allows you to access the Defense Center from CSM without additional authentication to log in. When managing the ASA module of an ASA FirePOWER device, you may want to modify the policies applied to the FirePOWER module of the device. You can select the managing Defense Center in CSM and launch it in a web browser. If the managing Defense Center is a member of a high availability pair, using SSO navigates you to the primary peer.

If you have access based on your user role, the system navigates you to the Device tab of the Device Management page for the device you cross-launched from in CSM. Otherwise, the system navigates you to the Summary Dashboard page (Overview > Dashboards), except for user accounts with no dashboard access, which use the Welcome page.

Before you can SSO to a Defense Center, you must set up a one-way, encrypted authentication path from CSM to the Defense Center. In NAT environments, the Defense Center and CSM must reside on the same side of the NAT boundary. To enable communications, you must provide the following criteria for CSM and the Defense Center to recognize each other:

- From CSM, you must generate an SSO shared encryption key that identifies the connection. You must enter this key on the Defense Center.

- On the Defense Center, you provide the CSM server hostname or IP address, along with the server port. If you are using high availability, configure SSO on the primary peer.

- To validate the encrypted authentication parameters, you must set up the same usernames (case insensitive) on CSM and the Defense Center for all users who should have SSO access.

The system disables SSO when STIG compliance is enabled for the Defense Center. See Enabling STIG Compliance for more information.

Note You cannot login with single sign-on if your organization uses CACs for authentication. For more information, see Understanding LDAP Authentication With CAC.

To set up single sign-on:

Access: Admin

Step 1 From CSM, generate an SSO shared encryption key.

See your CSM documentation for more information.

Step 2 From the Defense Center, select System > Local > User Management.

The User Management page appears.

Step 3 Select CSM Single Sign-on.

The CSM Single Sign-on page appears.

Step 4 Enter the CSM hostname or IP address and the server Port.

Step 5 Enter the Shared key that you generated from CSM.

Step 6 Optionally, if you want to use the Defense Center’s proxy server to communicate with CSM, select the Use Proxy For Connection check box. For more information, see Understanding Management Interface Options.

Step 7 Click Submit.

The CSM certificate appears.

Step 8 Click Confirm Certificate to save the Certificate.

You can now log in from CSM to the Defense Center without an additional login.

Scheduling Tasks

You can schedule many different types of administrative tasks to run at designated times, either once or on a recurring basis.

Note Some tasks (such as those involving automated software updates or that require pushing updates to managed devices) may place a significant load on networks with low bandwidths. You should schedule tasks like these to run during periods of low network use.

See the following sections for more information:

- Configuring a Recurring Task explains how to set up a scheduled task so that it runs at regular intervals.

- Automating Backup Jobs provides procedures for scheduling backup jobs.

- Automating Certificate Revocation List Downloads provides procedures for automatically refreshing the certificate revocation list (CRL) for an appliance.

- Automating Nmap Scans provides procedures for scheduling Nmap scans.

- Automating Applying an Intrusion Policy provides procedures for queuing an intrusion policy apply on managed devices.

- Automating Report Generation provides procedures for scheduling reports.

- Automating Geolocation Database Updates provides procedures for scheduling automatic updates of the geolocation database (GeoDB).

- Automating FireSIGHT Recommendations provides procedures for scheduling the automatic update of intrusion rule state recommendations.

- Automating Software Updates provides procedures for scheduling the download, push, and installation of software updates.

- Automating Vulnerability Database Updates provides procedures for scheduling the download and installation of VDB updates.

- Automating URL Filtering Updates provides procedures for automating updates of URL filtering data.

- Viewing Tasks describes how to view and manage tasks after they are scheduled.

- Editing Scheduled Tasks describes how to edit an existing task.

- Deleting Scheduled Tasks describes how to delete one-time tasks and all instances of recurring tasks.

Configuring a Recurring Task

License: Any

You set the frequency for a recurring task using the same process for all types of tasks.

Note that the time displayed on most pages on the web interface is the local time, which is determined by using the time zone you specify in your local configuration. Further, the Defense Center automatically adjusts its local time display for daylight saving time (DST), where appropriate. However, recurring tasks that span the transition dates from DST to standard time and back do not adjust for the transition. That is, if you create a task scheduled for 2:00 AM during standard time, it will run at 3:00 AM during DST. Similarly, if you create a task scheduled for 2:00 AM during DST, it will run at 1:00 AM during standard time.

To configure a recurring task:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select the type of task that you want to schedule.

Each of the types of tasks you can schedule is explained in its own section.

Step 4 For the Schedule task to run option, select Recurring.

The page reloads with the recurring task options.

Step 5 In the Start On field, specify the date when you want to start your recurring task. You can use the drop-down list to select the month, day, and year.

Step 6 In the Repeat Every field, specify how often you want the task to recur. You can specify a number of hours, days, weeks, or months.

Step 7 In the Run At field, specify the time when you want to start your recurring task.

Step 8 If you selected Weeks for Repeat Every, a Repeat On field appears. Select the check boxes next to the days of the week when you want to run the task.

Step 9 If you selected Months for Repeat Every, a Repeat On field appears. Use the drop-down list to select the day of the month when you want to run the task.

The remaining options on the New Task page are determined by the task you are creating. See the following sections for more information:

– Automating Backup Jobs

– Automating Certificate Revocation List Downloads

– Automating Nmap Scans

– Automating Report Generation

– Automating FireSIGHT Recommendations

– Automating Software Updates

– Automating Vulnerability Database Updates

– Automating URL Filtering Updates

Automating Backup Jobs

License: Any

Supported Devices: Series 2 and Series 3

Supported Defense Centers: Any

You can use the scheduler to automate backups of your Defense Centers or physical managed devices. You must design a backup profile before you can configure a backup as a scheduled task. For more information, see Creating Backup Profiles.

You cannot perform scheduled backups of virtual managed devices, Cisco NGIPS for Blue Coat X-Series, or Cisco ASA with FirePOWER Services. To perform a scheduled backup of the configuration data on a physical managed device, schedule the task from the web interface of the device itself. To perform a scheduled backup of event data, perform a scheduled backup of the managing Defense Center.

To automate backup tasks:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Backup.

The page reloads to show the backup options.

Step 4 Specify how you want to schedule the backup, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 From the Backup Profile list, select the appropriate backup profile.

For more information on creating new backup profiles, see Creating Backup Profiles.

Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured on the Defense Center to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 9 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Certificate Revocation List Downloads

License: Any

You can use the scheduler to automatically refresh the certificate revocation list (CRL) for the appliance web server on an appliance where you enable user certificates for the appliance. The Download CRL task is automatically created when you enable fetching of a CRL in the local appliance configuration, so this procedure explains how to open the scheduled task to set the frequency.

Tip You must enable and configure user certificates and set a CRL download URL before scheduling this task. For information on configuring user certificates, see Requiring User Certificates.

To automate download of certificate revocation lists:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

).

The Edit Task page appears, showing the download options.

Step 3 Specify how you want to schedule the CRL download, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 4 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 5 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured on the Defense Center to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 6 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Nmap Scans

License: FireSIGHT

You can schedule regular Nmap scans of targets on your network. Automated scans allow you to refresh information previously supplied by an Nmap scan. Because the FireSIGHT System cannot update Nmap-supplied data, you need to rescan periodically to keep that data up to date. You can also schedule scans to automatically test for unidentified applications or servers on hosts in your network. See the following sections for more information:

- Preparing Your System for an Nmap Scan

- Scheduling an Nmap Scan

Note that a Discovery Administrator can also use an Nmap scan as a remediation. For example, when an operating system conflict occurs on a host, that conflict may trigger an Nmap scan. Running the scan obtains updated operating system information for the host, which resolves the conflict. For more information, see Nmap Scan Remediations.

Preparing Your System for an Nmap Scan

License: FireSIGHT

If you have not used the Nmap scanning capability before, you must complete several Nmap configuration steps before defining a scheduled scan. See the following sections for more information:

- Creating an Nmap Scan Instance provides information on setting up an Nmap server connection profile.

- Creating an Nmap Scan Target provides information on setting up a scan target.

- Creating an Nmap Remediation provides information on setting up a remediation definition.

Scheduling an Nmap Scan

License: FireSIGHT

You can schedule a scan of a host or hosts on your network using the Nmap utility.

After Nmap replaces a host’s operating system, applications, or servers detected by the system with the results from an Nmap scan, the system no longer updates the information replaced by Nmap for the host. Nmap-supplied service and operating system data remains static until you run another Nmap scan. If you plan to scan a host using Nmap, you may want to set up regularly scheduled scans to keep Nmap-supplied operating systems, applications, or servers up to date. If the host is deleted from the network map and re-added, any Nmap scan results are discarded and the system resumes monitoring of all operating system and service data for the host.

To automate Nmap scanning:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Nmap Scan.

The page reloads to show the options for automating Nmap scans.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 In the Nmap Remediation field, select the Nmap remediation to use when running the scan.

Step 7 In the Nmap Target field, select the scan target that defines the target hosts you want to scan.

Step 8 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 9 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 10 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Applying an Intrusion Policy

License: Protection

You can queue an intrusion policy apply to a managed device. This task only applies the intrusion policy if an access control policy that references the intrusion policy is applied to the selected device when the task runs. Otherwise, the task aborts before completion.

You must associate an intrusion policy with an access control policy and apply the access control policy to a device before scheduling this task; see Controlling Traffic Using Intrusion and File Policies.

To queue a policy apply to a managed device:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The schedule calendar page for the current month appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Queue Intrusion Policy Apply.

The page reloads to show the options for queuing a policy apply.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the Defense Center.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 In the Intrusion Policy field, you have the following options:

- Select an intrusion policy to apply to the selected target device.

- Select All intrusion policies to apply all intrusion policies already applied to the device selected in the Device field.

Step 7 In the Device field, you have the following options:

- Select a device to which you want to apply the intrusion policy selected in the Intrusion Policy field.

- Select All targeted devices to apply the selected intrusion policy to all monitored devices which already have that intrusion policy applied.

Tip This field only displays devices which have the intrusion policy selected in the Intrusion Policy field already applied.

Step 8 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the Tasks Details section at the bottom of the schedule calendar page, so you should limit the size of your comment.

Step 9 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 10 Click Save.

The task is added. You can check the status of a running task in the Task Details section of the calendar page; see Viewing the Status of Long-Running Tasks.

Step 11 To edit your saved task, click the task anywhere it appears on the schedule calendar page.

).

Automating Report Generation

License: Any

Supported Devices: Any but X-Series

You can automate reports so that they run at regular intervals. However, you must design a template for your report before you can configure it as a scheduled task. See Understanding Report Templates for more information about using the report designer to create a report template.

If you also want to distribute email reports using the scheduler, you must configure your report template and a mail relay host before scheduling the task. For more information, see Distributing Reports by Email at Generation Time and Configuring a Mail Relay Host and Notification Address.

To automate report generation:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The schedule calendar page for the current month appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Report.

The page reloads to show the options for setting up a report to run automatically.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the Defense Center.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 In the Report Template field, select the report template that you want to use from the drop-down list. For more information, see Creating and Editing Report Templates.

Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the Tasks Details section at the bottom of the schedule calendar page, so you should limit the size of your comment.

Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Note Configuring this option does not distribute the reports. For more information, see Distributing Reports by Email at Generation Time.

Step 9 If you do not want to receive report email attachments when reports have no data (for example, when no events of a certain type occurred during the report period), select the If report is empty, still attach to email check box.

Step 10 Click Save.

The task is added. You can check the status of a running task in the Task Details section of the calendar page; see Viewing the Status of Long-Running Tasks.

Step 11 To edit your saved task, click the task anywhere it appears on the schedule calendar page.

).

Automating Geolocation Database Updates

License: FireSIGHT

Supported Defense Centers: Any except DC500

You can use the scheduler to automate recurring geolocation database (GeoDB) updates. Recurring GeoDB updates run once every 7 days (weekly); you can configure the time the update recurs each week. For more information on GeoDB updates, see Updating the Geolocation Database.

To automate geolocation database updates:

Access: Admin

Step 1 Select System > Updates.

The Product Updates page appears.

Step 2 Click the Geolocation Updates tab.

The Geolocation Updates page appears.

Step 3 Under Recurring Geolocation Updates, select the Enable Recurring Weekly Updates check box.

The Update Start Time field appears.

Step 4 In the Update Start Time field, specify the time and day of the week when you want weekly GeoDB updates to occur.

Step 5 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating FireSIGHT Recommendations

License: Protection

You can automatically generate rule state recommendations based on network discovery data for your network using the most recently saved configuration settings in a custom intrusion policy.

Note If the system automatically generates scheduled recommendations for an intrusion policy with unsaved changes, you must discard your changes in that policy and commit the policy if you want the policy to reflect the automatically generated recommendations. See Resolving Conflicts and Committing Policy Changes for more information.

When the task runs, the system automatically generates recommended rule states. Optionally, depending on the configuration of your policy, it also modifies the states of intrusion rules based on the criteria described in Tailoring Intrusion Protection to Your Network Assets. Modified rule states take effect the next time you apply your intrusion policy.

To automate rule state recommendation generation:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select FireSIGHT Recommended Rules.

The page reloads to show the options for generating FireSIGHT recommendations.

Step 4 Optionally, click the policies link next to the Job Type field to display the Detection & Prevention page, where you can configure FireSIGHT Recommended Rules in an intrusion policy.

Step 5 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 6 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 7 Next to Policies, select one or more policies where you want to generate recommendations. You have the following options:

- In the Policies field, select one or more policies. Use the Shift and Ctrl keys to select multiple policies.

- Click the All Policies check box to select all policies.

Step 8 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 9 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 10 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Software Updates

License: Any

You can automatically download and apply most patches and feature releases to the FireSIGHT System.

Note You must manually upload and install updates in two situations. First, you cannot schedule major updates to the FireSIGHT System. Second, you cannot schedule updates for or pushes from appliances that cannot access the Support Site. If your appliance is not directly connected to the Internet, you should set up a proxy as described in Configuring Management Interfaces to allow it to download updates from the Support Site. For information on manually updating the FireSIGHT System, see Updating System Software.

The tasks you must schedule to install software updates vary depending on whether you are updating the Defense Center or are using a Defense Center to update managed devices. Cisco strongly recommends that you use your Defense Centers to update the devices they manage.

To update the Defense Center, schedule the software installation using the Install Latest Update task. To use a Defense Center to automate software updates for its managed devices, you must schedule two tasks:

Step 1 Push (copy) the update to managed devices using the Push Latest Update task.

Step 2 Install the update on managed devices using the Install Latest Update task.

When scheduling updates, schedule the push and install tasks to happen in succession. That is, to automate software updates on your managed devices, you must first push the update to the device before you can install it. To automate software updates on a device group, you must select all the devices within the group. (Note that during the manual update process you do not have to push an update to managed devices before you install it. For more information, see Updating Managed Devices.)

Note You cannot create individual update tasks for managed devices in a clustered or stacked configuration.

Always allow enough time between tasks for the process to complete. Tasks should be scheduled at least 30 minutes apart. For example, if you schedule a task to install an update and the update has not finished copying from the Defense Center to the device, the installation task will not succeed. However, if the scheduled installation task repeats daily, it will install the pushed update when it runs the next day.

Note that a task scheduled to install an update on a device group will install the update to each device within the device group simultaneously. Allow enough time for the scheduled task to complete for all the devices within the device group.

If you want to have more control over this process, you can use the Once option to download and install updates during off-peak hours after you learn that an update has been released.

See the following sections for more information:

- Automating Software Downloads

- Automating Software Pushes

- Automating Software Installs

Automating Software Downloads

License: Any

You can create a scheduled task that automatically downloads the latest software updates from Cisco. You can use this task to schedule download of updates you plan to install manually.

To automate software update downloads:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Download Latest Update.

The New Task page reloads to show the update options.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 In the Update Items section, select Software.

Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 9 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Software Pushes

License: Any

If you want to automate the installation of software updates on managed devices, you must push the updates to the devices before installing.

When you push updates to managed devices, information about the push process status is reported on the Tasks page. See Viewing the Status of Long-Running Tasks for more information.

When you create the task to push software updates to managed devices, make sure you allow enough time between the push task and a scheduled install task for the updates to be copied to the device.

To push software updates to managed devices:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Push Latest Update.

The page reloads to show the options for pushing updates.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 From the Device list, select the device that you want to receive updates.

Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 9 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Software Installs

License: Any

If you are using a Defense Center to create a task to install a software update on a managed device, make sure you allow enough time between the task that pushes the update to the device and the task that installs the update. See Automating Software Pushes for information about pushing updates to managed devices.

Caution Depending on the update being installed, the appliance may reboot after the software is installed.

To schedule a software installation task:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Install Latest Update.

The page reloads to show the options for installing updates.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 From the Device list, you have the following options:

- Select the device where you want to install the update.

- Select the name of the Defense Center to install the update there.

Step 7 In the Update Items section, select Software.

Step 8 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 9 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 10 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating Vulnerability Database Updates

License: FireSIGHT

Cisco uses vulnerability database (VDB) updates to expand the list of network assets, traffic, and vulnerabilities that the FireSIGHT System recognizes. You can use the scheduling feature to download and install the latest VDB update on your Defense Centers, thereby ensuring that you are using the most up-to-date information to evaluate the hosts on your network.

Note You cannot schedule updates for appliances that cannot access the Support Site. If your appliance is not directly connected to the Internet, you should set up a proxy as described in Configuring Management Interfaces to allow it to download updates from the Support Site. For information on manually updating the FireSIGHT System, see Updating System Software.

When automating VDB updates, you must automate two separate steps:

Step 1 Downloading the VDB update.

Step 2 Installing the VDB update.

Always allow enough time between tasks for the process to complete. For example, if you schedule a task to install an update and the update has not fully downloaded, the installation task will not succeed. However, if the scheduled installation task repeats daily, it will install the downloaded VDB update when the task runs the next day.

If you want to have more control over this process, you can use the Once option to download and install VDB updates during off-peak hours after you learn that an update has been released.

Caution Installing a VDB update restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

See the following sections for more information:

- Automating VDB Update Downloads

- Automating VDB Update Installs

Automating VDB Update Downloads

License: FireSIGHT

You can create a scheduled task on the Defense Center that automatically downloads the latest VDB update from Cisco.

To automate VDB update downloads:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Download Latest Update.

The New Task page reloads to show the update options.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 In the Update Items section, select Vulnerability Database.

Step 7 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 8 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 9 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating VDB Update Installs

License: FireSIGHT

You should allow enough time between the task that downloads the VDB update and the task that installs the update; see Automating VDB Update Downloads for information.

Caution Installing a VDB update restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic for more information.

To schedule a VDB update:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Install Latest Update.

The page reloads to show the options for installing updates.

Step 4 Specify how you want to schedule the task, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 From the Device drop-down list, select the name of the Defense Center.

Step 7 In the Update Items section, select Vulnerability Database.

Step 8 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 9 Optionally, in the Email Status To: field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 10 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Automating URL Filtering Updates

License: URL Filtering

Supported Defense Centers: Any except DC500

You can use the scheduler to automate updates of URL filtering data from the Collective Security Intelligence Cloud. For a URL filtering update task to succeed:

- The Defense Center must have access to the Internet or it cannot contact the cloud.

- You must enable URL filtering, as described in Enabling Cloud Communications.

Note that when you enable URL filtering, you can also enable automatic updates. This forces the Defense Center to contact the cloud every 30 minutes for URL filtering data updates. If you have enabled automatic updates, you should not create a scheduled task to update URL filtering data.

Although daily updates tend to be small, if it has been more than five days since your last update, new URL filtering data may take up to 20 minutes to download, depending on your bandwidth. Then, it may take up to 30 minutes to perform the update itself.

To automate URL filtering data tasks:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click Add Task.

The New Task page appears.

Step 3 From the Job Type list, select Update URL Filtering Database.

The page reloads to show the URL filtering update options.

Step 4 Specify how you want to schedule the update, Once or Recurring:

- For one-time tasks, use the drop-down lists to specify the start date and time. The Current Time field indicates the current time on the appliance.

- For recurring tasks, you have several options for setting the interval between instances of the task. See Configuring a Recurring Task for details.

Step 5 In the Job Name field, type a name using up to 255 alphanumeric characters, spaces, or dashes.

Step 6 Optionally, in the Comment field, type a comment using up to 255 alphanumeric characters, spaces, or periods.

Tip The comment field appears in the View Tasks section of the page, so you should try to keep it relatively short.

Step 7 Optionally, in the Email Status To field, type the email address (or multiple email addresses separated by commas) where you want task status messages sent.

You must have a valid email relay server configured to send status messages. See Configuring a Mail Relay Host and Notification Address for more information about configuring a relay host.

Step 8 Click Save.

The task is added. You can check the status of a running task on the Task Status page; see Viewing the Status of Long-Running Tasks.

Viewing Tasks

License: Any

After adding scheduled tasks, you can view them and evaluate their status. The View Options section of the page allows you to view scheduled tasks using a calendar and a list of scheduled tasks.

See the following sections for more information:

- Using the Calendar

- Using the Task List

Using the Calendar

License: Any

The Calendar view option allows you to view which scheduled tasks occur on which day.

To view scheduled tasks using the calendar:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 You can perform the following tasks using the calendar view:

- Click the double left arrow icon (

) to move back one year.

- Click the single left arrow icon (

) to move back one month.

- Click the single right arrow icon (

) to move forward one month.

- Click the double right arrow icon (

) to move forward one year.

- Click Today to return to the current month and year.

- Click Add Task to schedule a new task.

- Click a date to view all scheduled tasks for the specific date in a task list table below the calendar.

- Click a specific task on a date to view the task in a task list table below the calendar.

Note For more information about using the task list, see Using the Task List.

Using the Task List

License: Any

The Task List shows a list of tasks along with their status. The task list appears below the calendar when you open the calendar. In addition, you can access it by selecting a date or task from the calendar. See Using the Calendar for more information.

Table 62-1 Task List Columns

Column

Description

Name

Displays the name of the scheduled task and the comment associated with it.

Type

Displays the type of scheduled task.

Start Time

Displays the scheduled start date and time.

Frequency

Displays how often the task is run.

Status

Describes the current status for a scheduled task:

- A check mark icon (

) indicates that the task ran successfully.

- A question mark icon (

) indicates that the task is in an unknown state.

- An exclamation mark icon (

) indicates that the task failed.

Creator

Displays the name of the user that created the scheduled task.

Edit

Edits the scheduled task.

Delete

Deletes the scheduled task.

Editing Scheduled Tasks

License: Any

You can edit a scheduled task that you previously created. This feature is especially useful if you want to test a scheduled task once to make sure that the parameters are correct. Later, after the task completes successfully, you can change it to a recurring task.

To edit an existing scheduled task:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click either the task that you want to edit or the day on which the task appears.

The Task Details table containing the selected task or tasks appears.

)

The Edit Task page appears, showing the details of the task you selected.

Step 4 Edit the task to meet your needs, including the start time, the job name, the comment, and how often the task runs, once or recurring. You cannot change the type of job.

The remaining options are determined by the task you are editing. See the following sections for more information:

- Automating Backup Jobs

- Automating Certificate Revocation List Downloads

- Automating Nmap Scans

- Automating Report Generation

- Automating FireSIGHT Recommendations

- Automating Software Updates

- Automating Vulnerability Database Updates

- Automating URL Filtering Updates

Step 5 Click Save to save your edits.

Your change are saved and the Scheduling page appears again.

Deleting Scheduled Tasks

License: Any

There are two types of deletions you can perform from the Schedule View page. You can delete a specific one-time task that has not yet run or you can delete every instance of a recurring task. If you delete an instance of a recurring task, all instances of the task are deleted. If you delete a task that is scheduled to run once, only that task is deleted.

The following sections describe how to delete tasks:

- To delete all instances of a task, see Deleting a Recurring Task.

- To delete a single instance of a task, see Deleting a One-Time Task.

Deleting a Recurring Task

License: Any

When you delete one instance of a recurring task, you automatically delete all instances of that task.

To delete a recurring task:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 On the calendar, select an instance of the recurring task you want to delete.

The page reloads to display a table of tasks below the calendar.

).

All instances of the recurring task are deleted.

Deleting a One-Time Task

License: Any

You can delete a one-time scheduled task or delete the record of a previously run scheduled task using the task list.

To delete a single task or, if it has already run, delete a task record:

Access: Admin/Maint

Step 1 Select System > Tools > Scheduling.

The Scheduling page appears.

Step 2 Click the task that you want to delete or the day on which the task appears.

A table containing the selected task or tasks appears.

).

The instance of the task you selected is deleted.

Managing System Policies

A system policy allows you to manage the following on your FireSIGHT System appliances:

- access control preferences

- appliance access lists

- audit log settings

- external authentication

- dashboard settings

- database event limits

- DNS cache properties

- the mail relay host and notification address

- tracking intrusion and network analysis policy changes

- specifying a different language

- custom login banners

- SNMP polling settings

- synchronizing time

- STIG compliance

- serving time from the Defense Center

- user interface and command line interface timeout settings

- mapping vulnerabilities for servers

You can use a system policy to control the aspects of your Defense Center that are likely to be similar for other appliances in your deployment. For example, your organization’s security policies may require that your appliances have a “No Unauthorized Use” message when a user logs in. With system policies, you can set the login banner once in a system policy on a Defense Center and then apply the policy to all the devices that it manages.

You can also benefit from having multiple system policies on a Defense Center. For example, if you have different mail relay hosts that you use under different circumstances or if you want to test different database limits, you can create several system policies and switch between them, rather than editing a single policy.

Contrast a system policy, which controls aspects of an appliance that are likely to be similar across a deployment, with system settings, which are likely to be specific to a single appliance. See Configuring Appliance Settings for more information.

See the following sections for more information:

- Creating a System Policy

- Editing a System Policy

- Applying a System Policy

- Comparing System Policies

- Deleting System Policies

Creating a System Policy

License: Any

Supported Devices: Any except X-Series

When you create a system policy, you assign it a name and a description. Next, you configure the various aspects of the policy, each of which is described in its own section.

Instead of creating a new policy, you can export a system policy from another appliance and then import it onto your appliance. You can then edit the imported policy to suit your needs before you apply it. For more information, see Importing and Exporting Configurations.

To create a system policy:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

The Policy Name column includes the system policy’s description. The Applied To column indicates the number of appliances where the policy is applied and a count of out-of-date appliances where the previously applied policy has changed and should be reapplied.

Step 2 Click Create Policy.

The Create Policy page appears.

Step 3 From the drop-down list, select an existing policy to use as a template for your new system policy.

Step 4 Type a name for your new policy in the New Policy Name field.

Step 5 Type a description for your new policy in the New Policy Description field.

Step 6 Click Create.

Your system policy is saved and the Edit System Policy page appears. For information about configuring each aspect of the system policy, see one of the following sections:

- Configuring the Access List for Your Appliance

- Configuring Audit Log Settings

- Enabling External Authentication

- Configuring Dashboard Settings

- Configuring Database Event Limits

- Configuring DNS Cache Properties

- Configuring a Mail Relay Host and Notification Address

- Configuring Access Control Policy Preferences

- Configuring Network Analysis Policy Preferences

- Configuring Intrusion Policy Preferences

- Specifying a Different Language

- Adding a Custom Login Banner

- Configuring SNMP Polling

- Enabling STIG Compliance

- Synchronizing Time

- Serving Time from the Defense Center

- Configuring User Interface Settings

- Mapping Vulnerabilities for Servers

Editing a System Policy

License: Any

Supported Devices: Any except X-Series

You can edit an existing system policy. If you edit a system policy that is currently applied to an appliance, reapply the policy after you have saved your changes. For more information, see Applying a System Policy.

To edit an existing system policy:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears, including a list of the existing system policies.

) next to the system policy that you want to edit.

The Edit Policy page appears. You can change the policy name and policy description. For information about configuring each aspect of the system policy, see one of the following sections:

- Configuring Access Control Policy Preferences

- Configuring the Access List for Your Appliance

- Configuring Audit Log Settings

- Enabling External Authentication

- Configuring Dashboard Settings

- Configuring Database Event Limits

- Configuring DNS Cache Properties

- Configuring a Mail Relay Host and Notification Address

- Configuring Network Analysis Policy Preferences

- Configuring Intrusion Policy Preferences

- Specifying a Different Language

- Adding a Custom Login Banner

- Configuring SNMP Polling

- Synchronizing Time

- Serving Time from the Defense Center

- Configuring User Interface Settings

- Mapping Vulnerabilities for Servers

Note If you are editing a system policy applied to an appliance, make sure you reapply the updated policy when you are finished. See Applying a System Policy.

Step 3 Click Save Policy and Exit to save your changes. The changes are saved, and the System Policy page appears.

Applying a System Policy

License: Any

Supported Devices: Any except X-Series

You can apply a system policy to an appliance. If a system policy is already applied, any changes you make do not take effect until you reapply it.

Note You cannot apply a system policy to Cisco NGIPS for Blue Coat X-Series.

To apply a system policy:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

) next to the system policy that you want to apply.

The Apply page appears.

Step 3 Select the appliances to which you want to apply the system policy.

Tip You can sort the appliances by group, model, health policy, or applied system policy. You can select either an individual appliance or an entire group.

Step 4 Click Apply.

The System Policy page appears. A message indicates the status of applying the system policy.

Comparing System Policies

License: Any

Supported Devices: Any except X-Series

You can compare two system policies or two revisions of the same system policy, subject to the system policies you can access. This allows you to review policy changes for compliance with your organization’s standards, or for optimization of system performance. To quickly compare your active system policy to another, you can select the Running Configuration option. Optionally, after you compare, you can generate a PDF report to record the differences between the system policies or system policy revisions.

There are two tools you can use to compare system policies or system policy revisions:

- The comparison view displays the differences between two system policies or system policy revisions in a side-by-side format. The name of each policy or policy revision appears in the title bar on the left and right sides of the comparison view.

You can use this to view and navigate both policy revisions on the web interface, with their differences highlighted.

- The comparison report creates a record of the differences between two system policies or system policy revisions in a format similar to the system policy report, but in PDF format.

You can use this to save, copy, print, and share your policy comparisons for further examination.

Using the System Policy Comparison View

License: Any

Supported Devices: Any except X-Series

The comparison view displays both system policies or policy revisions in a side-by-side format, with each policy or policy revision identified by name in the title bar on the left and right sides of the comparison view. For all revisions, the system policy comparison view displays the time of last modification and the last user to the right of the policy name.

Differences between the two system policies or policy revisions are highlighted:

- Blue indicates that the highlighted setting is different in the two policies or policy revisions, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy or policy revision, but not the other.

Table 63-1 System Policy Comparison View Actions

To...

You can...

navigate individually through changes

select Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a new system policy comparison view

select New Comparison.

The Select Comparison window appears. See Using the System Policy Comparison Report for more information.

generate a system policy comparison report

select Comparison Report.

The system policy comparison report is a PDF that contains information identical to the system policy comparison view.

Using the System Policy Comparison Report

License: Any

Supported Devices: Any except X-Series

A system policy comparison report is a record of all differences between two system policies or two revisions of the same system policy identified by the system policy comparison view, presented in PDF format. You can use this report to further examine the differences between two system policy configurations and to save and disseminate your findings.

You can generate a system policy comparison report from the comparison view for any system policies to which you have access. Changes you make to a system policy do not appear in the system policy comparison report until you save the changes.

Depending on your configuration, a system policy comparison report can contain one or more sections. Each section uses the same format and provides the same level of detail. Note that the Value A and Value B columns represent the policies or policy revisions you configured in the comparison view.

Tip You can use a similar procedure to compare SSL, network analysis, intrusion, file, access control, or health policies.

To compare two system policies or two revisions of the same policy:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 Click Compare Policies.

The Select Comparison pop-up window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

- To compare two revisions of the same policy, select Other Revision .

- To compare another policy to a currently active policy, select Running Configuration.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing two revisions of the same policy, select the policy from the Policy drop-down list, then select the revisions you want to compare from the Revision A and Revision B drop-down lists.

- If you are comparing a running configuration to another policy, select the running configuration from the Target/Running Configuration A drop-down list, and the other policy from the Policy B drop-down list.

Step 5 Click OK to display the system policy comparison view.

The comparison view appears.

Step 6 Click Comparison Report to generate the system policy comparison report.

The system policy comparison report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Deleting System Policies

License: Any

Supported Devices: Any except X-Series

You can delete a system policy, even if it is in use. If the policy is still in use, it is used until a new policy is applied. Default system policies cannot be deleted.

To delete a system policy:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

The System Policy page appears. A pop-up message appears, confirming the policy deletion.

Configuring a System Policy

License: Any

Supported Devices: Any except X-Series

You can configure various system policy settings. For information about configuring each aspect of the system policy, see one of the following sections:

- Configuring Access Control Policy Preferences

- Configuring the Access List for Your Appliance

- Configuring Audit Log Settings

- Enabling External Authentication

- Configuring Dashboard Settings

- Configuring Database Event Limits

- Configuring DNS Cache Properties

- Configuring a Mail Relay Host and Notification Address

- Configuring Network Analysis Policy Preferences

- Configuring Intrusion Policy Preferences

- Specifying a Different Language

- Adding a Custom Login Banner

- Synchronizing Time

- Serving Time from the Defense Center

- Configuring User Interface Settings

- Mapping Vulnerabilities for Servers

Configuring Access Control Policy Preferences

License: Protection

Supported Devices: Any except X-Series

You can configure the system to prompt users for a comment when they add or modify a rule in an access control policy, prompting them to enter a rule comment. You can use this to track users’ reasons for policy changes. If you enable comments on access control rule changes, you can make the rule comment optional or mandatory. The system prompts the user for a comment when each new change to a rule is saved.

The system adds the comment to the rule’s comment history when the user saves the rule. For more information, see Adding Comments to a Rule.

To configure the access control policy rule comment settings:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the access control policy settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the access control policy settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Access Control Preferences.

The Access Control Preferences page appears.

Step 4 You have the following options:

- Select Disabled from the drop-down list to allow users to add or modify a rule in an access control policy without entering a comment.

- Select Optional from the drop-down list to display the Description of Changes (Optional) window to users when they save changes to access control policy rules. This allows users the option to describe changes in a comment.

- Select Required from the drop-down list to display the Description of Changes (Required) window to users when they save changes to access control policy rules. This requires users to describe changes in a comment before the changes are saved.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring the Access List for Your Appliance

License: Any

Supported Devices: Any except X-Series

The Access List page allows you to control which computers can access your appliance on specific ports. By default, port 443 (Hypertext Transfer Protocol Secure, or HTTPS), which is used to access the web interface, and port 22 (Secure Shell, or SSH), which is used to access the command line, are enabled for any IP address. You can also add SNMP access over port 161. Note that you must add SNMP access for any computer you plan to use to poll for SNMP information.

Caution By default, access to the appliance is not restricted. To operate the appliance in a more secure environment, consider adding access to the appliance for specific IP addresses and then deleting the default any option.

The access list is part of the system policy. You can specify the access list either by creating a new system policy or by editing an existing system policy. In either case, the access list does not take effect until you apply the system policy.

Note that this access list does not also control external database access. For more information on the external database access list, see Enabling Access to the Database.

To configure the access list:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the access list in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the access list as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

).

The setting is removed.

Caution If you delete access for the IP address that you are currently using to connect to the appliance interface, and there is no entry for “ IP=any port=443”, you will lose access to the system when you apply the policy.

Step 4 Optionally, to add access for one or more IP addresses, click Add Rules.

The Add IP Address page appears.

Step 5 In the IP Address field, you have the following options, depending on the IP addresses you want to add:

- an exact IP address (for example, 192.168.1.101 )

- an IP address block using CIDR notation (for example, 192.168.1.1/24 )

For information on using CIDR in the FireSIGHT System, see IP Address Conventions.

- any , to designate any IP address

Step 6 Select SSH, HTTPS, SNMP, or a combination of these options to specify which ports you want to enable for these IP addresses.

Step 7 Click Add.

The Access List page appears again, reflecting the changes you made.

Step 8 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring Audit Log Settings

License: Any

Supported Devices: Any except X-Series

You can configure the system policy so that the appliance streams an audit log to an external host.

Note You must ensure that the external host is functional and accessible from the appliance sending the audit log.

The sending host name is part of the information sent. You can further identify the audit log stream with a facility, a severity, and an optional tag. The appliance does not send the audit log until you apply the system policy.

After you apply a policy with this feature enabled, and your destination host is configured to accept the audit log, the syslog messages are sent. The following is an example of the output structure:

Date Time Host [Tag] Sender: [User_Name]@[User_IP], [Subsystem], [Action]

where the local date, time, and hostname precede the bracketed optional tag, and the sending device name precedes the audit log message.

For example:

Mar 01 14:45:24 localhost [TAG] Dev-DC3000: admin@10.1.1.2, Operations > Monitoring, Page View

To configure the audit log settings:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the audit log settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the audit log settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Audit Log Settings.

The Audit Log Settings page appears.

Step 4 Select Enabled from the Send Audit Log to Syslog drop-down menu. (The default setting is Disabled.)

Step 5 Designate the destination host for the audit information by using the IP address or the fully qualified name of the host in the Host field. The default port (514) is used.

Caution If the computer you configure to receive an audit log is not set up to accept remote messages, the host will not accept the audit log.

Step 6 Select a syslog facility from the Facility field.

Step 7 Select a severity from the Severity field.

Step 8 Optionally, insert a reference tag in the Tag (optional) field.

Step 9 To send regular audit log updates to an external HTTP server, select Enabled from the Send Audit Log to HTTP Server drop-down list. The default setting is Disabled.

Step 10 In the URL to Post Audit field, designate the URL where you want to send audit information. You must enter an URL that corresponds to a listener program that expects the HTTP POST variables as listed:

- subsystem

- actor

- event_type

- message

- action_source_ip

- action_destination_ip

- result

- time

- tag (if defined, as above)

Caution To allow encrypted posts, you must use an HTTPS URL. Note that sending audit information to an external URL may affect system performance.

Step 11 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. See Applying a System Policy for more information.

Enabling External Authentication

License: Any

Supported Devices: Any except X-Series

Normally, when a user logs into an appliance, the appliance verifies user credentials by comparing the credentials to a user account stored in the appliance’s local database. However, if you create an authentication object referencing an external authentication server, you can enable external authentication in the system policy to let users logging into the Defense Center or managed device authenticate to that server, rather than using the local database.

When you apply a system policy with external authentication enabled to an appliance, the appliance verifies the user credentials against users on an LDAP or RADIUS server. In addition, if a user has local, internal authentication enabled and the user credentials are not found in the internal database, the appliance then checks the external server for a set of matching credentials. If a user has the same username on multiple systems, all passwords across all servers work. Note, however, that if authentication fails on the available external authentication servers, the appliance does not revert to checking the local database.

When you enable external authentication, you can set the default user role for any user whose account is externally authenticated. You can select multiple roles, as long as those roles can be combined. For example, if you enable external authentication that retrieves only users in the Network Security group in your company, you may set the default user role to include the Security Analyst role so users can access collected event data without any additional user configuration on your part. However, if your external authentication retrieves records for other personnel in addition to the security group, you would probably want to leave the default role unselected. For more information on available user roles, see Understanding User Privileges.

If no access role is selected, users can log in but cannot access any functionality. After a user attempts to log in, their account is listed on the User Management page, where you can edit the account settings to grant additional permissions. For more information on modifying a user account, see Modifying User Privileges and Options.

Tip If you configure the system policy to use one user role and apply the policy, then later modify the policy to use different default user roles and reapply, any user accounts created before the modification retain the first user role until you modify the accounts, or delete and recreate them.

If you want to specify the set of users who can successfully authenticate against the LDAP server for shell access, you must set the shell access attribute and other settings within an LDAP authentication object before enabling external authentication in a system policy. For more information, see Configuring LDAP-Specific Parameters and Understanding Shell Access.

If you want to specify the set of users who can successfully authenticate against the LDAP server for CAC authentication and authorization, you must set the UI access attribute, user name template, and other settings in an LDAP authentication object before you enable external authentication in a system policy. For more information, see Configuring LDAP-Specific Parameters and Understanding LDAP Authentication With CAC.

Note If you want to enable both shell access and CAC authentication on an appliance, you must create separate authentication objects and enable them separately in your system policy.

After you finish customizing your authentication object, you must enable external authentication in a system policy on your Defense Center and then push that policy to managed devices. After you apply the policy to a device, eligible externally authenticated users can log into that device. To make changes to your external authentication settings, you have to modify the system policy on the Defense Center, and then apply the policy to the device again. To disable authentication on a managed device, you can disable it in a system policy on the Defense Center and push that to the device.

Note that you can only enable external authentication on physical and virtual Defense Centers and managed devices. Enabling external authentication by applying a system policy is not supported on Cisco NGIPS for Blue Coat X-Series.

If a user with internal authentication attempts to log in, the appliance first checks if that user is in the local user database. If the user exists, the appliance then checks the username and password against the local database. If a match is found, the user logs in successfully. If the login fails, however, and external authentication is enabled, the appliance checks the user against each external authentication server in the authentication order shown in the system policy. If the username and password match results from an external server, the appliance changes the user to an external user with the default privileges for that authentication object.

If an external user attempts to log in, the appliance checks the username and password against the external authentication server. If a match is found, the user logs in successfully. If the login fails, the user login attempt is rejected. External users cannot authenticate against the user list in the local database. If the user is a new external user, an external user account is created in the local database with the default privileges from the external authentication object.

To enable authentication of users on external servers:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify your external authentication settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure your external authentication settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click External Authentication.

The External Authentication page appears.

Step 4 From the Status drop-down list, select Enabled.

Step 5 From the Default User Role drop-down list, select user roles to define the default permissions you want to grant to externally authenticated users.

Tip Press Ctrl before selecting roles to select multiple default user roles. Note that although you can select both a Security Analyst role and the corresponding Security Analyst (Read Only) role, only the Security Analyst role is applied.

Step 6 If you want to use the external server to authenticate shell access accounts as well, select Enabled from the Shell Authentication drop-down list.

Step 7 If you want to enable CAC authentication and authorization, select an available CAC authentication object from the CAC Authentication drop-down list.

For the complete procedure for configuring CAC authentication and authorization, see Understanding LDAP Authentication With CAC.

Step 8 To enable use of a preconfigured authentication object, select the check box next to the object. You must select at least one authentication object to enable external authentication.

Tip If you enabled shell authentication in step 6, you must select an authentication object configured to allow shell access. Note that you must use different authentication objects to manage shell access and CAC authentication in the same system policy. For more information, see Understanding Shell Access and Understanding LDAP Authentication With CAC.

Step 9 Optionally, use the up and down arrows to change the order in which authentication servers are accessed when an authentication request occurs.

Note Remember that shell access users can only authenticate against the server whose authentication object is highest in the profile order.

Step 10 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. See Applying a System Policy for more information.

Configuring Dashboard Settings

License: Any

Supported Devices: Any except X-Series

You can configure the system policy so that Custom Analysis widgets are enabled on the dashboard. Dashboards provide you with at-a-glance views of current system status through the use of widgets: small, self-contained components that provide insight into different aspects of the FireSIGHT System.

The Custom Analysis widget allows you to create a visual representation of events based on a flexible, user-configurable query of the events in your appliance's database. See Understanding the Custom Analysis Widget for more information on how to use custom widgets.

To enable Custom Analysis widgets:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the dashboard settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the dashboard settings as part of a new system policy, click Create Policy . Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Dashboard.

The Dashboard Settings page appears.

Step 4 Select the Enable Custom Analysis Widgets check box to allow users to add Custom Analysis widgets to dashboards. Clear the check box to prohibit users from using those widgets.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring Database Event Limits

License: Any

Supported Devices: Any except X-Series

Table 63-2 Database Event Limits

Event Type

Upper Event Limit

Lower Event Limit

intrusion events

2.5 million (DC500)

10 million (DC1000, virtual Defense Center)

20 million (DC750)

30 million (DC1500)

60 million (DC2000)

100 million (DC3000)

150 million (DC3500)

300 million (DC4000)

10,000

discovery events

10 million

20 million (DC2000, DC4000)

zero (disables storage)

connection events

Security Intelligence Events

10 million (DC500, DC1000, virtual Defense Center)

50 million (DC750)

100 million (DC1500, DC3000)

300 million (DC2000)

500 million (DC3500)

1 billion (DC4000)

Upper event limit is shared between connection events and Security Intelligence events; the sum of configured maximums for the two events cannot exceed the upper event limit.

zero (disables storage)

connection summaries (aggregated connection events)

10 million (DC500, DC1000, virtual Defense Center)

50 million (DC750)

100 million (DC1500, DC3000)

300 million (DC2000)

500 million (DC3500)

1 billion (DC4000)

zero (disables storage)

correlation and compliance white list events

1 million

2 million (DC2000, DC4000)

one

malware events

10 million

20 million (DC2000, DC4000)

10,000

file events

10 million

20 million (DC2000, DC4000)

zero (disables storage)

health events

1 million

zero (disables storage)

audit records

100,000

one

remediation status events

10 million

one

the white list violation history of the hosts on your network

a 30-day history of violations

one day’s history

user activity (user events)

10 million

one

user logins (user history)

10 million

one

rule update import log records

1 million

one

If the number of events in the intrusion event database exceeds the maximum, the oldest events and packet files are pruned until the database is back within the event limits. See Configuring a Mail Relay Host and Notification Address for information about generating automated email notifications when events are automatically pruned.

For information on manually pruning the discovery and user databases, see Purging Discovery Data from the Database.

In addition, you can configure an email address that will receive notifications when intrusion events and audit records are pruned from the database.

To configure the maximum number of records in the database:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the database settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the database settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access Control Preferences page appears.

Step 3 Click Database.

The Database page appears.

Step 4 For each of the databases, enter the number of records you want to store.

For information on how many records each database can maintain, see the Database Event Limits table.

Step 5 Optionally, in the Data Pruning Notification Address field, enter the email address you want to receive notifications when intrusion events, discovery events, audit records, security intelligence data, or URL filtering data are pruned from the appliance’s database.

Note that you must also configure an email server. See Configuring a Mail Relay Host and Notification Address for more information.

Step 6 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring DNS Cache Properties

License: Any

Supported Devices: Any except X-Series

If you have a DNS server configured on the Network page, you can configure the appliance to resolve IP addresses automatically on the event view pages. As a user assigned the Administrator role, you can also configure basic properties for DNS caching performed by the appliance. Configuring DNS caching allows you to identify IP addresses you previously resolved without performing additional lookups. This can reduce the amount of traffic on your network and speed the display of event pages when IP address resolution is enabled.

To configure the DNS cache properties:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the DNS cache settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the DNS cache settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click DNS Cache.

The DNS Cache page appears.

Step 4 Select Enabled from the DNS Resolution Caching drop-down list to enable caching. Select Disabled to disable it.

Note DNS resolution caching is a system-wide setting that allows the caching of previously resolved DNS lookups. To configure IP address resolution on a per-user-account basis, users must also select Event View Settings from the User Preferences menu, enable Resolve IP Addresses, and then click Save. For information about configuring DNS servers, see Configuring Management Interfaces. For information about configuring event view preferences, see Configuring Event View Settings.

Step 5 In the DNS Cache Timeout (in minutes) field, enter the number of minutes a DNS entry remains cached in memory before it is removed for inactivity.

The default setting is 300 minutes (five hours).

Step 6 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Caution Although DNS caching is enabled for the appliance, IP address resolution is not enabled on a per-user basis unless it is configured on the Events page accessed from the User Preferences menu.

Configuring a Mail Relay Host and Notification Address

License: Any

Supported Devices: Any except X-Series

You must configure a mail host if you plan to:

- email event-based reports

- email status reports for scheduled tasks

- email change reconciliation reports

- email data pruning notifications

- use email for discovery event, impact flag, and correlation event alerting

- use email for intrusion event alerting

- use email for health event alerting

You can select an encryption method for the communication between appliance and mail relay host, and can supply authentication credentials for the mail server if needed. After configuring settings, you can test the connection between the appliance and the mail server using the supplied settings.

To configure a mail relay host:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the email settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the email settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Email Notification.

The Configure Email Notification page appears.

Step 4 In the Mail Relay Host field, type the hostname or IP address of the mail server you want to use.

Note The mail host you enter must allow access from the appliance.

Step 5 Enter the port number to use on the email server in the Port Number field. Typical ports include 25, when using no encryption, 465, when using SSLv3, and 587, when using TLS.

Step 6 To select an encryption method, you have the following options:

- To encrypt communications between the appliance and the mail server using Transport Layer Security, select TLS from the Encryption Method drop-down list.

- To encrypt communications between the appliance and the mail server using Secure Socket Layers, select SSLv3 from the Encryption Method drop-down list.

- To allow unencrypted communication between the appliance and the mail server, select None from the Encryption Method drop-down list.

Note that certificate validation is not required for encrypted communication between the appliance and mail server.

Step 7 Enter a valid email address in the From Address field for use as the source email address for messages sent by the appliance.

Step 8 Optionally, to supply a user name and password when connecting to the mail server, select Use Authentication. Enter a user name in the Username field. Enter a password in the Password field.

Step 9 To send a test email using the configured mail server, click Test Mail Server Settings.

A message appears next to the button indicating the success or failure of the test.

Step 10 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring Network Analysis Policy Preferences

License: Protection

Supported Devices: Any except X-Series

You can configure the system to prompt users for a comment when they modify a network analysis policy. You can use this to track users’ reasons for policy changes. If you enable comments on network analysis policy changes, you can make the comments optional or mandatory. The change description is written to the audit log.

You can also have all network analysis policy changes written to the audit log. For more information on the audit log, see Managing Audit Records.

To configure the network analysis policy comment settings:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the network analysis policy preferences in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the network analysis policy preferences as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Network Analysis Policy Preferences.

The Network Analysis Policy Preferences page appears.

Step 4 From the Comments on policy change drop-down list, you have the following options:

- Select Disabled to allow users to modify a network analysis policy without entering a change description.

- Select Optional to display the Description of Changes window to users when they save changes to a network analysis policy. This allows users the option to describe changes in a comment.

- Select Required to display the Description of Changes window to users when they save changes to a network analysis policy. This requires users to describe changes in a comment before the changes are saved.

Step 5 Optionally, if you want to write all network analysis policy changes to the audit log, select Write changes in Network Analysis Policy to audit log.

Step 6 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring Intrusion Policy Preferences

License: Protection

Supported Devices: Any except X-Series

You can configure the system to prompt users for a comment when they modify an intrusion policy. You can use this to track users’ reasons for policy changes. If you enable comments on intrusion policy changes, you can make the comments optional or mandatory. The change description is written to the audit log.

You can also have all intrusion policy changes written to the audit log. For more information on the audit log, see Managing Audit Records.

To configure the intrusion policy comment settings:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the intrusion policy preferences in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the intrusion policy preferences as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Intrusion Policy Preferences.

The Intrusion Policy Preferences page appears.

Step 4 From the Comments on policy change drop-down list, you have the following options:

- Select Disabled to allow users to modify an intrusion policy without entering a change description.

- Select Optional to display the Description of Changes window to users when they save changes to an intrusion policy. This allows users the option to describe changes in a comment.

- Select Required to display the Description of Changes window to users when they save changes to an intrusion policy. This requires users to describe changes in a comment before the changes are saved.

Step 5 Optionally, if you want to write all intrusion policy changes to the audit log, select Write changes in Intrusion Policy to audit log.

Step 6 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Specifying a Different Language

License: Any

Supported Devices: Any except X-Series

You can use the Language page to specify a different language for the web interface.

Caution The language you select here is used for the web interface for every user who logs into the appliance.

To select a different language for the user interface:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the language settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the language settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Language.

The Language page appears.

Step 4 Select the language you want to use.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Adding a Custom Login Banner

License: Any

Supported Devices: Any except X-Series

You can create a custom login banner that appears when users log into the appliance using SSH and on the login page of the web interface. Banners can contain any printable characters except the less-than symbol (<) and the greater-than symbol (>).

To add a custom banner:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the login banner in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the login banner as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Login Banner.

The Login Banner page appears.

Step 4 In the Custom Login Banner field, enter the login banner you want to use with this system policy.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Configuring SNMP Polling

License: Any

Supported Devices: Any except X-Series

You can enable Simple Network Management Protocol (SNMP) polling of an appliance using the system policy. The SNMP feature supports use of versions 1, 2, and 3 of the SNMP protocol.

This feature allows access to:

- the standard management information base (MIB) for the appliance, which includes system details such as contact, administrative, location, service information, IP addressing and routing information, and transmission protocol usage statistics

- additional MIBs for managed devices that include statistics on traffic passing through physical interfaces, logical interfaces, virtual interfaces, ARP, NDP, virtual bridges, and virtual routers

Note that enabling the system policy SNMP feature does not cause the appliance to send SNMP traps; it only makes the information in the MIBs available for polling by your network management system.

Note You must add SNMP access for any computer you plan to use to poll the appliance. For more information, see Configuring the Access List for Your Appliance. Note that the SNMP MIB contains information that could be used to attack your appliance. Cisco recommends that you restrict your access list for SNMP access to the specific hosts that will be used to poll for the MIB. Cisco also recommends you use SNMPv3 and use strong passwords for network management access.

To configure SNMP polling:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the SNMP polling settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the SNMP polling settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Create.

In either case, the Access List page appears.

Step 3 If you have not already added SNMP access for each computer you plan to use to poll the appliance, do so now. For more information, see Configuring the Access List for Your Appliance.

Step 4 Click SNMP.

The SNMP page appears.

Step 5 From the SNMP Version drop-down list, select the SNMP version you want to use.

The drop-down list displays the version you selected.

Step 6 You have the following options:

- If you selected Version 1 or Version 2 , type the SNMP community name in the Community String field. Go to step 15 .

Note SNMPv2 only supports read-only communities.

- If you selected Version 3 , click Add User to display the user definition page.

Note SNMPv3 only supports read-only users. SNMPv3 also supports encryption with AES128.

Step 7 Enter a username in the Username field.

Step 8 Select the protocol you want to use for authentication from the Authentication Protocol drop-down list.

Step 9 Type the password required for authentication with the SNMP server in the Authentication Password field.

Step 10 Retype the authentication password in the Verify Password field just below the Authentication Password field.

Step 11 Select the privacy protocol you want to use from the Privacy Protocol list, or select None to not use a privacy protocol.

Step 12 Type the SNMP privacy key required by the SNMP server in the Privacy Password field.

Step 13 Retype the privacy password in the Verify Password field just below the Privacy Password field.

Step 14 Click Add.

) to delete a user.

Step 15 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Enabling STIG Compliance

License: Any

Supported Devices: Any except X-Series

Organizations within the United States federal government sometimes need to comply with a series of security checklists set out in Security Technical Implementation Guides (STIGs). The STIG Compliance option enables settings intended to support compliance with specific requirements set out by the United States Department of Defense.

If you enable STIG compliance on any appliances in your deployment, you must enable it on all appliances. Non-compliant managed devices cannot be registered to STIG-compliant Defense Centers and STIG-compliant devices cannot be registered to non-compliant Defense Centers.

Enabling STIG compliance does not guarantee strict compliance to all applicable STIGs. For more information on FireSIGHT System STIG compliance when using this mode for this version of the product, contact Support to obtain a copy of the FireSIGHT System STIG Release Notes for Version 5.4.1.

When you enable STIG compliance, password complexity and retention rules for local shell access accounts change. For more information on these settings, see the FireSIGHT System STIG Release Notes for Version 5.4.1. In addition, you cannot use ssh remote storage when in STIG compliance mode.

Note that applying a system policy with STIG compliance enabled forces appliances to reboot. If you apply a system policy with STIG enabled to an appliance that already has STIG enabled, the appliance does not reboot. If you apply a system policy with STIG disabled to an appliance that has STIG enabled, STIG remains enabled and the appliance does not reboot.

For appliances upgraded from versions earlier than Version 5.2.0, applying a policy with compliance enabled also regenerates appliance certificates, so you will need to re-register already registered managed devices or peers.

Caution You cannot disable this setting without assistance from Support. In addition, this setting may substantially impact the performance of your system. Cisco does not recommend enabling STIG compliance except to comply with Department of Defense security requirements.

To enable STIG compliance:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the time settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the time settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click STIG Compliance.

The STIG Compliance page appears.

Step 4 If you want to permanently enable STIG compliance on the appliance, select Enable STIG Compliance.

Caution You cannot disable STIG compliance on an appliance after you apply a policy with STIG compliance enabled. If you need to disable compliance, contact Support.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

When you apply a system policy that enables STIG compliance to an appliance, note that the appliance reboots. Note that if you apply a system policy with STIG enabled to an appliance that already has STIG enabled, the appliance does not reboot.

In addition, you need to re-register devices after enabling STIG compliance if the devices were upgraded from versions earlier than Version 5.2.0.

Synchronizing Time

License: Any

Supported Devices: Any except X-Series

You can manage time synchronization on the appliance using the Time Synchronization page. You can choose to synchronize the time:

- manually

- using one or more NTP servers (one of which can be a Defense Center)

Time settings are part of the system policy. You can specify the time settings either by creating a new system policy or by editing an existing policy. In either case, the time setting is not used until you apply the system policy.

Note that time settings are displayed on most pages on the appliance in local time using the time zone you set on the Time Zone page (America/New York by default), but are stored on the appliance itself using UTC time. In addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed in the Manual clock setting option, if enabled).

You must use native applications, such as command line interfaces or the operating system interface, to manage time settings for Cisco NGIPS for Blue Coat X-Series. Synchronize time for Cisco NGIPS for Blue Coat X-Series and its managing Defense Center from the same physical appliance or NTP server. For more information, see the Cisco Software for X-Series Installation Guide.

You can synchronize the appliance’s time with an external time server. If you specify a remote NTP server, your appliance must have network access to it. Do not specify an untrusted NTP server. Connections to NTP servers do not use configured proxy settings. To use the Defense Center as an NTP server, see Serving Time from the Defense Center.

Cisco recommends that you synchronize your virtual appliances to a physical NTP server. Do not synchronize your managed devices (virtual or physical) to a Virtual Defense Center.

Note Ensure that the time on your Defense Center and managed devices matches after time synchronization. Otherwise, unintended consequences may occur when the managed devices communicate with the Defense Center.

The procedure for synchronizing time differs slightly depending on whether you are using the web interface on a Defense Center or a managed device. Each procedure is explained separately below.

To synchronize time:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the time settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the time settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Time Synchronization.

The Time Synchronization page appears.

Step 4 If you want to serve time from the Defense Center to your managed devices, in the Serve time via NTP drop-down list, select Enabled.

Step 5 You have the following options for specifying how the time is synchronized on the Defense Center:

- To set the time manually, select Manually in Local Configuration . See Setting the Time Manually for information about setting the time after you apply the system policy.

- To receive time through NTP from a different server, select Via NTP from and, in the text box, type a comma-separated list of IP addresses for the NTP servers you want to use or, if DNS is enabled, type the fully qualified host and domain names.

Caution If the appliance is rebooted and your DHCP server sets an NTP server record different than the one you specify here, the DHCP-provided NTP server will be used instead. To avoid this situation, configure your DHCP server to set the same NTP server.

Step 6 You have the following options for specifying how time is synchronized on any managed devices:

- Select Manually in Local Configuration to set the time manually. See Setting the Time Manually for information about setting the time after you apply the system policy.

- Select Via NTP from Defense Center to receive time through NTP from the Defense Center. See Serving Time from the Defense Center for more information.

- Select Via NTP from to receive time through NTP from different servers. In the text box, type a comma-separated list of IP addresses of the NTP servers or, if DNS is enabled, type the fully qualified host and domain names.

Note It may take a few minutes for the managed device to synchronize with the configured NTP servers. In addition, if you are synchronizing the managed device to a Defense Center that is configured as an NTP server, and the Defense Center itself is configured to use an NTP server, it may take some time for the time to synchronize. This is because the Defense Center must first synchronize with its configured NTP server before it can serve time to the managed device.

Step 7 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy. See Applying a System Policy for more information.

Serving Time from the Defense Center

License: Any

Supported Devices: Any except X-Series

You can configure the Defense Center as a time server using NTP and then use it to synchronize time between the Defense Center and managed devices.

Note that you cannot set the time manually after configuring the Defense Center to serve time using NTP. If you need to manually change the time, you should do so before configuring the Defense Center to serve time using NTP. If you need to change the time manually after configuring the Defense Center as an NTP server, disable the Via NTP option and click Save, change the time manually and click Save, and then enable Via NTP and click Save.

Note If you configure the Defense Center to serve time using NTP, and then later disable it, the NTP service on managed devices still attempts to synchronize time with the Defense Center. You must disable NTP from the managed devices’ web interfaces to stop the synchronization attempts.

To configure the Defense Center as an NTP server:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify the NTP server settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure the NTP server settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Time Synchronization.

The Time Synchronization page appears.

Step 4 From the Serve Time via NTP drop-down list, select Enabled.

Step 5 In the Set My Clock option for the managed device, select Via NTP from Defense Center.

Step 6 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. See Applying a System Policy for more information.

Note It may take a few minutes for the Defense Center to synchronize with its managed devices.

Configuring User Interface Settings

License: Any

Supported Devices: Any except X-Series

Unattended login sessions of the FireSIGHT System web interface or command line interface may be security risks. You can configure, in minutes, the amount of idle time before a user’s login session times out due to inactivity. You can also set a similar timeout for shell (command line) sessions.

Your deployment may have users who plan to passively, securely monitor the web interface for long periods of time. You can exempt users from the web interface session timeout with a user configuration option. (Users with the Administrator role, whose complete access to menu options poses an extra risk if compromised, cannot be made exempt from session timeouts.) For more information, see Managing User Login Settings.

For cases in which you must restrict shell access to the system, a third option allows you to permanently disable the expert command in the command line. Disabling expert mode on an appliance prevents any user, even users with Configuration shell access, from going into expert mode in the shell. When a user goes into expert mode on the command line, the user can run any Linux command appropriate to the shell. When not in expert mode, command line users can only run the commands provided by the command line interface. Note that the command line interface is not supported for Series 2 appliances.

For more information on command line interface commands, see Command Line Reference. For information on setting up users for command line access, see Managing Command Line Access and Command Line Reference (for virtual device CLI user management).

To configure user interface settings:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify user interface settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure user interface settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click User Interface.

The User Interface page appears.

Step 4 You have the following options:

- To configure session timeout for the web interface, type a number (of minutes) in the Browser Session Timeout (Minutes) field. The default value is 60 ; the maximum value is 1440 (24 hours).

For information on how to exempt users from this session timeout, see Managing User Login Settings.

- To configure session timeout for the command line interface, type a number (of minutes) in the Shell Timeout (Minutes) field. The default value is 0 ; the maximum value is 1440 (24 hours).

- To permanently disable the expert command in the command line interface, select the Permanently Disable Expert Access check box.

Caution After you apply a system policy with expert mode disabled to an appliance, you cannot restore the ability to access expert mode through the web interface or the command line. You must contact Support to restore the expert mode capability.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. Changes to session timeout intervals do not take effect until the next login session.

Mapping Vulnerabilities for Servers

License: Protection

Supported Devices: Any except X-Series

The FireSIGHT System automatically maps vulnerabilities to a host IP address for any application protocol traffic received or sent from that address, when the server has an application ID in the discovery event database and the packet header for the traffic includes a vendor and version.

However, many servers do not include vendor and version information. For the server listed in the system policy, you can configure whether the system associates vulnerabilities with server traffic for vendor and versionless servers.

For example, a host serves SMTP traffic that does not have a vendor or version in the header. If you enable the SMTP server on the Vulnerability Mapping page of a system policy, then apply that policy to the Defense Center managing the device that detects the traffic, all vulnerabilities associated with SMTP servers are added to the host profile for the host.

Although detectors collect server information and add it to host profiles, the application protocol detectors will not be used for vulnerability mapping, because you cannot specify a vendor or version for a custom application protocol detector and cannot select the server for vulnerability mapping in the system policy.

To configure vulnerability mapping for servers:

Access: Admin

Step 1 Select System > Local > System Policy.

The System Policy page appears.

Step 2 You have the following options:

- To modify vulnerability mapping settings in an existing system policy, click the edit icon (

) next to the system policy.

- To configure vulnerability mapping settings as part of a new system policy, click Create Policy .

Provide a name and description for the system policy as described in Creating a System Policy, and click Save.

In either case, the Access List page appears.

Step 3 Click Vulnerability Mapping.

The Vulnerability Mapping page appears.

Step 4 You have the following options:

- To prevent vulnerabilities for a server from being mapped to hosts that receive application protocol traffic without vendor or version information, clear the check box for that server.

- To cause vulnerabilities for a server to be mapped to hosts that receive application protocol traffic without vendor or version information, select the check box for that server.

Tip You can select or clear all check boxes at once using the check box next to Enabled.

Step 5 Click Save Policy and Exit.

The system policy is updated. Your changes do not take effect until you apply the system policy to the Defense Center and its managed devices. See Applying a System Policy for more information.

Configuring Appliance Settings

A FireSIGHT System appliance’s local configuration (System > Local > Configuration) is a group of settings that is likely to be specific to a single appliance. Contrast the local configuration with the system policy (Managing System Policies), which controls appliance settings that are likely to be similar across a deployment.

The following table summarizes an appliance’s local configuration.

Table 64-1 Local Configuration Options

Option

Description

For more information, see...

Information

Allows you to view current information about the appliance. You can also change the appliance name.

Viewing and Modifying the Appliance Information

HTTPS Certificate

Allows you to request an HTTPS server certificate, if needed, from a trusted authority and upload certificates to your appliance.

Using Custom HTTPS Certificates

Database

Lets you enable external read-only access to the appliance database, and provides a client driver for you to download.

Enabling Access to the Database

Management Interfaces

Enables you to change options such as the IP address, hostname, and proxy settings of the appliance that were initially set up as part of the installation. You can also view and modify the settings for the management interfaces on your appliance.

Configuring Management Interfaces

Process

Allows you to shut down or reboot the appliance, and restart FireSIGHT System-related processes.

Shutting Down and Restarting the System

Time

Displays the current time. If the time synchronization settings in the current system policy for the appliance is set to Manually in Local Configuration, then you can use this page to change the time.

Setting the Time Manually

Remote Storage Device

On Defense Centers, allows you to configure remote storage for backups and reports.

Managing Remote Storage

Change Reconciliation

Allows you to receive, via email, a detailed report of changes to your system over the last 24 hours.

Understanding Change Reconciliation

Console Configuration

Allows you configure console access to FireSIGHT System appliances via VGA or serial port, or via Lights-Out Management (LOM), which allows you to perform limited monitoring and management tasks without being physically near the appliance.

Managing Remote Console Access

Cloud Services

On Defense Centers, allows you to download URL filtering data from the Collective Security Intelligence Cloud, perform lookups for uncategorized URLs, and send diagnostic information on detected files to Cisco.

Enabling Cloud Communications

VMware Tools

On a virtual Defense Center, allows you to enable and use VMware Tools.

Enabling VMware Tools

Viewing and Modifying the Appliance Information

License: Any

The Information page provides you with information about your appliances. The information includes read-only information, such as the product name and model number, the operating system and version, and the current appliance-level policies. The page also provides you with an option to change the name of the appliance.

The following table describes each field.

Table 64-2 Appliance Information

Field

Description

Name

A name you assign to the appliance. Note that this name is only used within the context of the FireSIGHT System. Although you can use the hostname as the name of the appliance, entering a different name in this field does not change the hostname.

Product Model

The model name for the appliance.

Software Version

The version of the software currently installed.

Serial Number

The chassis serial number of the appliance.

Store Events Only on Defense Center

Select this check box on the managed device to store event data on the Defense Center, but not the managed device. Clear this check box to store event data on both appliances.

Prohibit Packet Transfer to the Defense Center

Select this check box on the managed device to prevent the managed device from sending packet data with the events. Clear this check box to allow packet data to be stored on the Defense Center with events.

Operating System

The operating system currently running on the appliance.

Operating System Version

The version of the operating system currently running on the appliance.

IPv4 Address

The IPv4 address of the default (eth0) management interface of the appliance. If IPv4 management is disabled for the appliance, this field indicates that.

IPv6 Address

The IPv6 address of the default (eth0) management interface of the appliance. If IPv6 management is disabled for the appliance, this field indicates that.

Current Policies

The appliance-level policies currently applied. If a policy has been updated since it was last applied, the name of the policy appears in italics.

Model Number

The model number for the appliance. This number may be important for troubleshooting.

To modify the appliance information:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 To change the appliance name, type a new name in the Name field.

The name must be alphanumeric characters and cannot be composed of numeric characters only.

Step 3 To save your changes, click Save.

The page refreshes and your changes are saved.

Using Custom HTTPS Certificates

License: Any

Cisco Defense Centers and managed devices that support web-based user interfaces include default SSL (Secure Sockets Layer) certificates that you can use to initiate an encrypted communication channel between your web browser and the appliance. However, because the default certificate for an appliance is not generated by a certificate authority (CA) trusted by any globally known CA, you can replace it with a custom certificate signed by a globally known or internally trusted CA.

You can manage certificates through the local configuration for your appliance. For more information, see the following:

- Viewing the Current HTTPS Server Certificate

- Generating a Server Certificate Request

- Uploading Server Certificates

- Requiring User Certificates

Viewing the Current HTTPS Server Certificate

License: Any

You can view details from the server certificate currently in place for your appliance. The certificate provides the following information:

Table 64-3 HTTPS Server Certificate Information

Field

Description

Subject

For the appliance where the certificate is installed, provides the commonName, countryName, organizationName, and organizationalUnitName.

Issuer

For the appliance that issued the certificate, provides the commonName, countryName, organizationName, and organizationalUnitName.

Validity

Indicates the timeframe during which the certificate is valid.

Version

Indicates the certificate version.

Serial Number

Indicates the certificate serial number.

Signature Algorithm

Indicates the algorithm used to sign the certificate.

To view the certificate details:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click HTTPS Certificate.

The HTTPS Certificate page appears, with the details of the current certificate for the appliance.

Generating a Server Certificate Request

License: Any

You can generate a certificate request based on your appliance information and the identification information you supply. You can send the resulting request to a certificate authority to request a server certificate. You can also use it to self-sign a certificate if you have an internal certificate authority (CA) installed that is trusted by your browser. The generated key is in Base-64 encoded PEM format.

Note that when you generate a certificate request through the local configuration HTTPS Certificate page, you can only generate a certificate for a single server. You must type the fully qualified domain name of the server exactly as it should appear in the certificate in the Common Name field. If the common name and the DNS host name do not match, you receive a warning when connecting to the appliance. Similarly, if you install a certificate that is not signed by a globally known or internally trusted CA, you receive a security warning when you connect to the appliance.

To generate a certificate request:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click HTTPS Certificate.

The HTTPS Certificate page appears.

Step 3 Click Generate New CSR.

The Generate Certificate Signing Request pop-up window appears.

Step 4 Type the two-letter country code for your country in the Country Name (two-letter code) field.

Step 5 Type the postal abbreviation for your state or province in the State or Province field.

Step 6 Type the name of your Locality or City.

Step 7 Type your Organization name.

Step 8 Type an Organizational Unit (Department) name.

Step 9 Type the fully qualified domain name of the server for which you want to request a certificate in the Common Name field, exactly as you want it to appear in the certificate.

Step 10 Click Generate.

The Certificate Signing Request pop-up window appears.

Step 11 Open a text editor.

Step 12 Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST lines, and paste it into a blank text file.

Step 13 Save the file as servername.csr, where servername is the name of the server where you plan to use the certificate.

Step 14 Upload the CSR file to the certificate authority where you want to request a certificate or use the CSR to create a self-signed certificate.

Uploading Server Certificates

License: Any

After you have a signed certificate from a certificate authority (CA), you can upload it. If the signing authority that generated the certificate requires you to trust an intermediate CA, you must also supply a certificate chain, sometimes referred to as a certificate path. If you require user certificates, they must be generated by a certificate authority whose intermediate authority is included in the certificate chain.

To upload a certificate:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click HTTPS Certificate.

The HTTPS Certificate page appears.

Step 3 Click Import HTTPS Certificate.

The Import HTTPS Certificate pop-up window appears.

Step 4 Open the server certificate in a text editor, copy the entire block of text, including the BEGIN CERTIFICATE and END CERTIFICATE lines, and paste it into the Server Certificate field.

Step 5 Optionally, open the private key file, copy the entire block of text, including the BEGIN RSA PRIVATE KEY and END RSA PRIVATE KEY lines, and paste it into the Private Key field.

Step 6 Open any intermediate certificates you need to provide, copy the entire block of text, for each, and paste it into the Certificate Chain field.

Step 7 Click Save to upload the certificate.

The certificate uploads and the HTTPS Certificate page updates to reflect the new certificate.

Requiring User Certificates

License: Any

You can restrict access to the FireSIGHT System web server using client browser certificate checking. When you enable user certificates, the web server checks that a user’s browser client has a valid user certificate selected. That user certificate must be generated by the same trusted certificate authority used for the server certificate. If the user selects a certificate in the browser that is not valid or not generated by a certificate authority in the certificate chain on the device, the browser cannot load the web interface.

You can also load a certificate revocation list (CRL) for the server. The CRL lists any certificates that have been revoked by the certificate authority, so the web server can verify that the client browser certificate has not been revoked. If the user selects a certificate that is listed in the CRL as a revoked certificate, the browser cannot load the web interface. The appliance supports upload of CRLs in Distinguished Encoding Rules (DER) format. You can only load one CRL for a server.

To ensure that the list of revoked certificates stays current, you can create a scheduled task to update the CRL. The most recent refresh of the CRL is listed in the interface.

Make sure you use the same certificate authority used for the server certificate and that you have uploaded the intermediate certificate for the certificates. For more information, see Uploading Server Certificates.

Note You must have a valid user certificate present in your browser (or a CAC inserted in your reader) to enable user certificates and to access the web interface after doing so.

To require valid user certificates:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click HTTPS Certificate.

The HTTPS Certificate page appears.

Step 3 Select Enable User Certificates. If prompted, select the appropriate certificate from the drop-down list.

The Enable Fetching of CRL option appears.

Step 4 Optionally, select Enable Fetching of CRL.

The remaining CRL configuration options appear.

Step 5 Type a valid URL to an existing CRL file and click Refresh CRL.

The current CRL at the supplied URL loads to the server.

Note Enabling fetching of the CRL creates a scheduled task to update the CRL on a regular basis. Edit the task to set the frequency of the update. For more information, see Automating Certificate Revocation List Downloads.

Step 6 Verify that you have a valid user certificate generated by the same certificate authority that created the server certificate.

Caution When you save a configuration with enabled user certificates, if you do not have a valid user certificate in your browser certificate store, you disable all web server access to the appliance. Make sure you have a valid certificate installed before saving settings.

Step 7 To apply the user certificate configuration to the web server, click Save.

Note that you can disable user certificate enforcement via the command line if you enable certificates and find that your user certificate does not enable access. For more information, see disable-http-user-cert.

Enabling Access to the Database

License: Any

You can configure the Defense Center to allow read-only access to its database by a third-party client. This allows you to query the database using SQL using any of the following:

- industry-standard reporting tools such as Actuate BIRT, JasperSoft iReport, or Crystal Reports

- any other reporting application (including a custom application) that supports JDBC SSL connections

- the Cisco-provided command-line Java application called RunQuery, which you can either run interactively or use to obtain comma-separated results for a single query

From the Database Settings local configuration page, you can enable database access and create an access list that allows selected hosts to query the database. Note that this access list does not also control appliance access. For more information on appliance access lists, see Configuring the Access List for Your Appliance.

You can also download a package that contains the following:

- RunQuery, the Cisco-provided database query tool

- InstallCert, a tool you can use to retrieve and accept the SSL certificate from the Defense Center you want to access

- the JDBC driver you must use to connect to the database

Note that when you connect to the database from an external client you must provide a username and password that match those for an Administrator or External Database user on the Defense Center. For more information, see Adding New User Accounts.

For detailed information on configuring external access to the FireSIGHT System database, including information on the database schema and supported queries, see the FireSIGHT System Database Access Guide.

To enable database access:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Database.

The Database Settings page appears.

Step 3 Select the Allow External Database Access check box.

The Access List field appears. See step 6 for more information.

Step 4 Type the fully qualified domain name (FQDN), IPv4 address, or IPv6 address of the Defense Center in the Server Hostname field, depending on your third-party application requirements.

If you type a FQDN, you must make sure that the client can resolve the FQDN of the Defense Center. If you type an IP address, you must make sure that the client can connect to the Defense Center using the IP address.

Step 5 Next to Client JDBC Driver, click Download and follow your browser’s prompts to download the client.zip package.

See the FireSIGHT System Database Access Guide for information on using the tools in the package you downloaded to configure database access.

Step 6 To add database access for one or more IP addresses, click Add Hosts.

An IP Address field appears in the Access List field.

Step 7 In the IP Address field, you have the following options, depending on the IP addresses you want to add:

- an exact IP address (for example, 192.168.1.101)

- an IP address block using CIDR notation (for example, 192.168.1.1/24)

For information on using CIDR in the FireSIGHT System, see IP Address Conventions.

- any , to designate any IP address

Step 8 Click Add.

The IP address is added to the database access list.

).

Step 10 Click Save.

Your database access settings are saved.

Tip Click Refresh to revert to the last saved database settings.

Configuring Management Interfaces

License: Any

When you first set up an appliance, you configure its network settings so that it can communicate on your internal, protected management network. You can change any network settings you created when you first set up your appliance and configure additional network settings, such as proxies. On Series 3 appliances and virtual Defense Centers, you can enable traffic channels and configure additional management interfaces to improve performance, and create routes to manage and isolate traffic between the Defense Center and devices on different networks. On Series 3 devices, you can also enable or disable LCD panel access on the device. To change these settings and to configure additional network settings such as proxies, use the Management Interfaces page (System > Local > Configuration, then click Management Interfaces).

Note You must use command-line tools to modify network and proxy settings for virtual devices, and to modify network settings for Cisco NGIPS for Blue Coat X-Series. Note that Cisco NGIPS for Blue Coat X-Series does not support a proxy. For more information, see the FireSIGHT System Virtual Installation Guide and the Cisco NGIPS for Blue Coat X-Series Installation and Configuration Guide.

See the following sections for configuration options and procedures:

- Understanding Management Interface Options

- Editing Management Interfaces

Understanding Management Interface Options

You may want to change your settings to improve performance, enable different functionality, or otherwise alter the network configuration in your deployment. On Series 3 appliances, you can also configure traffic channels, enable an additional management interface, and create a route to isolate traffic from devices on different networks. For more information, see Understanding Management Interfaces.

Interfaces

The FireSIGHT System provides a dual stack implementation for both IPv4 and IPv6 management environments. You can choose one or both protocols; disable the protocol (if any) you do not want to use.

For each management protocol, you must specify the IP address of the default (eth0) management interface, a netmask or prefix length, and the default gateway. You can either set these manually or configure the appliance to retrieve them from a local DHCP server or IPv6 router. Note that you must manually configure each additional (eth1 and so on) management interface that you enable.

You can configure the following options on your management interface:

- Enabled - enables the management interface. Do not disable the default management interface until after you have already enabled and saved another management interface.

- Channels - enables the Management Traffic and Event Traffic channels on the interface.

You can enable the traffic channels (management traffic, event traffic, or both) to create different connections in the communication channel on the management interface. In addition, you can separate traffic channels over multiple management interfaces, combining the throughput of both interfaces to further improve performance. For more information, see Understanding Management Interfaces.

- Mode - allows you to change the default Autonegotiation or specify a link mode. Note that any changes you make to the Auto Negotiate value are ignored for Gigabit interfaces.

Note that when you register an 8000 Series managed device to your Defense Center, you must either auto-negotiate on both sides of the connection, or set both sides to the same static speed to ensure a stable network link. 8000 Series managed devices do not support half duplex network links; they also do not support differences in speed or duplex configurations at opposite ends of a connection.

- MTU - allows you to change the default setting.

Note Unlike other interfaces, changing the maximum transmission unit (MTU) on a management interface does not interrupt traffic.

The following table lists MTU configuration ranges for management interfaces:

Table 64-4 Management Interface MTU Range by Device

On the Model Device...

the MTU range is....

Series 2 except 3D6500 and 3D9900

576-1518

3D6500, 3D9900, virtual

576-9018

Series 3 default (eth0)

576-9234

Series 3 non-default (eth1 and so on)

1518-9018

Because the system automatically trims 18 bytes from the configured MTU value, any value below 1298 does not comply with the minimum IPv6 MTU setting of 1280, and any value below 594 does not comply with the minimum IPv4 MTU setting of 576. For example, the system automatically trims a configured value of 576 to 558.

- MDI/MDIX - allows you to change the default Auto-MDIX setting.

- IPv4 Configuration - allows you to configure select Static , DHCP , or Disabled .

– Select Static to enter the IPv4 management IP address and netmask.

– Select DHCP to retrieve network settings from a DHCP server. (eth0 only)

– Select Disabled to disable the protocol. Do not disable both IPv4 and IPv6.

- IPv6 Configuration - allows you to configure Static , DHCP , Router Assigned , or Disabled .

– Select Static to enter the IPv4 management IP address and netmask.

– Select DHCP to retrieve network settings from a DHCP server. (eth0 only)

– Select Router Assigned to retrieve network settings from a local IPv6 router.

– Select Disabled to disable the protocol. Do not disable both IPv4 and IPv6.

Routes

You can view or edit the route to your default management interface when you click the Edit icon, or view the route statistics when you click the View icon.

You can create a new route to an additional network. Click the Add icon to display a pop-up window where you can enter the destination network IP address, netmask or prefix length, interface dropdown (eth0 and so on) and the gateway. The following examples show some ways you can use a route to a different network:

- On a Defense Center, you can create a route to a device on a different network to allow one Defense Center to manage and isolate traffic from devices on different networks.

- On a device, you can create a route and register your device to Defense Centers on two different networks to configure high availability for Defense Centers over a wider deployment.

You can configure the following settings on a specific management interface to create a route to a network:

- Destination - the destination address of the network to which you want to create a route.

- Netmask or Prefix Length - the netmask (IPv4) or prefix length (IPv6) for the network

- Interface - the management interface on the appliance assigned to the new route.

- Gateway - the gateway for the new network.

Shared Settings

Regardless of your management environment, you can specify up to three DNS servers, as well as the host name and domain for the device.

You can change the management port. FireSIGHT System appliances communicate using a two-way, SSL-encrypted communication channel, which by default is on port 8305. Although Cisco strongly recommends that you keep the default setting, if the management port conflicts with other communications on your network, you can choose a different port.

Caution If you change the management port, you must change it for all appliances in your deployment that need to communicate with each other.

LCD Panel

Series 3 devices allow you view device information using an LCD panel on the front of the device. On the Series 3 Management Interfaces page, you can allow people to change network settings using the LCD panel.

If you edit the IP address of a managed device using the LCD panel, confirm that the changes are reflected on the managing Defense Center. In some cases, you may need to edit the device management settings manually. For more information, see Editing Device Management Settings.

Caution Allowing reconfiguration using the LCD panel can present a security risk. You need only physical access, not authentication, to configure network settings using the LCD panel.

Proxy

All FireSIGHT System appliances are configured to directly connect to the Internet on ports 443/tcp (HTTPS) and 80/tcp (HTTP); see Security, Internet Access, and Communication Ports. With the exception of Cisco NGIPS for Blue Coat X-Series, FireSIGHT System appliances support the use of a proxy server, to which you can authenticate via HTTP Digest.

Caution Proxies that use NT LAN Manager (NTLM) authentication cannot communicate with the Collective Security Intelligence Cloud to receive information. Make sure to configure a different authentication for your proxy if you want to use cloud-based features. For more information, see Enabling Cloud Communications.

Editing Management Interfaces

License: Any

You can use the Management Interfaces page to modify the default settings for the default management interface on your Defense Center. On Series 3 appliances and virtual Defense Centers, you can also enable and configure traffic channels and additional management interfaces. Any changes you make to the Auto Negotiate value are ignored for Gigabit interfaces.

Caution Do not modify the settings for the management interface unless you have physical access to the appliance. It is possible to select a setting that makes it difficult to access the web interface.

To edit a management interface:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Management Interfaces.

The Management Interfaces page appears, listing the current settings for each interface on your Defense Center.

Step 3 Optionally, under Interfaces, click Edit next to the interface that you want to configure.

You can modify the default management interface (eth0) or enable and configure an additional management interface (eth1 and so on). For each additional management interface, you must assign a unique, static IP address (IPv4 or IPv6) or hostname. You can select which traffic channels to carry, in addition to setting the mode, link, MTU, and IP configuration.

Step 4 Optionally, under Routes, enter the destination network IP address, netmask or prefix length, and gateway, and specify the management interface you want to use for this network route.

You can also view the route statistics when you click the magnifying glass icon.

Step 5 Optionally, under Shared Settings, specify network settings that do not depend on the management network protocol.

You can specify up to three DNS servers, as well as the host name and domain for the appliance. Note that if you selected DHCP in the previous step, you cannot manually specify these shared settings.

Caution Cisco strongly recommends that you keep the default setting, but if the management port conflicts with other communications on your network, you can choose a different port. If you change the management port, you must change it for all appliances in your deployment that need to communicate with each other.

Step 6 Optionally, on Series 3 devices, under LCD Panel, select the Allow reconfiguration of network settings check box to enable changing network settings using the device’s LCD panel.

Caution Allowing reconfiguration using the LCD panel can present a security risk. You need only physical access, not authentication, to configure network settings using the LCD panel. The web interface warns you that enabling this option is a potential security issue.

Step 7 Optionally, under Proxy, select the check box to enable proxy, and then:

- Enter the IP address or fully qualified domain name of your proxy server in the HTTP Proxy field. Enter the port in the Port field.

- Optionally, supply authentication credentials by selecting Use Proxy Authentication then providing a User Name and Password .

Step 8 When you are finished configuring the appliance’s network settings, click Save.

The network settings are changed. If you changed the appliance’s hostname, the new name is not reflected in the syslog until after you reboot the appliance.

Shutting Down and Restarting the System

License: Any

You have several options for controlling the processes on your appliance. You can:

- shut down the appliance

Caution Do not shut off appliances using the power button; it may cause a loss of data. Shut down appliances completely via the Appliance Process page.

- reboot the appliance

- restart communications, database, and HTTP server processes on the appliance (this is typically used during troubleshooting)

- restart the Snort process

Caution Restarting the Snort process temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic.

To shut down or restart your appliance:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Process.

The Appliance Process page appears.

Step 3 Specify the command you want to perform:

On Defense Centers:

- To shut down the appliance, click Run Command next to Shutdown Defense Center .

- To reboot the appliance, click Run Command next to Reboot Defense Center . Note that this logs you out of the Defense Center.

- To restart the appliance, click Run Command next to Restart Defense Center Console . Note that restarting the Defense Center may cause deleted hosts to reappear in the network map.

Note When you reboot your Defense Center, the system runs a database check that can take up to an hour to complete.

On managed devices:

- To shut down the appliance, click Run Command next to Shutdown Appliance .

- To reboot the appliance, click Run Command next to Reboot Appliance . Note that this logs you out of the device.

- To restart the appliance, click Run Command next to Restart Appliance Console .

- To restart the Snort process, click Run Command next to Restart Snort .

Note When you reboot your managed device, the system runs a database check that can take up to an hour to complete.

Setting the Time Manually

License: Any

If the Time Synchronization setting in the currently applied system policy is set to Manually in Local Configuration, then you can manually set the time for the appliance using the Time page in the local configuration.

You must use native applications, such as command line interfaces or the operating system interface, to manage time settings for Cisco NGIPS for Blue Coat X-Series. For more information, see the Cisco NGIPS for Blue Coat X-Series Installation Guide.

If the appliance is synchronizing its time based on NTP, you cannot change the time manually. Instead, the NTP Status section on the Time page provides the following information:

Table 64-5 NTP Status

Column

Description

NTP Server

The IP address and name of the configured NTP server.

Status

The status of the NTP server time synchronization. The following states may appear:

- Being Used indicates that the appliance is synchronized with the NTP server.

- Available indicates that the NTP server is available for use, but time is not yet synchronized.

- Not Available indicates that the NTP server is in your configuration, but the NTP daemon is unable to use it.

- Pending indicates that the NTP server is new or the NTP daemon was recently restarted. Over time, its value should change to Being Used , Available , or Not Available .

- Unknown indicates that the status of the NTP server is unknown.

Offset

The number of milliseconds of difference between the time on the appliance and the configured NTP server. Negative values indicate that the appliance is behind the NTP server, and positive values indicate that it is ahead.

Last Update

The number of seconds that have elapsed since the time was last synchronized with the NTP server. The NTP daemon automatically adjusts the synchronization times based on a number of conditions. For example, if you see larger update times such as 300 seconds, that indicates that the time is relatively stable and the NTP daemon has determined that it does not need to use a lower update increment.

See Synchronizing Time for more information about the time settings in the system policy.

To manually configure the time:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Time.

The Time page appears.

Step 3 Select the following from the Set Time drop-down lists:

- year

- month

- day

- hour

- minute

Step 4 Click Apply.

The time is updated. For information about changing your time zone, see Setting Your Default Time Zone.

Managing Remote Storage

License: Any

On Defense Centers, you can use local or remote storage for backups and reports. You can use Network File System (NFS), Secure Shell (SSH), or Server Message Block (SMB)/Common Internet File System (CIFS) for backup and report remote storage. You cannot send backups to one remote system and reports to another, but you can choose to send either to a remote system and store the other on the local Defense Center. For information on backup and restore, see Using Backup and Restore.

Tip After configuring and selecting remote storage, you can switch back to local storage only if you have not increased the connection database limit.

You must ensure that your external remote storage system is functional and accessible from the Defense Center.

Select one of the backup and report storage options:

- To disable external remote storage and use the local Defense Center for backup and report storage, see Using Local Storage.

- To use NFS for backup and report storage, see Using NFS for Remote Storage.

- To use secure shell (SCP) via SSH for backup and report storage, see Using SSH for Remote Storage.

- To use SMB for backup and report storage, see Using SMB for Remote Storage.

Note You cannot use remote backup and restore to manage data on Cisco NGIPS for Blue Coat X-Series.

Using Local Storage

License: Any

You can store backups and reports on the local Defense Center.

To store backups and reports locally:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Remote Storage Device.

The Remote Storage Device page appears.

Step 3 Select Local (No Remote Storage) from the Storage Type drop-down list.

Step 4 Click Save.

Your storage location choice is saved.

Tip You do not use the Test button with local storage.

Using NFS for Remote Storage

License: Any

You can select Network File System (NFS) protocol to store your reports and backups. Optionally, select the Use Advanced Options check box to use one of the mount binary options as documented in an NFS mount man page.

To store backups and reports using NFS:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Remote Storage Device.

The Remote Storage Device page appears.

Step 3 Select NFS from the Storage Type drop-down list.

The page refreshes to display the NFS storage configuration options.

Step 4 Add the connection information:

- Enter the IPv4 address or hostname of the storage system in the Host field.

- Enter the path to your storage area in the Directory field.

Step 5 If there are any required command line options, select Use Advanced Options.

A Command Line Options field appears where you can enter mount binary options.

Step 6 Under System Usage, select either or both of the following:

- Select Use for Backups to store backups on the designated host.

- Select Use for Reports to store reports on the designated host.

- Enter Disk Space Threshold for backup to remote storage. Default is 90%.

Step 7 Optionally, click Test.

The test ensures that the Defense Center can access the designated host and directory.

Step 8 Click Save.

Your remote storage configuration is saved.

Using SSH for Remote Storage

License: Any

You can select SSH to use secure copy (SCP) to store your reports and backups. Optionally, select the Use Advanced Options check box to use one of the mount binary options as documented in a SSH mount man page.

Caution If you enable STIG compliance on an appliance, you cannot use SSH for remote storage for that appliance. For more information, see Enabling STIG Compliance.

To store backups and reports using SSH:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Remote Storage Device.

The Remote Storage Device page appears.

Step 3 At Storage Type, select SSH.

The page refreshes to display the SCP via SSH storage configuration options.

Step 4 Add the connection information:

- Enter the IP address or hostname of the storage system in the Host field.

- Enter the path to your storage area in the Directory field.

- Enter the storage system’s user name in the Username field and the password for that user in the Password field. To specify a domain, precede the user name with the domain followed by a forward slash (/).

- To use SSH keys, copy the content of the SSH Public Key field and place it in your authorized_keys file.

Step 5 If there are any required command line options, select Use Advanced Options.

A Command Line Options field appears where you can enter mount binary options.

Step 6 Under System Usage, select either or both of the following:

- Select Use for Backups to store backups on the designated host.

- Select Use for Reports to store reports on the designated host.

Step 7 Optionally, click Test.

The test ensures that the Defense Center can access the designated host and directory.

Step 8 Click Save.

Your remote storage configuration is saved.

Using SMB for Remote Storage

License: Any

You can select Server Message Block (SMB) protocol to store your reports and backups. Optionally, select the Use Advanced Options check box to use one of the mount binary options, as documented in an SMB mount man page. For example, using SMB, you can enter the security mode in the Command Line Options field using the following format:

sec=mode

where mode is the security mode you want to use for remote storage. See the Security Mode Settings table for setting options.

Table 64-6 Security Mode Settings

Mode

Description

[none]

Attempt to connect as null user (no name).

krb5

Use Kerberos version 5 authentication.

krb5i

Use Kerberos authentication and packet signing.

ntlm

Use NTLM password hashing. (Default)

ntlmi

Use NTLM password hashing with signing (may be Default if /proc/fs/cifs/PacketSigningEnabled is on or if server requires signing).

ntlmv2

Use NTLMv2 password hashing.

ntlmv2i

Use NTLMv2 password hashing with packet signing.

To store backups and reports using SMB:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Remote Storage Device.

The Remote Storage Device page appears.

Step 3 Under Storage Type, select SMB.

The page refreshes to display the SMB storage configuration options.

Step 4 Add the connection information:

- Enter the IPv4 address or hostname of the storage system in the Host field.

- Enter the share of your storage area in the Share field. Note that the system only recognizes top-level shares and not full file paths. To use the specified Share directory as a remote backup destination, it must be shared on the Windows system.

- Optionally, enter the domain name for the remote storage system in the Domain field.

- Enter the user name for the storage system in the Username field and the password for that user in the Password field.

Step 5 If there are any required command line options, select Use Advanced Options.

A Command Line Options field appears where you can enter the mount binary commands, such as security modes. See Security Mode Settings for more information.

Step 6 Under System Usage, select either or both of the following:

- Select Use for Backups to store backups on the designated host.

- Select Use for Reports to store reports on the designated host.

Step 7 Optionally, click Test.

The test ensures that the Defense Center can access the designated host and directory.

Step 8 Click Save.

Your remote storage configuration is saved.

Understanding Change Reconciliation

License: Any

To monitor the changes that users make and ensure that they follow your organization’s preferred standard, you can configure your system to send, via email, a detailed report of changes made to your system over the past 24 hours. Whenever a user saves changes to the system configuration, a snapshot is taken of the changes. The change reconciliation report combines information from these snapshots to present a clear summary of recent system changes.

The following sample graphic displays a User section of an example change reconciliation report and lists both the previous value for each configuration and the value after changes. When users make multiple changes to the same configuration, the report lists summaries of each distinct change in chronological order, beginning with the most recent.

You can view changes made during the previous 24 hours. However, to view prior changes, you must view the audit log. See Using the Audit Log to Examine Changes for more information.

To use the change reconciliation feature:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Change Reconciliation.

The Change Reconciliation page appears.

Step 3 Select the Enable check box.

Step 4 Select the time of day you want the system to send out the change reconciliation report from the Time to Run drop-down lists.

Step 5 In the Email to field, enter the email addresses of report recipients. At any time, you can click Resend Last Report to send recipients another copy of the most recent change reconciliation report.

Note To receive change reconciliation reports, you must first configure a mail relay host and notification address. For more information, see Configuring a Mail Relay Host and Notification Address.

Step 6 Optionally, select Include Policy Configuration to include records of policy changes in the change reconciliation report. This includes changes to access control, intrusion, system, health, and network discovery policies. If you do not select this option, the report will not show changes to any policies.

Note This option is not available on managed devices.

Step 7 Optionally, select Show Full Change History to include records of all changes over the past 24 hours in the change reconciliation report. If you do not select this option, the report includes only a consolidated view of changes for each category.

Step 8 Click Save.

Your changes are saved. The report runs daily at the time you selected.

Managing Remote Console Access

License: Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

You can use a Linux system console for remote access on any appliance via either the VGA port (which is the default) or the serial port on the physical appliance. Choose the option most suitable to the physical layout of your organization’s Cisco deployment.

You can use Lights-Out Management (LOM) on the default (eth0) management interface on a Serial Over LAN (SOL) connection to remotely monitor or manage Series 3 appliances without logging into the management interface of the appliance. You can perform limited tasks, such as viewing the chassis serial number or monitoring such conditions as fan speed and temperature, using a command line interface on an out-of-band management connection. Series 2, virtual appliances, ASA FirePOWER module, and Cisco NGIPS for Blue Coat X-Series do not support LOM.

You must enable LOM for both the appliance and the user you want to manage the appliance. After you enable the appliance and the user, you use a third-party Intelligent Platform Management Interface (IPMI) utility to access and manage your appliance.

Note The baseboard management controller (BMC) for a 3D71xx, 3D82xx, or a 3D83xx device is only accessible via 1Gbps link speeds when the host is powered on. When the device is powered down the BMC can only establish Ethernet link at 10 and 100Mbps. Therefore if LOM is being used to remotely power the device, connect the device to the network using 10 and 100Mbps link speeds only.

For more information, see the following topics:

- Configuring Remote Console Settings on the Appliance

- Enabling Lights-Out Management User Access

- Using a Serial Over LAN Connection

- Using Lights-Out Management

Configuring Remote Console Settings on the Appliance

License: Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Use the web interface of the appliance you want to remotely manage to select and configure the remote console access option you want to use.

Note that Series 2, virtual appliances, ASA FirePOWER module, and Cisco NGIPS for Blue Coat X-Series do not support LOM.

Note Before you can connect to a Series 3 device using LOM/SOL, you must disable Spanning Tree Protocol (STP) on any third-party switching equipment connected to the device’s management interface.

To configure remote console settings:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Select Console Configuration.

The Console Configuration page appears.

Step 3 Select a remote console access option:

- Select VGA to use the appliance’s VGA port. This is the default option.

- Select Physical Serial Port to use the appliance’s serial port, or to use LOM/SOL on a Series 3 Defense Center, 3D7050, or 8000 Series device.

Note that 3D2100, 3D2500, 3D3500, and 3D4500 managed devices do not have serial ports.

- Select Lights-Out Management to use LOM/SOL on a 7000 Series device (except the 3D7050). On these devices, you cannot use SOL and a regular serial connection at the same time.

If you selected Physical Serial Port or Lights-Out Management, the LOM settings appear.

Note When you change your remote console from Physical Serial Port to Lights-Out Management or from Lights-Out Management to Physical Serial Port on the 70xx Family of devices (except the 3D7050), you may have to reboot the appliance twice to see the expected boot prompt.

Step 4 To configure LOM via SOL, enter the appropriate settings:

- DHCP Configuration for the appliance ( DHCP or Static )

- IP Address to be used for LOM

Note The LOM IP address must be different from the management interface IP address of the appliance.

- the Netmask for the appliance

- the Default Gateway for the appliance

Step 5 Click Save.

Remote console configuration for the appliance is saved. If you configured Lights-Out Management, you must enable it for at least one user; see Enabling Lights-Out Management User Access.

Enabling Lights-Out Management User Access

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3

You must explicitly grant Lights-Out Management permissions to users who will use the feature. You configure LOM and LOM users on a per-appliance basis using each appliance’s local web interface. That is, you cannot use the Defense Center to configure LOM on a managed device. Similarly, because users are managed independently per appliance, enabling or creating a LOM-enabled user on the Defense Center does not transfer that capability to users on managed devices.

LOM users also have the following restrictions:

- You must assign the Administrator role to the user.

- The username may have up to 16 alphanumeric characters. Hyphens and longer user names are not supported for LOM users.

- The password may have up to 20 alphanumeric characters, except for 3D7100 Family devices. If LOM is enabled on a 3D7110, 3D7115, 3D7120, or 3D7125 device, the password may have up to 16 alphanumeric characters. Passwords longer than 20 or 16 characters, respectively, are not supported for LOM users. A user’s LOM password is the same as that user’s system password. Cisco recommends that you use a complex, non-dictionary-based password of the maximum supported length for your appliance and change it every three months.

- Series 3 Defense Centers and 8000 Series devices can have up to 13 LOM users. 7000 Series devices can have up to eight LOM users.

Note that if you deactivate, then reactivate, a role with LOM while a user with that role is logged in, or restore a user or user role from a backup during that user’s login session, that user must log back into the web interface to regain access to IPMItool commands. For more information, see Managing Predefined User Roles.

To enable or view Lights-Out Management user access:

Access: Admin

Step 1 Select System > Local > User Management.

The User Management page appears.

Step 2 You have the following options:

- To grant LOM user access to an existing user, click the edit icon (

) next to a user name in the list.

- To grant LOM user access to a new user, click Create User .

Step 3 Under User Configuration, enable the Administrator role.

Administrator Options appear.

Step 4 Select the Allow Lights-Out Management Access check box.

Step 5 Click Save.

The user has LOM access for this appliance.

Using a Serial Over LAN Connection

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3

You use a third-party IPMI utility on your computer to create a Serial Over LAN connection to the appliance. If your computer uses a Linux-like or Mac environment, use IPMItool; for Windows environments, use IPMIutil.

Note Cisco recommends using IPMItool version 1.8.12 or greater.

Linux

IPMItool is standard with many distributions and is ready to use.

Mac

You must install IPMItool on a Mac. First, confirm that your Mac has Apple's XCode Developer tools installed, making sure that the optional components for command line development are installed (UNIX Development and System Tools in newer versions, or Command Line Support in older versions). Then you can install macports and the IPMItool. Use your favorite search engine for more information or try these sites:

https://developer.apple.com/technologies/tools/

http://www.macports.org/

Windows

You must compile IPMIutil on Windows. If you do not have access to a compiler, you can use IPMIutil itself to compile. Use your favorite search engine for more information or try this site:

http://ipmiutil.sourceforge.net/

Understanding IPMI Utility Commands

Commands used for IPMI utilities are composed of segments as in the following IPMItool example:

ipmitool -I lanplus -H IP_address -U user_name command

where:

– ipmitool invokes the utility

– -I lanplus enables encryption for the session

– -H IP_address indicates the IP address of the appliance you want to access

– -U user_name is the name of an authorized user

– -command is the name of the command you want to give

Note Cisco recommends using IPMItool version 1.8.12 or greater.

The same command for Windows looks like this:

ipmiutil command -V 4 -J 3 -N IP_address -U user_name

This command connects you to the command line on the appliance where you can log in as if you were physically present at the appliance. You may be prompted to enter a password.

To create a Serial Over LAN connection:

Access: Admin with LOM access

Step 1 Enter the following command:

For IPMItool:

ipmitool -I lanplus -H IP_address -U user_name sol activate

Note Cisco recommends using IPMItool version 1.8.12 or greater.

For IPMIutil:

ipmiutil -J 3 -H IP_address -U username sol -a

The command line login for the appliance appears. You may be prompted to enter a password.

Using Lights-Out Management

License: Any

Supported Devices: Series 3

Supported Defense Centers: Series 3

Lights-Out Management provides the ability to perform a limited set of actions over an SOL connection on the default (eth0) management interface without the need to log into the appliance. You use the command to create a SOL connection followed by one of the commands listed in the following table. After the command is completed, the connection ends. Note that not all power control commands are valid on 70xx Family devices.

Note The baseboard management controller (BMC) for a 3D71xx, 3D82xx, or a 3D83xx device is only accessible via 1Gbps link speeds when the host is powered on. When the device is powered down the BMC can only establish Ethernet link at 10 and 100Mbps. Therefore if LOM is being used to remotely power the device, connect the device to the network using 10 and 100Mbps link speeds only.

Caution In rare cases, if your computer is on a different subnet than the appliance's management interface and the appliance is configured for DHCP, attempting to access LOM features on a Series 3 appliance can fail. If this occurs, you can either disable and then re-enable LOM on the appliance, or use a computer on the same subnet as the appliance to ping its management interface. You should then be able to use LOM.

Caution Cisco is aware of a vulnerability inherent in the Intelligent Platform Management Interface (IPMI) standard (CVE-2013-4786). Enabling Lights-Out Management (LOM) on an appliance exposes this vulnerability. To mitigate this vulnerability, deploy your appliances on a secure management network accessible only to trusted users and use a complex, non-dictionary-based password of the maximum supported length for your appliance and change it every three months. To prevent exposure to this vulnerability, do not enable LOM.

If all attempts to access your appliance have failed, you can use LOM to restart your appliance remotely. Note that if a system is restarted while the SOL connection is active, the LOM session may disconnect or time out.

Caution Do not restart your appliance unless it does not respond to any other attempts to restart. Remotely restarting the appliance does not gracefully reboot the system and you may lose data.

.

Table 64-7 Lights-Out Management Commands

IPMItool

IPMIutil

Description

(not applicable)

-V 4

Enables admin privileges for the IPMI session

-I lanplus

-J 3

Enables encryption for the IPMI session

-H

-N

Indicates the IP address of the remote appliance

-U

-U

Indicates the username of an authorized LOM account

sol activate

sol -a

Starts the SOL session

sol deactivate

sol -d

Ends the SOL session

chassis power cycle

power -c

Restarts the appliance (not valid on 70xx Family devices)

chassis power on

power -u

Powers up the appliance

chassis power off

power -d

Powers down the appliance (not valid on

70xx Family devices)

sdr

sensor

Displays appliance information, such as fan speeds and temperatures

For example, to display a list of appliance information, the IPMItool command is:

ipmitool -I lanplus -H IP_address -U user_name sdr

Note Cisco recommends using IPMItool version 1.8.12 or greater.

The same command with the IPMIutil utility is:

ipmiutil sensor -V 4 -J 3 -N IP_address -U user_name

To use Lights-Out Management:

Access: Admin with LOM access

Step 1 Enter the following command:

For IPMItool:

ipmitool -I lanplus -H IP_address -U user_name command

Note Cisco recommends using IPMItool version 1.8.12 or greater.

For IPMIutil:

ipmiutil -J 3 -H IP_address -U username command

where command is one of the commands from the Lights-Out Management Commands table.

The corresponding action as noted in the table is performed. You may be prompted to enter a password.

Enabling Cloud Communications

License: URL Filtering or Malware

Supported Defense Centers: Any except DC500

The FireSIGHT System contacts Cisco’s Collective Security Intelligence Cloud to obtain various types of information:

- If your organization has a FireAMP subscription, you can receive endpoint-based malware events; see Working with Cloud Connections for FireAMP.

- File policies associated with access control rules allow managed devices to detect files transmitted in network traffic. The Defense Center uses data from the Cisco cloud to determine if the files represent malware; see Understanding and Creating File Policies.

- When you enable URL filtering, the Defense Center can retrieve category and reputation data for many commonly visited URLs, as well as perform lookups for uncategorized URLs. You can then quickly create URL conditions for access control rules; see Performing Reputation-Based URL Blocking.

For file and malware cloud-based features, you can use a FireAMP Private Cloud instead of the standard cloud connection if your organization requires additional security or wishes to limit outside connections. All file and malware cloud lookups, as well as collection and relaying of event data from FireAMP endpoints, are handled through the private cloud; when the private cloud contacts the public Cisco cloud, it does so through an anonymized proxy connection. Although it does not support dynamic analysis or non-FireAMP cloud features such as Security Intelligence or URL filtering, the private cloud, from a user’s perspective, functions much the same as a standard public cloud connection. For more information on configuring a private cloud, see Working with the FireAMP Private Cloud.

Use the Defense Center’s local configuration to specify the following options:

Enable URL Filtering

You must enable this option to perform category and reputation-based URL filtering.

Due to memory limitations, some device models perform URL filtering with a smaller, less granular, set of categories and reputations. For example, if a parent domain's subsites have different URL categories and reputations, some devices may use the parent site's data for all subsites. These devices include the 7100 Family and the following ASA FirePOWER models: ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, ASA 5512-X, ASA 5515-X, ASA 5516-X, and the ASA 5525-X.

For virtual devices, see the installation guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.

Query Cloud for Unknown URL

Allows the system to query the cloud when someone on your monitored network attempts to browse to a URL that is not in the local data set.

If the cloud does not know the category or reputation of a URL, or if the Defense Center cannot contact the cloud, the URL does not match access control rules with category or reputation-based URL conditions. You cannot assign categories or reputations to URLs manually.

Disable this option if you do not want your uncategorized URLs to be cataloged by the Cisco cloud, for example, for privacy reasons.

Enable Automatic Updates

Allows the system to contact the cloud on a regular basis to obtain updates to the URL data in your appliances’ local data sets. Although the cloud typically updates its data once per day, enabling automatic updates forces the Defense Center to check every 30 minutes to make sure that you always have up-to-date information.

Although daily updates tend to be small, if it has been more than five days since your last update, new URL filtering data may take up to 20 minutes to download, depending on your bandwidth. Then, it may take up to 30 minutes to perform the update itself.

If you want to have strict control of when the system contacts the cloud, you can disable automatic updates and use the scheduler instead, as described in Automating URL Filtering Updates.

Note Cisco recommends that you either enable automatic updates or use the scheduler to schedule updates. Although you can manually perform on-demand updates, allowing the system to automatically contact the cloud on a regular basis provides you with the most up-to-date, relevant URL data.

Share URI Information of malware events with Cisco

Optionally, Defense Centers can send information about the files detected in network traffic to the cloud. This information includes URI information associated with detected files and their SHA-256 hash values. Although sharing is opt-in, transmitting this information to Cisco will help with future efforts to identify and track malware.

Use legacy port 32137 for network AMP lookups

Selecting this check box allows your system to use port 32137/tcp (the previous default port) for network cloud lookups instead of port 443/tcp. If you updated your appliances from a previous version of the FireSIGHT System, this check box is selected by default.

Licensing

Performing category and reputation-based URL filtering and device-based malware detection require that you enable the appropriate licenses on your managed devices; see Licensing the FireSIGHT System.

You cannot configure cloud connection options if you have no URL Filtering or Malware licenses on the Defense Center. If you have one license but not the other, the Cloud Services local configuration page displays only the options for which you are licensed. Defense Centers with expired licenses cannot contact the cloud.

Note that, in addition to causing the URL Filtering configuration options to appear, adding a URL Filtering license to your Defense Center automatically enables Enable URL Filtering and Enable Automatic Updates. You can manually disable the options if needed.

Note that receiving endpoint-based malware events using a FireAMP subscription does not require a license, nor does specifying individual URLs or groups of URLs to allow or block. For more information, see Understanding Malware Protection and File Control and Performing Manual URL Blocking.

Internet Access and High Availability

The system uses ports 80/HTTP and 443/HTTPS to contact the Cisco cloud and also supports use of a proxy; see Configuring Management Interfaces.

Although all URL filtering configurations and information are synchronized between Defense Centers in a high availability deployment, only the primary Defense Center downloads URL filtering data. If the primary Defense Center fails, you must make sure that the secondary Defense Center has direct access to the Internet and use the web interface on the secondary Defense Center to promote it to Active. For more information, see Monitoring and Changing High Availability Status.

On the other hand, although they share file policies and related configurations, Defense Centers in a high availability pair share neither cloud connections nor malware dispositions. To ensure continuity of operations, and to ensure that detected files’ malware dispositions are the same on both Defense Centers, both primary and secondary Defense Centers must have access to the cloud.

Health Monitoring

The default health policy includes the following modules that track the state and stability of the Defense Center’s cloud connections:

– URL Filtering Monitor, which also warns you if the Defense Center fails to push category and reputation updates to its managed devices

– Advanced Malware Protection

Tip Another module, the FireAMP Status Monitor, tracks the Defense Center’s connection to the Cisco cloud for FireAMP subscription holders. For more information on health monitoring, see Using the Health Monitor.

The following procedures explain how to enable communications the Cisco cloud, and how to perform an on-demand update of URL data. Note that you cannot start an on-demand update if an update is already in progress.

To enable communications with the cloud:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click Cloud Services.

The Cloud Services page appears. If you have a URL Filtering license, the page displays the last time URL data was updated.

Step 3 Configure cloud connection options as described above.

You must Enable URL Filtering before you can Enable Automatic Updates or Query Cloud for Unknown URLs.

Step 4 Click Save.

Your settings are saved. If you enabled URL filtering, depending on how long it has been since URL filtering was last enabled, or if this is the first time you enabled URL filtering, the Defense Center retrieves URL filtering data from the cloud.

To perform an on-demand update of the system’s URL data:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click URL Filtering.

The URL Filtering page appears.

Step 3 Click Update Now.

The Defense Center contacts the cloud and updates its URL filtering data if an update is available.

Enabling VMware Tools

License: Any

Supported Defense Centers: virtual

VMware Tools is a suite of utilities intended to enhance the performance of the virtual machine. These utilities allow you to make full use of the convenient features of VMware products. The system supports the following plugins on all virtual appliances:

- guestInfo

- powerOps

- snapshot

- timeSync

- vmbackup

You can also enable VMware Tools on all supported ESXi versions. For a list of supported versions, see the FireSIGHT System Virtual Installation Guide. For information on the full functionality of VMware Tools, see the VMware website (http://www.vmware.com/).

The following procedure describes how to enable VMware Tools on the virtual Defense Center using the Configuration menu on the web interface. Because the virtual device does not have a web interface, you must use the command line interface to enable VMware Tools on a virtual device; see the FireSIGHT System Virtual Installation Guide.

To enable VMware Tools on a virtual Defense Center:

Access: Admin

Step 1 Select System > Local > Configuration.

The Information page appears.

Step 2 Click VMware Tools.

The VMware Tools page appears.

Step 3 Click Enable VMware Tools and click Save.

Your changes are saved.

Licensing the FireSIGHT System

You can license a variety of features to create an optimal FireSIGHT System deployment for your organization. You use the Defense Center to manage licenses for itself and the devices it manages.

For more information, see:

- Understanding Licensing

- Viewing Your Licenses

- Adding a License to the Defense Center

- Deleting a License

- Changing a Device’s Licensed Capabilities

Understanding Licensing

License: Any

You can license a variety of features to create an optimal FireSIGHT System deployment for your organization. A FireSIGHT license is included with your Defense Center and is required to perform host, application, and user discovery.

Additional model-specific licenses allow your managed devices to perform a variety of functions including:

- intrusion detection and prevention

- Security Intelligence filtering

- file control and advanced malware protection

- application, user, and URL control

- switching and routing

- device clustering

- network address translation (NAT)

- virtual private network (VPN) deployments

There are a few ways you may lose access to licensed features in the FireSIGHT System. You can remove licenses from the Defense Center, which affects all of its managed devices. You can also disable licensed capabilities on specific managed devices. Finally, some licenses may expire. Though there are some exceptions, you cannot use the features associated with an expired or deleted license.

Certain licenses, like the FireSIGHT license, are perpetual. Other licenses require that you purchase a service subscription to enable the license.

For more information, see:

- License Types and Restrictions

- Service Subscriptions

- Licensing High Availability Pairs

- Licensing Stacked and Clustered Devices

- Licensing Series 2 Appliances

- Understanding FireSIGHT Host and User License Limits

License Types and Restrictions

License: Any

This section describes the types of licenses available in a FireSIGHT System deployment. The licenses you can enable on an appliance depend on its model, version, and (for managed devices) the other licenses enabled.

For virtual and Series 3 devices, licenses are model specific; you cannot enable a license on a managed device unless the license exactly matches the device’s model. For example, you cannot use a 3D8250 Protection license to enable Protection capabilities on a 3D8140 device. As your organization and deployment grow, you can purchase additional licenses for additional managed devices.

Series 2 devices automatically have Protection capabilities (with the exception of Security Intelligence filtering). Although you do not need to explicitly enable Protection on Series 2 devices, you also cannot enable any other licenses.

Also note that although you can enable Control on a virtual device or ASA FirePOWER device to perform user and application control, these devices do not support switching, routing, stacking, or clustering.

The following table summarizes FireSIGHT System licenses.

Table 65-1 FireSIGHT System Licenses

License You Assign in FireSIGHT System

Service Subscription You Purchase

Platforms

Granted Capabilities

Requires

Expire Capable?

FireSIGHT

none

Defense Centers

discovery

none

no

Protection

(licensed)

TA (included with device)

Series 3, Virtual, X-Series, ASA FirePOWER

intrusion detection and prevention

file control

Security Intelligence filtering

none

no

Protection (automatic)

none (included with device)

Series 2

intrusion detection and prevention

file control

none

no

Control

none (included with device)

Virtual, ASA FirePOWER

user and application control

Protection

no

Control

none (included with device)

Series 3

user and application control

switching and routing

clustering

Protection

no

Malware

TAM, TAMC, or AMP

Series 3, Virtual, ASA FirePOWER

advanced malware protection (network-based malware detection and blocking)

Protection

yes

URL Filtering

TAC, TAMC, or URL

Series 3, Virtual, X-Series, ASA FirePOWER

category and reputation-based URL filtering

Protection

yes

VPN

none (contact Sales for more information)

Series 3

deploying virtual private networks

Control

yes

Note that the DC500 Defense Center does not support the capabilities provided by a URL Filtering or Malware license.

For more information, see:

- FireSIGHT

- Protection

- Control

- Malware

- URL Filtering

- VPN

FireSIGHT

License: FireSIGHT

A FireSIGHT license is included with your Defense Center and allows you to perform host, application, and user discovery. Discovery data allows the system to create a complete, up-to-the-minute profile of your network, and correlate threat, endpoint, and network intelligence with user identity information. You can use discovery data to perform traffic profiling, assess network compliance, and implement correlation policies.

Your FireSIGHT license also determines how many individual hosts and users you can monitor with the Defense Center and its managed devices. Note that the user limit applies independently to the following:

- the Users database, which contains a record for each user detected by the FireSIGHT System

- the number of users you can use in access control rules to perform user control, also called access-controlled users

For information on the consequences of reaching the licensed limit, see Understanding FireSIGHT Host and User License Limits.

Without a FireSIGHT license, you can still perform basic system configuration, monitoring, network-based access control (zone, network, VLAN, and port rule conditions), connection logging, and reporting. Additionally, you can receive endpoint-based malware events from the Collective Security Intelligence Cloud without a FireSIGHT license, although your organization does need a FireAMP subscription.

Tip The License statements in this guide assume your Defense Center has a FireSIGHT license. However, if the Defense Center was previously running Version 4.10.x, you may be able to use legacy RNA Host and RUA User licenses instead of a FireSIGHT license. For more information, see Protection.

Protection

License: Protection

Supported Devices: Series 3, Virtual, X-Series, ASA FirePOWER

A Protection license allows you to perform intrusion detection and prevention, file control, and Security Intelligence filtering:

- Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and, optionally, drop offending packets.

- File control allows you to detect and, optionally, block users from uploading (sending) or downloading (receiving) files of specific types over specific application protocols. With a Malware license (see Malware), you can also inspect and block a restricted set of those file types based on their malware dispositions.

- Security Intelligence filtering allows you to blacklist—deny traffic to and from—specific IP addresses, before the traffic is subjected to analysis by access control rules. Dynamic feeds allow you to immediately blacklist connections based on the latest intelligence. Optionally, you can use a “monitor-only” setting for Security Intelligence filtering.

A Protection license (along with a Control license) is automatically included in the purchase of any managed device. This license is perpetual, but you must also purchase a TA subscription to enable system updates.

Although you can configure an access control policy to perform Protection-related inspection without a license, you cannot apply the policy until you first add a Protection license to the Defense Center, then enable it on the devices targeted by the policy.

If you delete your Protection license from the Defense Center or disable Protection on managed devices, the Defense Center stops acknowledging intrusion and file events from the affected devices. As a consequence, correlation rules that use those events as a trigger criteria stop firing. Additionally, the Defense Center will not contact the internet for either Cisco-provided or third-party Security Intelligence information. You cannot reapply existing policies until you re-enable Protection.

Because a Protection license is required for URL Filtering, Malware, and Control licenses, deleting or disabling a Protection license has the same effect as deleting or disabling your URL Filtering, Malware, or Control license.

Note Series 2 devices automatically have most Protection capabilities; you do not have to purchase or enable Protection licenses for these devices. However, Series 2 devices cannot perform Security Intelligence filtering.

Control

License: Control

Supported Devices: Series 3, Virtual, ASA FirePOWER

Supported Defense Centers: feature dependent

A Control license allows you to implement user and application control by adding user and application conditions to access control rules. It also allows you to configure your Series 3 managed devices to perform switching and routing (including DHCP relay and NAT), as well as cluster managed devices. To enable Control on a managed device, you must also enable Protection.

Note Although you can enable a Control license on a virtual device or ASA FirePOWER device, these devices do not support switching, routing, stacking, or clustering.

A Control license is automatically included (along with a Protection license) in the purchase of any managed device. This license is perpetual, but you must also purchase a TA subscription to enable system updates.

Although you can add user and application conditions to access control rules without a Control license, you cannot apply the policy until you first add a Control license to the Defense Center, then enable it on the devices targeted by the policy.

Note that the DC500 Defense Center does not support adding user conditions in access control rules.

Without a Control license, you cannot create switched, routed, or hybrid interfaces on your managed devices; create NAT entries; or configure DHCP relay for virtual routers. Although you can create virtual switches and routers, they are not useful without switched and routed interfaces to populate them. Further, you cannot apply a device configuration that includes switching or routing to a managed device where you have not enabled Control. Additionally, establishing clustering between managed devices requires that the devices are enabled for Control.

If you delete your Control license from the Defense Center or disable Control on individual devices, the affected devices do not stop performing switching or routing, nor do device clusters break. Although you can edit and delete existing configurations, you cannot apply your changes to the affected devices. You cannot add new switched, routed, or hybrid interfaces, nor can you add new NAT entries, configure DHCP relay, or establish device clustering. Finally, you cannot reapply existing access control policies if they include rules with user or application conditions.

URL Filtering

License: URL Filtering

Supported Devices: Series 3, Virtual, X-Series, ASA FirePOWER

Supported Defense Centers: Any except DC500

URL filtering allows you to write access control rules that determine the traffic that can traverse your network based on URLs requested by monitored hosts, correlated with information about those URLs, which is obtained from the Cisco cloud by the Defense Center. To enable URL Filtering, you must also enable a Protection license.

Tip Without a URL Filtering license, you can specify individual URLs or groups of URLs to allow or block. This gives you granular, custom control over web traffic, but does not allow you to use URL category and reputation data to filter network traffic.

You can purchase a URL Filtering license as a services subscription combined with Threat & Apps (TAC) or Threat & Apps and Malware (TAMC), or as an add-on subscription (URL) for a system where Threat & Apps (TA) is already enabled.

Although you can add category and reputation-based URL conditions to access control rules without a URL Filtering license, the Defense Center will not contact the cloud for URL information. You cannot apply the access control policy until you first add a URL Filtering license to the Defense Center, then enable it on the devices targeted by the policy.

You may lose access to URL filtering if you delete the license from the Defense Center or disable URL Filtering on managed devices. Also, URL Filtering licenses may expire. If your license expires or if you delete or disable it, access control rules with URL conditions immediately stop filtering URLs, and your Defense Center can no longer contact the cloud. You cannot reapply existing access control policies if they include rules with category and reputation-based URL conditions.

Malware

License: Malware

Supported Devices: Series 3, Virtual, ASA FirePOWER

Supported Defense Centers: Any except DC500

A Malware license allows you to perform advanced malware protection, that is, use managed devices to detect and block malware in files transmitted over your network. To enable Malware on a managed device, you must also enable Protection.

Note Managed devices with Malware licenses enabled periodically attempt to connect to the Cisco cloud even if you have not configured dynamic analysis. Because of this, the device’s Interface Traffic dashboard widget shows transmitted traffic; this is expected behavior.

You configure malware detection as part of a file policy, which you then associate with one or more access control rules. File policies can detect your users uploading or downloading files of specific types over specific application protocols. The Malware license allows you to inspect a restricted set of those file types for malware, as well as download and submit specific file types to the Cisco cloud for dynamic and Spero analysis to determine whether they contain malware. The Malware license also allows you add specific files to a file list and enable the file list within a file policy, allowing those files to be automatically allowed or blocked on detection.

You can purchase a Malware license as a subscription combined with Threat &Apps (TAM) or Threat & Apps and URL Filtering (TAMC), or as an add-on subscription (AMP) for a system where Threat & Apps (TA) is already enabled.

add a Malware license, then enable it on the devices targeted by the policy. If you later disable the license on the devices, you cannot reapply an existing access control policy to those devices if it includes file policies that perform malware detection.

If you delete all your Malware licenses or they all expire, the Defense Center stops performing malware cloud lookups, and also stops acknowledging retrospective events sent from the Cisco cloud. You cannot reapply existing access control policies if they include file policies that perform malware detection. Note that for a very brief time after a Malware license expires or is deleted, the system can use cached dispositions for files detected by Malware Cloud Lookup file rules. After the time window expires, the system assigns a disposition of Unavailable to those files, rather than performing a lookup.

Note that a Malware license is only required if you want the system to detect malware in network traffic. Without a Malware license, the Defense Center can receive endpoint-based malware events from the Cisco cloud if your organization has a FireAMP subscription. For more information, see Understanding Malware Protection and File Control.

VPN

License: VPN

Supported Devices: Series 3

VPN allows you to establish secure tunnels between endpoints via a public source, such as the Internet or other network. You can configure the FireSIGHT System to build secure VPN tunnels between the virtual routers of Cisco managed devices. To enable VPN, you must also enable Protection and Control licenses. To purchase a VPN license, contact Sales.

Without a VPN license, you cannot configure a VPN deployment with your managed devices. Although you can create deployments, they are not useful without at least one VPN-enabled routed interface to populate them.

If you delete your VPN license from the Defense Center or disable VPN on individual devices, the affected devices do not break the current VPN deployments. Although you can edit and delete existing deployments, you cannot apply your changes to the affected devices.

Service Subscriptions

License: Any

A service subscription enables specific features on a managed device for a set length of time. Service subscriptions can be purchased in one-, three-, or five-year terms. If a subscription expires, Cisco notifies you that you must renew the subscription. If a subscription expires, you might not be able to use the related features, depending on the feature type.

Your purchase of a managed device automatically includes Control and Protection licenses. These licenses are perpetual, but you must also purchase a TA service subscription to enable system updates. Additional service subscriptions are optional.

Service subscriptions correspond to the licenses you assign to managed devices in the FireSIGHT System, as follows:

Table 65-2 FireSIGHT Service Subscriptions

Subscription You Purchase

License You Assign in FireSIGHT System

TA

Control + Protection (a.k.a. "Threat & Apps," required for system updates)

TAC

Control + Protection + URL Filtering

TAM

Control + Protection + Malware

TAMC

Control + Protection + URL Filtering + Malware

AMP

Malware (add-on where TA is already present)

URL

URL Filtering (add-on where TA is already present)

Licensing High Availability Pairs

License: Any

Supported Defense Centers: DC1000, DC1500, DC2000, DC3000, DC3500, DC4000

Defense Centers in a high availability pair do not share licenses. You must apply equivalent licenses to each member of the pair. Because Cisco generates licenses based on each Defense Center’s unique license key, you cannot use the same licenses on different Defense Centers.

Licensing Stacked and Clustered Devices

License: Any

Supported Devices: feature dependent

Individual devices must have equivalent licenses before they can be stacked or clustered. After you stack devices, you can change the licenses for the entire stack. However, you cannot change the enabled licenses on a device cluster.

You can stack 3D8140, 3D8200 family, 3D8300 family, and 3D9900 devices of the same model that meet the requirements described in Managing Stacked Devices. You can cluster two devices of the same Series 3 model that meet the requirements described in Clustering Devices.

Licensing Series 2 Appliances

License: Protection

Supported Devices: Series 2

With the exception of the DC500, Series 2 and Series 3 Defense Center licensing is identical. Because the DC500 does not support URL filtering or network-based malware detection, it cannot take advantage of URL Filtering or Malware licenses.

Series 2 devices automatically have the capabilities, except for Security Intelligence, enabled by a Protection license. You cannot disable the Protection license on Series 2 devices, and you cannot enable other licenses.

See the following sections for more information:

- Service Subscriptions describes the types of licenses available in a FireSIGHT System deployment.

- Summary of Supported Capabilities by Managed Device Model summarizes supported and unsupported features on Series 2 appliances.

Understanding FireSIGHT Host and User License Limits

License: FireSIGHT

The FireSIGHT license on your Defense Center determines how many individual hosts and users you can monitor with the Defense Center and its managed devices, as well as how many users you can use to perform user control. FireSIGHT host and user license limits are model specific, as listed in the following table.

Table 65-3 FireSIGHT Limits by Defense Center Model

Defense Center Model

FireSIGHT Host and User Limit

DC500

1000

DC750

2000

DC1000

20,000

DC1500

50,000

DC2000

100,000

DC3000

100,000

DC3500

300,000

DC4000

600,000

virtual

50,000

For example, you can monitor 1000 hosts and 1000 users with the DC500.

If your Defense Center was previously running Version 4.10.x of the FireSIGHT System and you used an ISO file to “restore” the appliance to Version 5.x factory defaults, you may be able to use your legacy RNA Host and RUA User licenses instead of a FireSIGHT license.

For more information, see the following sections:

- Understanding the FireSIGHT Host Limit

- Understanding the FireSIGHT User Limit

- Understanding the Access-Controlled User Limit

- Protection

Understanding the FireSIGHT Host Limit

License: FireSIGHT

The FireSIGHT license on your Defense Center determines how many individual hosts you can monitor with the Defense Center and its managed devices, and therefore how many hosts you can store in your network map.

Note that the system counts MAC-only hosts separately from hosts identified by both IP addresses and MAC addresses. All IP addresses associated with a host are counted together as one host.

When the system detects activity associated with a host with an IP address in your monitored network (as defined by your network discovery policy), that host is added to the network map.

If you reach the host limit and the system detects a new host, whether the new host is added to the network map depends on the When Host Limit Reached setting in your network discovery policy. You can configure the system either to stop adding new hosts to the database, or to replace the hosts that have remained inactive for the longest time.

Note Even if you cannot add a new host to the network map, the system still performs access control on that host’s network traffic. Although reaching the FireSIGHT host limit does not prevent you from performing access control on hosts discovered after you reached your licensed limit, you cannot view or perform analysis on those hosts using host profile data. For example, you cannot use compliance white lists to monitor network compliance for those hosts, or use those hosts in host profile qualifications, and so on.

You can also manually delete a host, an entire subnet, or all of your hosts from the network map. Keep in mind, however, that if the system detects activity associated with a deleted host, it re-adds the host to the network map.

Note also that if the system has not detected network traffic from a host in the last Host Timeout period specified in your network discovery policy, the host is removed from the network map. The default setting is 10080 minutes (7 days).

To help you track your host license use, the FireSIGHT Host License Limit health module warns you if you have fewer than a configurable number of host licenses left.

Understanding the FireSIGHT User Limit

License: FireSIGHT

The FireSIGHT license on your Defense Center determines how many individual users you can monitor. When the system detects activity from a new user, that user is added to the Users database. You can detect users in the following ways:

- You can use the network discovery policy to configure managed devices to passively detect logins for LDAP, AIM, POP3, IMAP, Oracle, SIP (VoIP), FTP, HTTP, MDNS, and SMTP users.

- You can install User Agents on your Microsoft Active Directory LDAP servers to detect authentications against Active Directory credentials.

After you reach the licensed limit, in most cases the system stops adding new users to the database. To add new users, you must either manually delete users from the database, or purge all users from the database.

However, the system favors authoritative user logins. If you have reached the licensed limit and the system detects an authoritative user login for a previously undetected user, the system deletes the non-authoritative user who has remained inactive for the longest time, and replaces it with the new user.

Tip Note that if you are using managed devices to detect user activity, you can restrict user logging by protocol to help minimize username clutter and preserve FireSIGHT user licenses. For example, monitoring users discovered via AIM, POP3, and IMAP may add users not relevant to your organization due to network access from contractors, visitors, and other guests. For more information, see Restricting User Logging.

Understanding the Access-Controlled User Limit

License: Control

Supported Devices: Series 3, Virtual, ASA FirePOWER

The FireSIGHT license on your Defense Center determines not only how many individual users you can monitor, but also how many users you can use in access control rules to perform user control. These users are called access-controlled users.

Note To perform user control, your organization must use Microsoft Active Directory. The system uses User Agents running on Active Directory servers to associate access-controlled users with IP addresses, which is what allows access control rules to trigger.

You specify the groups that access-controlled users must belong to by configuring a connection (called a user awareness object) between the Defense Center and an Active Directory server. Then, on a regular basis, the Defense Center queries the server and retrieves a list of the users in the groups you specified in the authentication object. You can then use these users to perform access control.

You must make sure the total number of users in the groups you specify in the authentication object is less than your FireSIGHT user license. If your parameters are too broad, the Defense Center obtains information on as many users as it can and reports the number of users it failed to retrieve in the task queue. For performance and licensing reasons, Cisco recommends that you specify only the groups that represent the users you want to use in access control.

Viewing Your Licenses

License: Any

Use the Licenses page to view the licenses for a Defense Center and its managed devices. For each type of appliance in your deployment, the page lists the total number of licenses you have as well as the portion of those licenses that are in use.

Keep in mind that on this page, the number of FireSIGHT User licenses in use represents the number of users detected by the FireSIGHT System, that is, the number of users in the Users database. It does not represent the number of access-controlled users you are using for access control. For more information, see Understanding FireSIGHT Host and User License Limits.

The Licenses page also provides details on each of your licenses. For each model, you can see how many licenses of each type you have, and how many managed devices you can license with each type of license. For licenses that expire, the page provides you with the expiration date.

Other than the Licenses page, there are a few other ways you can view licenses and license limits:

- The Product Licensing dashboard widget provides an at-a-glance overview of your licenses.

- The Device Management page ( Devices > Device Management ) lists the licenses applied to each of your managed devices.

- Two health modules, License Monitor and FireSIGHT Host License Limit, communicate license status when used in a health policy.

To view your licenses:

Access: Admin

Step 1 Select System > Licenses.

The Licenses page appears.

Adding a License to the Defense Center

License: Any

Before you add a license to the Defense Center, make sure you have the activation key provided by Cisco when you purchased the license.

With the exception of FireSIGHT, you must enable licenses on your managed devices before you can use licensed features. You can enable a license either when you add a device to the Defense Center, or by editing the device’s general properties after you add the device, Note that because Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence filtering, you cannot disable these capabilities, nor can you apply other licenses to a Series 2 device. See Changing a Device’s Licensed Capabilities.

Note If you add licenses after a backup has completed, these licenses will not be removed or overwritten if this backup is restored. To prevent a conflict on restore, remove those licenses before restoring the backup, noting where the licenses were used, and add and reconfigure them after restoring the backup. If a conflict occurs, contact Support.

To add a license:

Access: Admin

Step 1 Select System > Licenses.

The Licenses page appears.

Step 2 Click Add New License.

The Add License page appears.

Step 3 Did you receive an email with your license?

- If yes, copy the license from the email, paste it into the License field, and click Submit License .

If the license is correct, the license is added. Skip the rest of the procedure.

- If no, click Get License .

The Licensing Center web site appears. If you cannot access the Internet, switch to a computer that can. Note the license key at the bottom of the page and browse to https://tools.cisco.com/SWIFT/LicensingUI/Home.

Step 4 Follow the on-screen instructions to obtain your license, which will be sent to you in an email.

Tip You can also request a license on the Licenses tab after you log into the Support Site.

Step 5 Copy the license from the email, paste it into the License field in the Defense Center’s web interface, and click Submit License.

If the license is valid, it is added. You can now enable the license’s capabilities on your managed devices, as described in Changing a Device’s Licensed Capabilities.

Deleting a License

License: Any

Use the following procedure if you need to delete a license for any reason. Keep in mind that because Cisco generates licenses based on each Defense Center’s unique license key, when you delete the license from one Defense Center and then reuse it on a different Defense Center, you must request a new license based on the license key from the new Defense Center.

In most cases, deleting a license removes your ability to use features enabled by that license. For more information, see Service Subscriptions.

To delete a license:

Access: Admin

Step 1 Select System > Licenses.

The Licenses page appears.

).

Deleting a license removes the licensed capability from all devices using that license. For example, if your Protection license is valid for and enabled on 100 managed devices, deleting the license removes Protection capabilities from all 100 devices.

Step 3 Confirm that you want to delete the license.

The license is deleted.

Changing a Device’s Licensed Capabilities

License: Any

Supported Devices: Series 3, Virtual, X-Series, ASA FirePOWER

To change the licensed capabilities of a Series 3 device, virtual device, Cisco NGIPS for Blue Coat X-Series, or ASA FirePOWER device, edit the device’s general properties on the Device Management page. Although there are some exceptions, you cannot use the features associated with a license if you disable it on a managed device.

Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence filtering. You cannot disable these capabilities, nor can you apply other licenses to a Series 2 device. Note that, although you cannot use a Malware or URL Filtering license with a DC500 Defense Center, you can use a DC500 to enable or change these and other licensed capabilities of a Series 3 device, virtual device, Cisco NGIPS for Blue Coat X-Series, or ASA FirePOWER device.

For detailed information on the licenses you can enable, including version, model, and other requirements, see Service Subscriptions.

To enable or disable a device’s licensed capabilities:

Access: Admin/Network Admin

Step 1 Select Devices > Device Management.

The Device Management page appears.

).

The Interfaces tab for that device appears.

Step 3 Click Device.

The Device tab appears.

).

The License pop-up window appears.

Step 5 Enable or disable the licensed capabilities of the device by clearing or selecting the appropriate check boxes.

Step 6 Click Save.

The changes are saved but do not take effect until you apply the device configuration; see Applying Changes to Devices.

Updating System Software

Cisco electronically distributes several different types of updates, including major and minor updates to the system software itself, as well as rule updates, geolocation database (GeoDB) updates, and Vulnerability Database (VDB) updates.

Caution This chapter contains general information on updating the FireSIGHT System. Before you update any part of the FireSIGHT System, including the VDB, GeoDB, or intrusion rules, you must read the release notes or advisory text that accompanies the update. The release notes provide important information, including supported platforms, compatibility, prerequisites, warnings, and specific installation and uninstallation instructions.

Unless otherwise documented in the release notes or advisory text, updating an appliance does not modify its configuration; the settings on the appliance remain intact.

See the following sections for more information:

- Understanding Update Types

- Performing Software Updates

- Uninstalling Software Updates

- Updating the Vulnerability Database

- Importing Rule Updates and Local Rule Files

- Updating the Geolocation Database

Understanding Update Types

License: Any

Cisco electronically distributes several different types of updates, including major and minor updates to the system software itself, as well as intrusion rule updates and VDB updates.

The following table describes the types of updates provided by Cisco. For most update types, you can schedule their download and installation; see Scheduling Tasks and Using Recurring Rule Updates.

Table 66-1 FireSIGHT System Update Types

Update Type

Description

Schedule?

Uninstall?

patches to the FireSIGHT System

Patches include a limited range of fixes (and usually change the fourth digit in the version number; for example, 5.4.0.1).

yes

yes

feature updates to the FireSIGHT System

Feature updates are more comprehensive than patches and generally include new features (and usually change the third digit in the version number; for example, 5.4.1).

yes

yes

major updates (major and minor version releases) to the FireSIGHT System

Major updates, sometimes referred to as upgrades, include new features and functionality and may entail large-scale changes to the product (and usually change the first or second digit in the version number; for example, 5.3 or 5.4).

no

no

VDB

VDB updates affect the vulnerabilities reported by the FireSIGHT System as well as the detected operating systems, applications, and clients.

yes

no

intrusion rules

Intrusion rule updates provide new and updated intrusion rules and preprocessor rules, modified states for existing rules, and modified default intrusion policy settings. Rule updates may also delete rules, provide new rule categories and default variables, and modify default variable values.

yes

no

geolocation database (GeoDB)

GeoDB updates provide updated information on physical locations, connection types, and so on that your system can associate with detected routable IP addresses. You can use geolocation data as a condition in access control rules. You must install the GeoDB to view geolocation details.

The DC500 Defense Center does not support this feature.

yes

no

Note that while you can uninstall patches and other minor updates to the FireSIGHT System, you cannot uninstall major updates or return to previous versions of the VDB, GeoDB, or intrusion rules. If you updated your appliance to a new major version of the FireSIGHT System, and you need to revert to an older version, contact Support.

Performing Software Updates

License: Any

There are a few basic steps to updating your FireSIGHT System deployment. First, you must prepare for the update by reading the release notes and completing any required pre-update tasks. Then, you can begin the update — first update your Defense Centers, then the devices they manage. You must monitor the update’s progress until it completes, then verify the update’s success. Finally, complete any required post-update steps.

For more information, see the following sections:

- Planning for the Update

- Understanding the Update Process

- Updating a Defense Center

- Updating Managed Devices

- Monitoring the Status of Major Updates

Planning for the Update

License: Any

Before you begin the update, you must thoroughly read and understand the release notes, which you can download from the Support Site. The release notes describe supported platforms, new features and functionality, known and resolved issues, and product compatibility. The release notes also contain important information on prerequisites, warnings, and specific installation and uninstallation instructions.

The following sections provide an overview of some of the factors you must consider when planning for the update.

FireSIGHT System Version Requirements

You must make sure your appliances (including software-based devices) are running the correct version of the FireSIGHT System. The release notes indicate the required version. If you are running an earlier version, you can obtain updates from the Support Site.

Operating System Requirements

Make sure the computers where you installed software-based devices are running the correct versions of their operating systems. The release notes indicate the required versions. For information on supported operating systems for virtual devices, see the FireSIGHT System Virtual Installation Guide. For information on supported operating systems for Cisco NGIPS for Blue Coat X-Series, see the Cisco NGIPS for Blue Coat X-Series Installation Guide.

Time and Disk Space Requirements

Make sure you have enough free disk space and allow enough time for the update. When you update a managed device, the update requires additional disk space on the Defense Center. The release notes indicate space and time requirements.

Configuration and Event Backup Guidelines

Before you begin a major update, Cisco recommends that you delete any backups that reside on the appliance after copying them to an external location. Regardless of the update type, you should also back up current event and configuration data to an external location. Event data is not backed up as part of the update process.

You can use the Defense Center to back up event and configuration data for itself and the devices it manages; see Using Backup and Restore.

When to Perform the Update

Because the update process may affect traffic inspection, traffic flow, and link state, and because the Data Correlator is disabled while an update is in progress, Cisco recommends you perform the update in a maintenance window or at a time when the interruption will have the least impact on your deployment.

Understanding the Update Process

License: Any

Order of Update

You must update your Defense Centers before you can update the devices they manage.

Use the Defense Center to Perform the Update

Cisco recommends that you use the Defense Center’s web interface to update not only itself, but also the devices it manages. You must use the Defense Center to update managed devices that do not have a web interface, such as virtual devices and Cisco NGIPS for Blue Coat X-Series. For major updates to Cisco NGIPS for Blue Coat X-Series, you may need to uninstall the previous version and install the new version. See the Cisco NGIPS for Blue Coat X-Series Installation Guide for more information.

The Product Updates page (System > Updates) shows the version of each update, as well as the date and time it was generated. It also indicates whether a reboot is required as part of the update.

When you upload updates obtained from Support to your appliance, they appear on the page. Uninstallers for patch and feature updates also appear; see Uninstalling Software Updates. On the Defense Center, the page can list VDB updates.

Tip For patches and feature updates, you can take advantage of the automated update feature; see Automating Software Updates.

Updating Paired Defense Centers

When you begin to update one Defense Center in a high availability pair, the other Defense Center in the pair becomes the primary, if it is not already. In addition, the paired Defense Centers stop sharing configuration information; paired Defense Centers do not receive software updates as part of the regular synchronization process.

To ensure continuity of operations, do not update paired Defense Centers at the same time. First, complete the update procedure for the secondary Defense Centers, then update the primary.

Updating Clustered Devices

When you install an update on clustered devices or clustered stacks, the system performs the update on the devices or stacks one at a time. When the update starts, the system first applies it to the backup device or stack, which goes into maintenance mode until any necessary processes restart and the device or stack is processing traffic again. The system then applies the update to the active device or stack, which follows the same process.

To update devices in a clustered stack, you must perform the update from the managing Defense Center on all members of a cluster at once; you cannot perform the upgrade directly from the devices.

Updating Stacked Devices

When you install an update on stacked devices, the system performs the updates simultaneously. Each device resumes normal operation when the update completes. Note that:

- If the primary device completes the update before all of the secondary devices, the stack operates in a limited, mixed-version state until all devices have completed the update.

- If the primary device completes the upgrade after all of the secondary devices, the stack resumes normal operation when the update completes on the primary device.

Traffic Flow and Inspection

When you install or uninstall updates from a managed device, the following capabilities may be affected:

- traffic inspection, including application and user awareness and control, URL filtering, Security Intelligence filtering, intrusion detection and prevention, and connection logging

- traffic flow, including switching, routing, and related functionality

- link state

The Data Correlator does not run during system updates. It resumes when the update is complete.

The manner and duration of network traffic interruption depends on the components of the FireSIGHT System that the update affects, how your devices are configured and deployed, and whether the update reboots the device. For specific information on how and when network traffic is affected for a particular update, see the release notes.

Tip When you update clustered devices, the system performs the updates one at a time to avoid traffic interruption.

Using the Web Interface During the Update

Regardless of the type of update, do not use the web interface of the appliance you are updating to perform tasks other than monitoring the update.

To prevent you from using an appliance during a major update, and to allow you to easily monitor a major update’s progress, the system streamlines the appliance’s web interface. You can monitor a minor update's progress in the task queue (System > Monitoring > Task Status). Although you are not prohibited from using the web interface during a minor update, Cisco recommends against it.

Tip To monitor updates to its managed devices, use the task queue on the Defense Center.

Even for minor updates, the web interface on the updating appliance may become unavailable during the update process, or the appliance may log you out. This is expected behavior. If this occurs, log in again to view the task queue. If the update is still running, you must continue to refrain from using the web interface until the update has completed. Note that while updating, managed devices may reboot a second time; this is also expected behavior.

Caution If you encounter issues with the update (for example, if the web interface indicates that the update has failed or if a manual refresh of the task queue or Update Status page shows no progress), do not restart the update. Instead, contact Support.

After the Update

You must complete all of the post-update tasks listed in the release notes to ensure that your deployment is performing properly.

The most important post-update task is to reapply access control policies, both after you update the Defense Center and then again after you update its managed devices.

Caution When you apply an access control policy, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See Applying an Access Control Policy and Configurations that Restart the Snort Process.

Additionally, you should:

- verify that the update succeeded

- make sure that all appliances in your deployment are communicating successfully

- update your intrusion rules, VDB, and GeoDB, if necessary

- make any required configuration changes, based on the information in the release notes

- perform any additional post-update tasks listed in the release notes

Updating a Defense Center

License: Any

Update the Defense Center in one of two ways, depending on the type of update and whether your Defense Center has access to the Internet:

- You can use the Defense Center to obtain the update directly from the Support Site, if your Defense Center has access to the Internet. This option is not supported for major updates.

- You can manually download the update from the Support Site and then upload it to the Defense Center. Choose this option if your Defense Center does not have access to the Internet or if you are performing a major update.

Caution To ensure continuity of operations, do not update paired Defense Centers at the same time; see Updating Paired Defense Centers.

For major updates, updating the Defense Center removes uninstallers for previous updates.

To update the Defense Center

Access: Admin

Step 1 Read the release notes and complete any required pre-update tasks.

Pre-update tasks may include making sure that: the Defense Center is running the correct version of the Cisco software, you have enough free disk space to perform the update, you set aside adequate time to perform the update, you backed up event and configuration data, and so on.

Step 2 Upload the update to the Defense Center. You have two options, depending on the type of update and whether your Defense Center has access to the Internet:

- For all except major updates, and if your Defense Center has access to the Internet, select System > Updates , then click Download Updates to check for the latest updates. For major updates, or if your Defense Center does not have access to the Internet, you must first manually download the update. Download the updates from either of the following Support Sites:

– For all Sourcefire updates: (https://support.sourcefire.com/)

– For Cisco updates:

Physical Defense Center

(http://software.cisco.com/download/navigator.html?mdfid=278875421)

Virtual Defense Center_

(http://software.cisco.com/download/type.html?mdfid=286259687&catid=null)

- Select System > Updates , then click Upload Update . Browse to the update and click Upload .

Note Download the update directly from the Support Site, either manually or by clicking Download Updates on the Product Updates tab. If you transfer an update file by email, it may become corrupted.

The update is uploaded to the Defense Center.

Step 3 Make sure that the appliances in your deployment are successfully communicating and that there are no issues being reported by the health monitor.

Step 4 Select System > Monitoring > Task Status to view the task queue and make sure that there are no jobs in process.

Tasks that are running when the update begins are stopped and cannot be resumed; you must manually delete them from the task queue after the update completes. The task queue automatically refreshes every 10 seconds. You must wait until any long-running tasks are complete before you begin the update.

Step 5 Select System > Updates.

The Product Updates page appears.

Step 6 Click the install icon next to the update you uploaded.

The Install Update page appears.

Step 7 Select the Defense Center and click Install. If prompted, confirm that you want to install the update and reboot the Defense Center.

The update process begins. How you monitor the update depends on whether the update is a major or minor update. See the FireSIGHT System Update Types table and the release notes to determine your update type:

- For minor updates, you can monitor the update’s progress in the task queue ( System > Monitoring > Task Status ).

- For major updates, you can begin monitoring the update’s progress in the task queue. However, after the Defense Center completes its necessary pre-update checks, you are logged out. When you log back in, the Upgrade Status page appears. See Monitoring the Status of Major Updates for information.

Caution Regardless of the update type, do not use the web interface to perform tasks other than monitoring the update until the update has completed and, if necessary, the Defense Center reboots. For more information, see Using the Web Interface During the Update.

Step 8 After the update finishes, if necessary, log into the Defense Center.

If you are the first user to log in after a major update, the End User License Agreement (EULA) may appear. You must review and accept the EULA to continue.

Step 9 Clear your browser cache and force a reload of the browser. Otherwise, the user interface may exhibit unexpected behavior.

Step 10 Select Help > About and confirm that the software version is listed correctly. Also note the versions of the rule update and VDB on the Defense Center; you will need this information later.

Step 11 Verify that all managed devices are successfully communicating with the Defense Center.

Step 12 If the rule update available on the Support Site is newer than the rules on your Defense Center, import the newer rules.

For more information, see Importing Rule Updates and Local Rule Files.

Step 13 Reapply access control policies.

When you apply an access control policy, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See Applying an Access Control Policy and Configurations that Restart the Snort Process.

Step 14 If the VDB available on the Support Site is newer than the VDB on your Defense Center, install the latest VDB.

Caution Installing a VDB update restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic and Updating the Vulnerability Database for more information.

Step 15 Continue with the next section, Updating Managed Devices, to update Cisco software on the devices that the Defense Center manages.

Updating Managed Devices

License: Any

After you update your Defense Centers, Cisco recommends that you use them to update the devices they manage. You must use the Defense Center to update managed devices that do not have a web interface, such as virtual devices and Cisco NGIPS for Blue Coat X-Series. For major updates to Cisco NGIPS for Blue Coat X-Series, you may need to uninstall the previous version and install the new version.

Updating managed devices is a two-step process. First, download the update from either of the following Support Sites and upload it to the managing Defense Center:

- Sourcefire: (https://support.sourcefire.com/ )

- Cisco: (http://www.cisco.com/cisco/web/support/index.html )

Next, install the software.

Note Traffic inspection, traffic flow, and link state may be affected during the update, depending on how your devices are configured and deployed, the components that the update affects, and whether the update reboots the devices. For specific information on how and when network traffic is affected for a particular update, see the release notes for that update.

To update managed devices:

Access: Admin

Step 1 Read the release notes and complete any required pre-update tasks.

Pre-update tasks may include updating your managing Defense Center, backing up event and configuration data, and making sure that the devices are running the correct version of the Cisco software, that computers where you installed software-based devices are running the correct version of their operating systems, that you have enough free disk space to perform the update, that you have set aside adequate time to perform the update, and so on.

Step 2 Update the FireSIGHT System software on the devices’ managing Defense Center; see Updating a Defense Center.

Step 3 Download the update from either of the following Support Sites:

- For all Sourcefire updates: (https://support.sourcefire.com/ )

- For Cisco updates:

physical managed devices: (http://software.cisco.com/download/navigator.html?mdfid=278875421)

virtual managed devices: (http://software.cisco.com/download/type.html?mdfid=286259690&flowid=70802)

Different device models may use different updates. For information on the updates you can download, see the release notes.

Note Download the update directly from the Support Site. If you transfer an update file by email, it may become corrupted.

Step 4 Make sure that the appliances in your deployment are successfully communicating and that there are no issues being reported by the health monitor.

Step 5 On the managing Defense Center, select System > Updates.

The Product Updates page appears.

Step 6 Click Upload Update to browse to the update you downloaded, then click Upload.

The update is uploaded to the Defense Center. The Product Updates tab shows the type of update you just uploaded, its version number, and the date and time when it was generated. The page also indicates whether a reboot is required as part of the update.

Step 7 Click the install icon next to the update you are installing.

The Install Update page appears.

Step 8 Select the devices where you want to install the update, then click Install; you can update multiple devices at once if they use the same update. If prompted, confirm that you want to install the update and reboot the devices.

The update process begins. Depending on the size of the file, it may take some time to install the update on all devices. You can monitor the update's progress in the Defense Center’s task queue (System > Monitoring > Task Status). Note that managed devices may reboot twice during the update; this is normal.

Caution If you encounter issues with the update (for example, if the task queue indicates that the update has failed or if a manual refresh of the task queue shows no progress), do not restart the update. Instead, contact Support.

Step 9 Optionally, after a major update, log in to the device’s local web interface.

If you are the first user to log in after a major update, the End User License Agreement (EULA) may appear. You must review and accept the EULA to continue. Note that the EULA also appears, and must be accepted, if your first login is via the command line interface rather than the web interface.

Step 10 On the Defense Center, select Devices > Device Management and confirm that the devices you updated have the correct version listed.

Step 11 Verify that the devices you updated are successfully communicating with the Defense Center.

Step 12 Reapply access control policies.

When you apply an access control policy, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart, which temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See Applying an Access Control Policy and Configurations that Restart the Snort Process.

Monitoring the Status of Major Updates

License: Any

For major updates, the FireSIGHT System provides you with a streamlined web interface so that you can easily monitor the update process. The streamlined interface also prevents you from using the web interface to perform tasks other than monitoring the update.

You can begin monitoring the update’s progress in the task queue (System > Monitoring > Task Queue). However, after the appliance completes its necessary pre-update checks, you and all other users are logged out of the web interface. Unless you are an administrator or a maintenance user, you cannot log back in until the update is complete.

For administrators, when you log back in, the streamlined update page appears.

When using a Defense Center to update a managed device, Cisco recommends that you monitor the update’s progress from the Defense Center’s task queue. Note, however, that if you attempt to log into the device’s local web interface after the appliance finishes its pre-update checks, the streamlined update page appears and you can use it to monitor the update’s progress.

The page displays the version of the FireSIGHT System you are updating from, the version you are updating to, and the time that has elapsed since the update began. It also displays a progress bar and gives details about the script currently running.

Tip Click show log for current script to see the update log. Click hide log for current script to hide the log again.

If the update fails for any reason, the page displays an error message indicating the time and date of the failure, which script was running when the update failed, and instructions on how to contact Support. Do not restart the update.

Caution If you encounter any other issue with the update (for example, if a manual refresh of the page shows no progress for an extended period of time), do not restart the update. Instead, contact Support.

When the update completes, the appliance displays a success message and reboots. After the appliance finishes rebooting, refresh the page to log in and complete any required post-update steps.

Uninstalling Software Updates

License: Any

When you apply a patch or feature update to a Cisco appliance, the update process creates an uninstaller that allows you to remove the update from that appliance, using its web interface.

When you uninstall an update, the resulting Cisco software version depends on the update path for your appliance. For example, consider a scenario where you updated an appliance directly from Version 5.0 to Version 5.0.0.2. Uninstalling the Version 5.0.0.2 patch might result in an appliance running Version 5.0.0.1, even though you never installed the Version 5.0.0.1 update. For information on the resulting Cisco software version when you uninstall an update, see the release notes.

Note Uninstalling from the web interface is not supported for major updates. If you updated your appliance to a new major version of the FireSIGHT System and you need to revert to an older version, contact Support.

Order of Uninstallation

Uninstall the update in the reverse order that you installed it. That is, first uninstall the update from managed devices, then from Defense Centers.

Use the Local Web Interface to Uninstall the Update

You must use the local web interface to uninstall updates; you cannot use the Defense Center to uninstall updates from managed devices. For information on uninstalling a patch from a device that does not have a local web interface (for example, virtual devices or Cisco NGIPS for Blue Coat X-Series), see the release notes.

Note that, although you can use this process to uninstall minor updates for Cisco NGIPS for Blue Coat X-Series, you cannot use this process to uninstall the Cisco NGIPS for Blue Coat X-Series application from the X-Series platform. For more information, see the Cisco NGIPS for Blue Coat X-Series Installation Guide.

Uninstalling the Update from Clustered or Paired Appliances

Clustered devices and Defense Centers in high availability pairs must run the same version of the FireSIGHT System. Although the uninstallation process triggers an automatic failover, appliances in mismatched pairs or clusters do not share configuration information, nor do they install or uninstall updates as part of their synchronization. If you need to uninstall an update from redundant appliances, plan to perform the uninstallations in immediate succession.

You cannot uninstall an update from devices in a clustered stack if uninstalling would revert these devices to a version in which clustered stacking is not supported.

To ensure continuity of operations, uninstall the update from clustered devices and paired Defense Centers one at a time. First, uninstall the update from the secondary appliance. Wait until the uninstallation process completes, then immediately uninstall the update from the primary appliance.

Caution If the uninstallation process on a clustered device or paired Defense Center fails, do not restart the uninstall or change configurations on its peer. Instead, contact Support.

Uninstalling the Update from Stacked Devices

All devices in a stack must run the same version of the FireSIGHT System. Uninstalling the update from any of the stacked devices causes the devices in that stack to enter a limited, mixed-version state.

To minimize impact on your deployment, Cisco recommends that you uninstall an update from stacked devices simultaneously. The stack resumes normal operation when the update completes on all devices in the stack.

You cannot uninstall an update from devices in a clustered stack if uninstalling would revert these devices to a version in which clustered stacking is not supported.

Traffic Flow and Inspection

Uninstalling an update from managed devices may affect traffic inspection, traffic flow, and link state. For specific information on how and when network traffic is affected for a particular update, see the release notes.

After the Uninstallation

After you uninstall the update, there are several steps you should take to ensure that your deployment is performing properly. These include verifying that the uninstall succeeded and that all appliances in your deployment are communicating successfully. For specific information for each update, see the release notes.

To uninstall a patch or feature update using the local web interface:

Access: Admin

Step 1 Select System > Updates.

The Product Updates page appears.

Step 2 Click the install icon next to the uninstaller for the update you want to remove.

- On the Defense Center, the Install Update page appears. Select the Defense Center and click Install .

- On a managed device, there is no intervening page.

In either case, if prompted, confirm that you want to uninstall the update and reboot the appliance.

The uninstall process begins. You can monitor its progress in the task queue (System > Monitoring > Task Status).

Caution Do not use the web interface to perform tasks other than monitoring the update until the uninstall has completed and, if necessary, the appliance reboots. For more information, see Using the Web Interface During the Update.

Step 3 After the uninstall finishes, if necessary, log into the appliance.

Step 4 Clear your browser cache and force a reload of the browser. Otherwise, the user interface may exhibit unexpected behavior.

Step 5 Select Help > About and confirm that the software version is listed correctly.

Step 6 Verify that the appliance where you uninstalled the patch is successfully communicating with its managed devices (for the Defense Center) or its managing Defense Center (for managed devices).

Updating the Vulnerability Database

License: Any

The Cisco Vulnerability Database (VDB) is a database of known vulnerabilities to which hosts may be susceptible, as well as fingerprints for operating systems, clients, and applications. The FireSIGHT System correlates the fingerprints with the vulnerabilities to help you determine whether a particular host increases your risk of network compromise. The Cisco Vulnerability Research Team (VRT) issues periodic updates to the VDB.

To update the VDB, use the Product Updates page on the Defense Center. When you upload VDB updates obtained from Support to your appliance, they appear on the page along with updates and uninstaller updates for the FireSIGHT System.

The time it takes to update vulnerability mappings depends on the number of hosts in your network map. You may want to schedule the update during low system usage times to minimize the impact of any system downtime. As a rule of thumb, divide the number of hosts on your network by 1000 to determine the approximate number of minutes to perform the update.

Note Updated application detectors and operating system fingerprints in the VDB require that you reapply access control policies before they can take effect. After you complete a VDB update, reapply any out-of-date access control policies to your managed devices. For more information, see Applying an Access Control Policy.

Caution Installing a VDB update restarts the Snort process when you apply your access control policy, temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See How Snort Restarts Affect Traffic and Updating the Vulnerability Database for more information.

This section explains how to plan for and perform manual VDB updates. You can take advantage of the automated update feature to schedule VDB updates; see Automating Vulnerability Database Updates.

To update the vulnerability database:

Access: Admin

Step 1 Read the VDB Update Advisory Text for the update.

The advisory text includes information about the changes to the VDB made in the update, as well as product compatibility information.

Step 2 Select System > Updates.

The Product Updates page appears.

Step 3 Upload the update to the Defense Center:

- If your Defense Center has access to the Internet, click Download Updates to check for the latest updates one either of the following Support Sites:

– Sourcefire: (https://support.sourcefire.com/)

– Cisco: (http://www.cisco.com/cisco/web/support/index.html)

- If your Defense Center does not have access to the Internet, manually download the update from one of the following Support Sites, then click Upload Update . Browse to the update and click Upload :

– Sourcefire: (https://support.sourcefire.com/)

– Cisco: (http://www.cisco.com/cisco/web/support/index.html)

Note Download the update directly from the Support Site either manually or by clicking Download Updates. If you transfer an update file by email, it may become corrupted.

The update is uploaded to the Defense Center.

Step 4 Click the install icon next to the VDB update.

The Install Update page appears.

Step 5 Select the Defense Center, then click Install.

The update process begins. Depending on the number of hosts in your network map, installing the update may take some time. You can monitor the update's progress in the task queue (System > Monitoring > Task Status).

Caution Do not use the web interface to perform tasks related to mapped vulnerabilities until the update has completed. If you encounter issues with the update (for example, if the task queue indicates that the update has failed or if a manual refresh of the task queue shows no progress) do not restart the update. Instead, contact Support.

Step 6 After the update finishes, select Help > About to confirm that the VDB build number matches the update you installed.

You must reapply any out-of-date access control policies for the VDB update to take effect; see Applying an Access Control Policy.

Importing Rule Updates and Local Rule Files

License: Any

As new vulnerabilities become known, the Cisco Vulnerability Research Team (VRT) releases rule updates that you can first import onto your Defense Center, then implement by applying affected access control, network analysis, and intrusion policies to your managed devices.

Rule updates are cumulative, and Cisco recommends you always import the latest update. You cannot import a rule update that either matches or predates the version of the currently installed rules. If your deployment includes a high availability pair of Defense Centers, import the update on the primary only. The secondary Defense Center receives the rule update as part of the regular synchronization process.

Note Rule updates may contain new binaries, so make sure your process for downloading and installing them complies with your security policies. In addition, rule updates may be large, so import rules during periods of low network use.

A rule update may provide the following:

- new and modified rules and rule states —Rule updates provide new and updated intrusion and preprocessor rules. For new rules, the rule state may be different in each system-provided intrusion policy. For example, a new rule may be enabled in the Security over Connectivity intrusion policy and disabled in the Connectivity over Security intrusion policy. Rule updates may also change the default state of existing rules, or delete existing rules entirely.

- new rule categories —Rule updates may include new rule categories, which are always added.

- modified preprocessor and advanced settings —Rule updates may change the advanced settings in the system-provided intrusion policies and the preprocessor settings in system-provided network analysis policies. They can also update default values for the advanced preprocessing and performance options in your access control policies.

- new and modified variables —Rule updates may modify default values for existing default variables, but do not override your changes. New variables are always added.

Understanding When Rule Updates Modify Policies

Rule updates can affect both system-provided and custom network analysis policies, as well as all access control policies:

- system provided —Changes to system-provided network analysis and intrusion policies, as well as any changes to advanced access control settings, automatically take effect when you reapply the policies after the update.

- custom —Because every custom network analysis and intrusion policy uses a system-provided policy as its base, or as the eventual base in a policy chain, rule updates can affect custom network analysis and intrusion policies. However, you can prevent rule updates from automatically making those changes. This allows you to update system-provided base policies manually, on a schedule independent of rule update imports. Regardless of your choice (implemented on a per-custom-policy basis), updates to system-provided policies do not override any settings you customized. For more information, see Allowing Rule Updates to Modify a System-Provided Base Policy.

Note that importing a rule update discards all cached changes to network analysis and intrusion policies. For your convenience, the Rule Updates page lists policies with cached changes and the users who made those changes. For more information, see Resolving Conflicts and Committing Policy Changes.

Reapplying Policies

For changes made by a rule update to take affect, you must reapply any modified policies. When importing a rule update, you can configure the system to automatically reapply intrusion or access control policies to their target devices. This is especially useful if you allow the rule update to modify system-provided base policies.

- Reapplying an access control policy also reapplies associated SSL, network analysis, and file policies, but does not reapply intrusion policies. It also updates the default values for any modified advanced settings. Because you cannot apply a network analysis policy independently, you must reapply access control policies if you want to update preprocessor settings in network analysis policies.

- Reapplying intrusion policies allows you to update rules and other changed intrusion policy settings. You can reapply intrusion policies in conjunction with access control policies, or you can apply only intrusion policies to update intrusion rules without updating any other access control configurations.

Caution When you apply an access control or intrusion policy, resource demands may result in a small number of packets dropping without inspection. Additionally, applying some configurations requires the Snort process to restart. This includes applying an access control or intrusion policy after importing an intrusion rule update that includes a new or updated shared object rule. Restarting the Snort process temporarily interrupts traffic inspection. Whether traffic drops during this interruption or passes without further inspection depends on the model of the managed device and how it handles traffic. See Configurations that Restart the Snort Process and How Snort Restarts Affect Traffic for more information.

For more information on importing rule updates, see:

- Using One-Time Rule Updates explains how to import a single rule update from the Support Site.

- Using Recurring Rule Updates explains how to use an automated feature on the web interface to download and install rule updates from the Support Site.

- Importing Local Rule Files explains how to import a copy of a standard text rules file that you have created on a local machine.

- Viewing the Rule Update Log explains the rule update log.

Using One-Time Rule Updates

License: Any

There are two methods that you can use for one-time rule updates:

- Using Manual One-Time Rule Updates explains how to manually download a rule update from the Support Site to your local machine and then manually install the rule update.

- Using Automatic One-Time Rule Updates explains how to use an automated feature on the web interface to search the Support Site for new rule updates and upload them.

Using Manual One-Time Rule Updates

License: Any

The following procedure explains how to import a new rule update manually. This procedure is especially useful if your Defense Center does not have Internet access.

To manually import a rule update:

Access: Admin

Step 1 From a computer that can access the Internet, access either of the following sites:

- Sourcefire: (https://support.sourcefire.com/ )

- Cisco: (http://www.cisco.com/cisco/web/support/index.html )

Step 2 Click Download, then click Rules.

Step 3 Navigate to the latest rule update.

Rule updates are cumulative; you cannot import a rule update that either matches or predates the version of the currently installed rules.

Step 4 Click the rule update file that you want to download and save it to your computer.

Step 5 Log into your appliance’s web interface.

Step 6 Select System > Updates, then select the Rule Updates tab.

The Rule Updates page appears.

Tip You can also click Import Rules on the Rule Editor page (Policies > Intrusion > Rule Editor).

Step 7 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created or imported to the deleted folder. See Deleting Custom Rules for more information.

Step 8 Select Rule Update or text rule file to upload and install and click Choose File to navigate to and select the rule update file.

Step 9 Optionally, reapply policies to your managed devices after the update completes:

- Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion policies. Choose only this option to update rules and other changed intrusion policy settings without having to update any other access control configurations you may have made. You must select this option to reapply intrusion policies in conjunction with access control policies; reapplying access control policies in this case does not perform a complete apply.

- Select Reapply access control policies after the rule update import completes to automatically reapply access control policies and their associated SSL, network analysis, and file policies, but not intrusion policies. Selecting this option also updates the default values for any modified access control advanced settings. Because you cannot apply a network analysis policy independently of its parent access control policy, you must reapply access control policies if you want to update preprocessor settings in network analysis policies.

Step 10 Click Import.

The system installs the rule update and displays the Rule Update Log detailed view; see Understanding the Rule Update Import Log Detailed View. The system also applies policies as you specified in the previous step; see Applying an Access Control Policy and Applying an Intrusion Policy.

Note Contact Support if you receive an error message while installing the rule update.

Using Automatic One-Time Rule Updates

License: Any

The following procedure explains how to import a new rule update by automatically connecting to the Support Site. You can use this procedure only if the appliance has Internet access.

To automatically import a rule update:

Access: Admin

Step 1 Select System > Updates, then select the Rule Updates tab.

The Rule Updates page appears.

Tip You can also click Import Rules on the Rule Editor page (Policies > Intrusion > Rule Editor).

Step 2 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created or imported to the deleted folder. See Deleting Custom Rules for more information.

Step 3 Select Download new Rule Update from the Support Site.

Step 4 Optionally, reapply policies to your managed devices after the update completes:

- Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion policies. Choose only this option to update rules and other changed intrusion policy settings without having to update any other access control configurations you may have made. You must select this option to reapply intrusion policies in conjunction with access control policies; reapplying access control policies in this case does not perform a complete apply.

- Select Reapply access control policies after the rule update import completes to automatically reapply access control policies and their associated SSL, network analysis, and file policies, but not intrusion policies. Selecting this option also updates the default values for any modified access control advanced settings. Because you cannot apply a network analysis policy independently of its parent access control policy, you must reapply access control policies if you want to update preprocessor settings in network analysis policies.

Step 5 Click Import.

The system installs the rule update and displays the Rule Update Log detailed view; see Understanding the Rule Update Import Log Detailed View. The system also applies policies as you specified in the previous step; see Applying an Access Control Policy and Applying an Intrusion Policy.

Note Contact Support if you receive an error message while installing the rule update.

Using Recurring Rule Updates

License: Any

You can import rule updates on a daily, weekly, or monthly basis, using the Rule Updates page. If your deployment includes a high availability pair of Defense Centers, import the update on the primary only. The secondary Defense Center receives the rule update as part of the regular synchronization process.

Applicable subtasks in the rule update import occur in the following order: download, install, base policy update, and policy reapply. When one subtask completes, the next subtask begins. Note that you can only apply policies previously applied by the appliance where the recurring import is configured.

To schedule recurring rule updates:

Access: Admin

Step 1 Select System > Updates, then select the Rule Updates tab.

The Rule Updates page appears.

Tip You can also click Import Rules on the Rule Editor page (Policies > Intrusion > Rule Editor).

Step 2 Optionally, click Delete All Local Rules, then click OK to move all user-defined rules that you have created or imported to the deleted folder. See Deleting Custom Rules for more information.

Step 3 Select Enable Recurring Rule Update Imports.

The page expands to display options for configuring recurring imports. Import status messages appear beneath the Recurring Rule Update Imports section heading. Recurring imports are enabled when you save your settings.

Tip To disable recurring imports, clear the Enable Recurring Rule Update Imports check box and click Save.

Step 4 In the Import Frequency field, select Daily, Weekly, or Monthly from the drop-down list.

If you selected a weekly or monthly import frequency, use the drop-down lists that appear to select the day of the week or month when you want to import rule updates. Select from a recurring task drop-down list either by clicking or by typing the first letter or number of your selection one or more times and pressing Enter.

Step 5 In the Import Frequency field, specify the time when you want to start your recurring rule update import.

Step 6 Optionally, reapply policies to your managed devices after the update completes:

- Select Reapply intrusion policies after the rule update import completes to automatically reapply intrusion policies. Choose only this option to update rules and other changed intrusion policy settings without having to update any other access control configurations you may have made. You must select this option to reapply intrusion policies in conjunction with access control policies; reapplying access control policies in this case does not perform a complete apply.

- Select Reapply access control policies after the rule update import completes to automatically reapply access control policies and their associated SSL, network analysis, and file policies, but not intrusion policies. Selecting this option also updates the default values for any modified access control advanced settings. Because you cannot apply a network analysis policy independently of its parent access control policy, you must reapply access control policies if you want to update preprocessor settings in network analysis policies.

Step 7 Click Save to enable recurring rule update imports using your settings.

The status message under the Recurring Rule Update Imports section heading changes to indicate that the rule update has not yet run. At the scheduled time, the system installs the rule update and applies policies as you specified in the previous step; see Applying an Access Control Policy and Applying an Intrusion Policy.

), and you can view messages as they occur in the Rule Update Log detailed view. Depending on the rule update size and content, several minutes may pass before status messages appear. For more information, see Viewing the Rule Update Log.

Note Contact Support if you receive an error message while installing the rule update.

Importing Local Rule Files

License: Any

A local rule is a custom standard text rule that you import from a local machine as a plain text file with ASCII or UTF-8 encoding. You can create local rules using the instructions in the Snort users manual, which is available at http://www.snort.org.

Note the following regarding importing local rules:

- The text file name can include alphanumeric characters, spaces, and no special characters other than underscore ( _ ), period ( . ), and dash ( - ).

- You do not have to specify a Generator ID (GID); if you do, you can specify only GID 1 for a standard text rule or 138 for a sensitive data rule.

- Do not specify a Snort ID (SID) or revision number when importing a rule for the first time; this avoids collisions with SIDs of other rules, including deleted rules.

The system will automatically assign the rule the next available custom rule SID of 1000000 or greater, and a revision number of 1.

- You must include the SID assigned by the system and a revision number greater than the current revision number when importing an updated version of a local rule that you have previously imported.

To view the revision number for a current local rule, display the Rule Editor page (Policies > Intrusion > Rule Editor), click on the local rule category to expand the folder, then click Edit next to the rule.

- You can reinstate a local rule that you have deleted by importing the rule using the SID assigned by the system and a revision number greater than the current revision number. Note that the system automatically increments the revision number when you delete a local rule; this is a device that allows you to reinstate local rules.

To view the revision number for a deleted local rule, display the Rule Editor page (Policies > Intrusion > Rule Editor), click on the deleted rule category to expand the folder, then click Edit next to the rule.

- You cannot import a rule file that includes a rule with a SID greater than 2147483647; the import will fail.

- If you import a rule that includes a list of source or destination ports that is longer than 64 characters, the import will fail.

- The system always sets local rules that you import to the disabled rule state; you must manually set the state of local rules before you can use them in your intrusion policy. See Setting Rule States for more information.

- You must make sure that the rules in the file do not contain any escape characters.

- The rules importer requires that all custom rules are imported in ASCII or UTF-8 encoding.

- All imported local rules are automatically saved in the local rule category.

- All deleted local rules are moved from the local rule category to the deleted rule category.

- The system imports local rules preceded with a single pound character (#), but they are flagged as deleted.

- The system ignores local rules preceded with two pound characters (##) and does not import them.

- Cisco strongly recommends that you import local rules on the primary Defense Center in a High Availability Pair to avoid SID numbering issues.

- Policy validation fails if you enable an imported local rule that uses the deprecated threshold keyword in combination with the intrusion event thresholding feature in an intrusion policy. See Configuring Event Thresholding for more information.

To import local rule files:

Access: Admin

Step 1 Select Policies > Intrusion > Rule Editor.

The Rule Editor page appears.

Step 2 Click Import Rules.

The Import Rules page appears.

Tip You can also select System > Updates, then select the Rule Updates tab.

Step 3 Select Rule Update or text rule file to upload and install and click Browse to navigate to your rule file. Note that all rules uploaded in this manner are saved in the local rule category.

Tip You can import only plain text files with ASCII or UTF-8 encoding.

Step 4 Click Import.

The rule file is imported. Make sure you enable the appropriate rules in your intrusion policies. The rules are not activated until the next time you apply the affected policies.

Note Managed devices do not use the new rule set for inspection until after you apply their intrusion policies. See Applying an Access Control Policy for procedures.

Viewing the Rule Update Log

License: Any

The Defense Center generates a record for each rule update and local rule file that you import.

Table 66-2 Rule Update Log Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Rule Update Log Table.

delete an import file record from the import log, including detailed records for all objects included with the file

) next to the file name for the import file. Note Deleting the file from the log does not delete any object imported in the import file, but only deletes the import log records.

view details for each object imported in a rule update or local rule file

) next to the file name for the import file.

See the following sections for more information:

- Understanding the Rule Update Log Table describes the fields in the list of rule updates and local rule files that you import.

- Viewing Rule Update Import Log Details describes the detailed record for each object imported in a rule update or local rule file.

- Understanding the Rule Update Import Log Detailed View describes each field in the Rule Update Log detailed view.

- Searching the Rule Update Import Log explains how you can search the import log for specific records or for all records matching the search criteria.

To view the Rule Update Log:

Access: Admin

Step 1 Select System > Updates, then select the Rule Updates tab.

The Rule Updates page appears.

Tip You can also click Import Rules on the Rule Editor page, which you access by selecting Policies > Intrusion > Rule Editor.

Step 2 Click Rule Update Log.

The Rule Update Log page appears. This page lists each imported rule update and local rule file.

Understanding the Rule Update Log Table

License: Any

The fields in the list of rule updates and local rule files that you import are described in the following table.

Table 66-3 Rule Update Log Fields

Field

Description

Summary

The name of the import file. If the import fails, a brief statement of the reason for the failure appears under the file name.

Time

The time and date that the import started.

User ID

The user name of the user that triggered the import.

Status

Whether the import:

- succeeded (

)

- failed or is currently in progress (

)

Tip The red status icon indicating an unsuccessful or incomplete import appears on the Rule Update Log page during the import and is replaced by the green icon only when the import has successfully completed.

) to delete the file record and all detailed object records imported with the file.

Tip You can view import details as they appear while a rule update import is in progress.

Viewing Rule Update Import Log Details

License: Any

The Rule Update Import Log detailed view lists a detailed record for each object imported in a rule update or local rule file. You can also create a custom workflow or report from the records listed that includes only the information that matches your specific needs.

Table 66-4 Rule Update Import Log Detailed View Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Rule Update Import Log Detailed View.

sort and constrain records on the current workflow page

find more information in Sorting Drill-Down Workflow Pages.

temporarily use a different workflow

click (switch workflows). For information on selecting workflows, see Selecting Workflows. For information on creating custom workflows, see Creating Custom Workflows.

bookmark the current page so that you can quickly return to it

click Bookmark This Page. For more information, see Using Bookmarks.

navigate to the bookmark management page

click View Bookmarks. For more information, see Using Bookmarks.

generate a report based on the data in the current view

click Report Designer. For more information, see Creating a Report Template from an Event View.

search the entire Rule Update Import Log database for rule update import records

click Search. From more information, see Searching the Rule Update Import Log.

open a search page prepopulated with the current single constraint

select Edit Search or Save Search next to Search Constraints. From more information, see the Table View and Drill-Down Page Features table.

To view the Rule Update Import Log Detailed View:

Access: Admin

Step 1 Select System > Updates, then select the Rule Updates tab.

The Rule Updates page appears.

Tip You can also click Import Rules on the Rule Editor page, which you access by selecting Policies > Intrusion > Rule Editor.

Step 2 Click Rule Update Log.

The Rule Update Log page appears.

) next to the file whose detailed records you want to view.

The table view of detailed records appears.

Understanding the Rule Update Import Log Detailed View

License: Any

You can view a detailed record for each object imported in a rule update or local rule file. The fields in the Rule Update Log detailed view are described in the following table.

Table 66-5 Rule Update Import Log Detailed View Fields

Field

Description

Time

The time and date the import began.

Name

The name of the imported object, which for rules corresponds to the rule Message field, and for rule update components is the component name.

Type

The type of imported object, which can be one of the following:

- rule update component (an imported component such as a rule pack or policy pack)

- rule (for rules, a new or updated rule; note that in Version 5.0.1 this value replaced the update value, which is deprecated)

- policy apply (the Reapply intrusion policies after the Rule Update import completes option was enabled for the import)

Action

An indication that one of the following has occurred for the object type:

- new (for a rule, this is the first time the rule has been stored on this appliance)

- changed (for a rule update component or rule, the rule update component has been modified, or the rule has a higher revision number and the same GID and SID)

- collision (for a rule update component or rule, import was skipped because its revision conflicts with an existing component or rule on the appliance)

- deleted (for rules, the rule has been deleted from the rule update)

- enabled (for a rule update edit, a preprocessor, rule, or other feature has been enabled in a default policy provided by Cisco)

- disabled (for rules, the rule has been disabled in a default policy provided by Cisco)

- drop (for rules, the rule has been set to Drop and Generate Events in a default policy provided by Cisco)

- error (for a rule update or local rule file, the import failed)

- apply (the Reapply intrusion policies after the Rule Update import completes option was enabled for the import)

Default Action

The default action defined by the rule update. When the imported object type is rule, the default action is Pass, Alert, or Drop. For all other imported object types, there is no default action.

GID

The generator ID for a rule. For example, 1 (standard text rule) or 3 (shared object rule). See Table 41-7 for more information.

SID

The SID for a rule.

Rev

The revision number for a rule.

Policy

For imported rules, this field displays All, which indicates that the imported rule was included in all default intrusion policies. For other types of imported objects, this field is blank.

Details

A string unique to the component or rule. For rules, the GID, SID, and previous revision number for a changed rule, displayed as previously (GID:SID:Rev). This field is blank for a rule that has not changed.

Count

The count (1) for each record. The Count field appears in a table view when the table is constrained, and the Rule Update Log detailed view is constrained by default to rule update records.

Searching the Rule Update Import Log

License: Any

Note Beta Users: This feature will be fully explained in the final version of the documentation.

You can search the import log for specific records or for all records matching the search criteria. You may want to create customized searches and save them to reuse later.

Tip You search the entire Rule Update Import Log database even when you initiate a search by clicking Search on the toolbar from the Rule Update Import Log detailed view with only the records for a single import file displayed. Make sure you set your time constraints to include all objects you want to include in the search. See Specifying Time Constraints in Searches for more information.

Table 66-6 Rule Update Import Log Search Criteria

Search Field

Description

Example

Time

Specify the date and time the record was generated. See Specifying Time Constraints in Searches for the syntax for entering time.

> 2006-01-15 13:30:00 returns all rule records imported after January 15, 2006 at 1:30 PM.

Name

Specify all or part of the content of the rule Message field. You can use an asterisk (*) as a wildcard character in this field.

*dhcp* returns all rule records with DHCP in the Message field.

Type

Specify the type of record, which can be rule update component, rule, or policy apply.

Note that you can use the update search value to search for rules imported prior to Version 5.0.1.

update returns imported rule update components such as a rule pack or policy pack; rule returns rule updates, including new rules; policy apply returns a table row of information for rule updates where intrusion policies were automatically reapplied following the update.

Action

Specify an action for the object you want to view. See the Rule Update Import Log Detailed View Fields table for a list of actions you can specify.

When the type is rule, new returns all rules imported for the first time on the appliance.

GID

Specify the generator ID for the rule.

3 returns all shared object rules.

SID

Specify a signature ID or a range of SIDs for a rule.

923 returns the record for the rule with the SID 923.

Rev

Specify the revision number for the rule.

3 returns rules with the revision number 3.

Policy

Specify the default policy the rule is imported into.

All returns rules imported into all default policies.

Rule Update

Specify the Rule Update filename.

filename returns all records for the specified import file.

Details

Specify details on the imported object.

previously* returns the record for all rules that have changed.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

To search the Rule Update Import Log:

Access: Admin/Intrusion Admin

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 From the Table drop-down list, select Rule Update Import Log.

The page reloads with the appropriate constraints.

Tip You can also click Search on the Rule Update Log detailed view; see Viewing Rule Update Import Log Details.

Step 3 Optionally, if you want to save the search, enter a name for the search in the Name field.

If you do not enter a name, the web interface automatically creates one when you save it.

Step 4 Enter your search criteria in the appropriate fields, as described in the Rule Update Import Log Search Criteria table. If you enter multiple criteria, the search returns the records that match all the criteria.

Step 5 If you want to save the search so that other users can access it, clear the Save As Private check box. Otherwise, leave the check box selected to save the search as private.

If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 6 You have the following options:

- Click Search to start the search.

Your search results appear in the default Rule Update Import Log detailed view workflow. To use a different workflow, including a custom workflow, click (switch workflows). For information on specifying a different default workflow, see Configuring Event View Settings.

- Click Save if you are modifying an existing search and want to save your changes.

- Click Save as New Search to save the search criteria. The search is saved (and associated with your user account if you selected Save As Private ) so that you can run it at a later time.

Updating the Geolocation Database

License: FireSIGHT

Supported Defense Centers: Any except DC500

The Cisco Geolocation Database (GeoDB) is a database of geographical data (such as country, city, coordinates, and so on) and connection-related data (such as Internet service provider, domain name, connection type, and so on) associated with routable IP addresses. When your system detects GeoDB information that matches a detected IP address, you can view the geolocation information associated with that IP address. You must install the GeoDB on your system to view any geolocation details other than country or continent. Cisco issues periodic updates to the GeoDB.

To update the GeoDB, use the Geolocation Updates page (System > Updates > Geolocation Updates) on the Defense Center. When you upload GeoDB updates you obtained from Support or from your appliance, they appear on this page.

Time needed to update the GeoDB depends on your appliance; the installation usually takes 30 to 40 minutes. Although a GeoDB update does not interrupt any other system functions (including the ongoing collection of geolocation information), the update does consume system resources while it completes. Consider this when planning your updates.

This section explains how to plan for and perform manual GeoDB updates. You can also take advantage of the automated update feature to schedule GeoDB updates; for more information, see Automating Geolocation Database Updates. For more information on geolocation, see Using Geolocation.

To update the geolocation database:

Access: Admin

Step 1 Select System > Updates.

The Product Updates page appears.

Step 2 Click the Geolocation Updates tab.

The Geolocation Updates page appears.

Step 3 Upload the update to the Defense Center.

- If your Defense Center has access to the Internet, click Download and install geolocation update from the Support Site to check for the latest updates on either of the Support Sites:

– Sourcefire: (https://support.sourcefire.com/)

– Cisco: (http://www.cisco.com/cisco/web/support/index.html)

- If your Defense Center does not have access to the Internet, manually download the update from either of the Support Sites, then click Upload and install geolocation update . Browse to the update and click Import :

– Sourcefire: (https://support.sourcefire.com/)

– Cisco: (http://www.cisco.com/cisco/web/support/index.html)

Note Download the update directly from the Support Site, either manually or by clicking Download and install geolocation update from the Support Site on the Geolocation Updates page. If you transfer an update file by email, it may become corrupted.

The update process begins. The average duration of update installation is 30 to 40 minutes; this may vary depending on your appliance hardware. You can monitor the update’s progress in the task queue (System > Monitoring > Task Status).

Step 4 After the update finishes, return to the Geolocation Updates page or select Help > About to confirm that the GeoDB build number matches the update you installed.

The GeoDB update overrides any previous versions of the GeoDB and is effective immediately. When you update the GeoDB, the Defense Center automatically updates its managed devices. Although it may take a few minutes for a GeoDB update to take effect throughout your deployment, you do not have to reapply access control policies after you update.

Monitoring the System

The FireSIGHT System provides many useful monitoring features to assist you in the daily administration of your system, all on a single page. For example, on the Host Statistics page you can monitor basic host statistics and intrusion event information, as well as statistics for the Data Correlator and network discovery processes for the current day. You can also monitor both summary and detailed information on all processes that are currently running on the Defense Center or managed device. The following sections provide more information about the monitoring features that the system provides:

- Viewing Host Statistics describes how to view host information such as:

- system uptime

- disk and memory usage

- Data Correlator statistics

- system processes

- intrusion event information

- On the Defense Center, you can also use the health monitor to monitor disk usage and alert on low disk space conditions. For more information, see Understanding Health Monitoring.

- Monitoring System Status and Disk Space Usage describes how to view basic event and disk partition information.

- Viewing System Process Status describes how to view basic process status.

- Understanding Running Processes describes the basic system processes that run on the appliance.

You can use the options in Overview > Summary to view and graph statistics for intrusion and discovery events. For more information, see:

- Viewing Intrusion Event Statistics

- Viewing Intrusion Event Graphs

- Viewing Discovery Event Statistics

- Viewing Discovery Performance Graphs

Viewing Host Statistics

License: Any

The Statistics page lists the current status of the following:

- general host statistics; see the Host Statistics table for details

- Data Correlator statistics (Defense Center only — requires FireSIGHT); see the Data Correlator Process Statistics table for details

- intrusion event information (requires Protection); see the Intrusion Event Information table for details

The following table describes the host statistics listed on the Statistics page.

Table 67-1 Host Statistics

Category

Description

Time

The current time on the system.

Uptime

The number of days (if applicable), hours, and minutes since the system was last started.

Memory Usage

The percentage of system memory that is being used.

Load Average

The average number of processes in the CPU queue for the past 1 minute, 5 minutes, and 15 minutes.

Disk Usage

The percentage of the disk that is being used. Click the arrow to view more detailed host statistics. See Monitoring System Status and Disk Space Usage for more information.

Processes

A summary of the processes running on the system. See Viewing System Process Status for more information.

If your FireSIGHT System deployment includes a Defense Center with a FireSIGHT license, you can also view statistics about the Data Correlator and network discovery processes for the current day. As the managed devices perform data acquisition, decoding, and analysis, the network discovery process correlates the data with the fingerprint and vulnerability databases, then produces binary files that are processed by the Data Correlator running on the Defense Center. The Data Correlator analyzes the information from the binary files, generates events, and creates the discovery network map.

The statistics that appear for network discovery and the Data Correlator are averages for the current day, using statistics gathered between 12:00 AM and 11:59 PM for each device.

The following table describes the statistics displayed for the Data Correlator process.

Table 67-2 Data Correlator Process Statistics

Category

Description

Events/Sec

Number of discovery events that the Data Correlator receives and processes per second

Connections/Sec

Number of connections that the Data Correlator receives and processes per second

CPU Usage — User (%)

Average percentage of CPU time spent on user processes for the current day

CPU Usage — System (%)

Average percentage of CPU time spent on system processes for the current day

VmSize (KB)

Average size of memory allocated to the Data Correlator for the current day, in kilobytes

VmRSS (KB)

Average amount of memory used by the Data Correlator for the current day, in kilobytes

On managed devices and on Defense Centers that manage devices, you can also view the date and time of the last intrusion event, the total number of events that have occurred in the past hour and the past day, and the total number of events in the database.

Note The information in the Intrusion Event Information section of the Statistics page is based on intrusion events stored on the managed device rather than those sent to the Defense Center. If you manage your device so that intrusion events are not stored locally, no intrusion event information is listed on this page. This is also the case for managed devices that cannot store events locally.

The following table describes the statistics displayed in the Intrusion Event Information section of the Statistics page.

Table 67-3 Intrusion Event Information

Statistic

Description

Last Alert Was

The date and time that the last event occurred

Total Events Last Hour

The total number of events that occurred in the past hour

Total Events Last Day

The total number of events that occurred in the past twenty-four hours

Total Events in Database

The total number of events in the events database

To view the Statistics page:

Access: Admin/Maint

Step 1 Select System > Monitoring > Statistics.

The Statistics page appears.

Step 2 On the Defense Center, you can also list statistics for managed devices. From the Select Device(s) box, click Select Devices. You can use the Shift and Ctrl keys to select multiple devices at once.

The Statistics page is updated with statistics for the devices you selected.

Monitoring System Status and Disk Space Usage

License: Any

The Disk Usage section of the Statistics page provides a quick synopsis of disk usage, both by category and by partition status. If you have a malware storage pack installed on a device, you can also check its partition status. You can monitor this page from time to time to ensure that enough disk space is available for system processes and the database.

Tip On the Defense Center, you can also use the health monitor to monitor disk usage and alert on low disk space conditions. For more information, see Understanding Health Monitoring.

To access disk usage information:

Access: Admin/Maint

Step 1 Select System > Monitoring > Statistics.

The Statistics page appears.

Step 2 Hover your pointer over a disk usage category in the By Category stacked bar to view (in order):

- the percentage of available disk space used by that category

- the actual storage space on the disk

- the total disk space available for that category

For more information on the disk usage categories, see Understanding the Disk Usage Widget.

Step 3 Click the down arrow next to Total to expand it.

The Disk Usage section expands, displaying partition usage. If you have a malware storage pack installed, the /var/storage partition usage is also displayed.

If your deployment includes multiple managed devices, you may want to constrain disk usage data by specific devices.

On the Defense Center, to view disk usage information for a specific device:

Access: Admin/Maint

Step 1 Select the device name from the Select Device(s) box, and click Select Devices.

The page reloads, listing host statistics for each device you selected.

Step 2 Click the down arrow next to Disk Usage to expand it.

The Disk Usage section expands.

Viewing System Process Status

License: Any

The Processes section of the Host Statistics page allows you to see the processes that are currently running on an appliance. It provides general process information and specific information for each running process. If you are managing devices with a Defense Center, you can use the Defense Center’s web interface to view the process status for any managed device.

The following table describes each column that appears in the process list.

Table 67-4 Process Status

Column

Description

Pid

The process ID number

Username

The name of the user or group running the process

Pri

The process priority

Nice

The nice value, which is a value that indicates the scheduling priority of a process. Values range between -20 (highest priority) and 19 (lowest priority)

Size

The memory size used by the process (in kilobytes unless the value is followed by m, which indicates megabytes)

Res

The amount of resident paging files in memory (in kilobytes unless the value is followed by m, which indicates megabytes)

State

The process state:

- D — process is in uninterruptible sleep (usually Input/Output)

- N — process has a positive nice value

- R — process is runnable (on queue to run)

- S — process is in sleep mode

- T — process is being traced or stopped

- W — process is paging

- X — process is dead

- Z — process is defunct

- < — process has a negative nice value

Time

The amount of time (in hours:minutes:seconds) that the process has been running

Cpu

The percentage of CPU that the process is using

Command

The executable name of the process

To expand the process list:

Access: Admin/Maint

Step 1 Select System > Monitoring > Statistics.

The Statistics page appears.

Step 2 On the Defense Center, select the device or devices you want to view process statistics for from the Select Device(s) box and click Select Devices.

Step 3 Click the down arrow next to Processes.

The process list expands, listing general process status information that includes the number and types of running tasks, the current time, the current system uptime, the system load average, CPU, memory, and swap information, and specific information about each running process.

Cpu(s) lists the following CPU usage information:

- user process usage percentage

- system process usage percentage

- nice usage percentage (CPU usage of processes that have a negative nice value, indicating a higher priority)

Nice values indicate the scheduled priority for system processes and can range between -20 (highest priority) and 19 (lowest priority).

- idle usage percentage

Mem lists the following memory usage information:

- total number of kilobytes in memory

- total number of used kilobytes in memory

- total number of free kilobytes in memory

- total number of buffered kilobytes in memory

Swap lists the following swap usage information:

- total number of kilobytes in swap

- total number of used kilobytes in swap

- total number of free kilobytes in swap

- total number of cached kilobytes in swap

Note For more information about the types of processes that run on the appliance, see Understanding Running Processes.

To collapse the process list:

Access: Admin/Maint

Step 1 Click the up arrow next to Processes.

The process list collapses.

Understanding Running Processes

License: Any

There are two different types of processes that run on an appliance: daemons and executable files. Daemons always run, and executable files are run when required.

See the following sections for more information:

- Understanding System Daemons

- Understanding Executables and System Utilities

Understanding System Daemons

License: Any

Daemons continually run on an appliance. They ensure that services are available and spawn processes when required. The following table lists daemons that you may see on the Process Status page and provides a brief description of their functionality.

Note The table below is not an exhaustive list of all processes that may run on an appliance.

Table 67-5 System Daemons

Daemon

Description

crond

Manages the execution of scheduled commands (cron jobs)

dhclient

Manages dynamic host IP addressing

fpcollect

Manages the collection of client and server fingerprints

httpd

Manages the HTTP (Apache web server) process

httpsd

Manages the HTTPS (Apache web server with SSL) service, and checks for working SSL and valid certificate authentication; runs in the background to provide secure web access to the appliance

keventd

Manages Linux kernel event notification messages

klogd

Manages the interception and logging of Linux kernel messages

kswapd

Manages Linux kernel swap memory

kupdated

Manages the Linux kernel update process, which performs disk synchronization

mysqld

Manages FireSIGHT System database processes

ntpd

Manages the Network Time Protocol (NTP) process

pm

Manages all Cisco processes, starts required processes, restarts any process that fails unexpectedly

reportd

Manages reports

safe_mysqld

Manages safe mode operation of the database; restarts the database daemon if an error occurs and logs runtime information to a file

SFDataCorrelator

Manages data transmission

sfestreamer

(Defense Center only)

Manages connections to third-party client applications that use the Event Streamer

sfmgr

Provides the RPC service for remotely managing and configuring an appliance using an sftunnel connection to the appliance

SFRemediateD

(Defense Center only — requires FireSIGHT)

Manages remediation responses

sftimeserviced

(Defense Center only)

Forwards time synchronization messages to managed devices

sfmbservice

(requires Protection)

Provides access to the sfmb message broker process running on a remote appliance, using an sftunnel connection to the appliance. Currently used only by health monitoring to send health events and alerts from a managed device to a Defense Center or, in a high availability environment, between Defense Centers

sftroughd

Listens for connections on incoming sockets and then invokes the correct executable (typically the Cisco message broker, sfmb) to handle the request

sftunnel

Provides the secure communication channel for all processes requiring communication with a remote appliance

sshd

Manages the Secure Shell (SSH) process; runs in the background to provide SSH access to the appliance

syslogd

Manages the system logging (syslog) process

Understanding Executables and System Utilities

License: Any

There are a number of executables on the system that run when executed by other processes or through user action. The following table describes the executables that you may see on the Process Status page.

Table 67-6 System Executables and Utilities

Executable

Description

awk

Utility that executes programs written in the awk programming language

bash

GNU Bourne-Again SHell

cat

Utility that reads files and writes content to standard output

chown

Utility that changes user and group file permissions

chsh

Utility that changes the default login shell

SFDataCorrelator

(Defense Center only — requires FireSIGHT)

Analyzes binary files created by FireSIGHT to generate events, connection data, and the network map

cp

Utility that copies files

df

Utility that lists the amount of free space on the appliance

echo

Utility that writes content to standard output

egrep

Utility that searches files and folders for specified input; supports extended set of regular expressions not supported in standard grep

find

Utility that recursively searches directories for specified input

grep

Utility that searches files and directories for specified input

halt

Utility that stops the server

httpsdctl

Handles secure Apache Web processes

hwclock

Utility that allows access to the hardware clock

ifconfig

Indicates the network configuration executable. Ensures that the MAC address stays constant

iptables

Handles access restriction based on changes made to the Access Configuration page. See Configuring the Access List for Your Appliance for more information about access configuration.

iptables-restore

Handles iptables file restoration

iptables-save

Handles saved changes to the iptables

kill

Utility that can be used to end a session and process

killall

Utility that can be used to end all sessions and processes

ksh

Public domain version of the Korn shell

logger

Utility that provides a way to access the syslog daemon from the command line

md5sum

Utility that prints checksums and block counts for specified files

mv

Utility that moves (renames) files

myisamchk

Indicates database table checking and repairing

mysql

Indicates a database process; multiple instances may appear

openssl

Indicates authentication certificate creation

perl

Indicates a perl process

ps

Utility that writes process information to standard output

sed

Utility used to edit one or more text files

sfheartbeat

Identifies a heartbeat broadcast, indicating that the appliance is active; heartbeat used to maintain contact between a device and Defense Center

sfmb

Indicates a message broker process; handles communication between Defense Centers and device.

sh

Public domain version of the Korn shell

shutdown

Utility that shuts down the appliance

sleep

Utility that suspends a process for a specified number of seconds

smtpclient

Mail client that handles email transmission when email event notification functionality is enabled

snmptrap

Forwards SNMP trap data to the SNMP trap server specified when SNMP notification functionality is enabled

snort

(requires Protection)

Indicates that Snort is running

ssh

Indicates a Secure Shell (SSH) connection to the appliance

sudo

Indicates a sudo process, which allows users other than admin to run executables

top

Utility that displays information about the top CPU processes

touch

Utility that can be used to change the access and modification times of specified files

vim

Utility used to edit text files

wc

Utility that performs line, word, and byte counts on specified files

Using Health Monitoring

The health monitor provides numerous tests for determining the health of an appliance from the Defense Center. You can use the health monitor to create a collection of tests, referred to as a health policy, and apply the health policy to one or more appliances. You can create one health policy for every appliance in your system, customize a health policy for the specific appliance where you plan to apply it, or use the default health policy. You can also import a health policy exported from another Defense Center.

The tests, referred to as health modules, are scripts that test for criteria you specify. You can modify a health policy by enabling or disabling tests or by changing test settings, and you can delete health policies that you no longer need. You can also suppress messages from selected appliances by blacklisting them.

The tests in a health policy run automatically at the interval you configure. You can also run all tests, or a specific test, on demand. The health monitor collects health events based on the test conditions configured. Optionally, you can also configure email, SNMP, or syslog alerting in response to health events.

On the Defense Center, you can view health status information for the entire system or for a particular appliance. Fully customizable event views allow you to quickly and easily analyze the health status events gathered by the health monitor. These event views allow you to search and view event data and to access other information that may be related to the events you are investigating.

You can also generate troubleshooting files for an appliance if you are asked to do so by Support.

See the following sections for more information:

- Understanding Health Monitoring

- Configuring Health Policies

- Using the Health Monitor Blacklist

- Configuring Health Monitor Alerts

- Using the Health Monitor

- Using Appliance Health Monitors

- Working with Health Events

Understanding Health Monitoring

License: Any

You can use the health monitor to check the status of critical functionality across your FireSIGHT System deployment. Monitor the health of your entire FireSIGHT System through the Defense Center by applying health policies to each of the managed devices and collecting the resulting health data at the Defense Center. Pie charts and status tables on the Health Monitor page visually represent the health status for monitored appliances, so you can check status at a glance, then drill down into status details if needed.

You can use the health monitor to access health status information for the entire system or for a particular appliance. The Health Monitor page provides a visual summary of the status of all appliances on your system. Individual appliance health monitors let you drill down into health details for a specific appliance.

You can also view health events in the standard FireSIGHT System table view. From an individual appliance’s health monitor, you can open a table view of occurrences of a specific event, or you can retrieve all the health events for that appliance. You can also search for specific health events. For example, if you want to see all the occurrences of CPU usage with a certain percentage, you can search for the CPU usage module and enter the percentage value.

You can also configure email, SNMP, or syslog alerting in response to health events. A health alert is an association between a standard alert and a health status level. For example, if you need to make sure an appliance never fails due to hardware overload, you can set up an email alert. You can then create a health alert that triggers that email alert whenever CPU, disk, or memory usage reaches the Warning level you configure in the health policy applied to that appliance. You can set alerting thresholds to minimize the number of repeating alerts you receive.

Because health monitoring is an administrative activity, only users with administrator user role privileges can access system health data. For more information on assigning user privileges, see Modifying User Privileges and Options.

Note Except for the Defense Center, FireSIGHT System devices do not have health monitoring policies applied to them by default. Managed devices report hardware status automatically via the Hardware Alarms health module; if you want to use other modules to monitor a managed device, you must apply a health policy to that device. For more information on the Cisco-provided default health policy for your appliances, see Understanding the Default Health Policy. For more information on creating customized health policies, see Creating Health Policies. For details on applying policies, see Applying Health Policies.

For more information on health policies and the health modules you can run to test system health, see the following topics:

- Understanding Health Policies

- Understanding Health Modules

- Understanding Health Monitoring Configuration

Understanding Health Policies

License: Any

A health policy is a collection of health module settings you apply to an appliance to define the criteria that the Defense Center uses when checking the health of the appliance. The health monitor tracks a variety of health indicators to ensure that your FireSIGHT System hardware and software are working correctly.

When you create health policies, you choose which tests to run to determine appliance health. You can also apply the default health policy to any appliance.

Understanding Health Modules

License: Any

Health modules, also sometimes referred to as health tests, are scripts that test for the criteria you specify in a health policy. The available health modules are described in the following table.

Table 68-1 Health Modules

Module

Description

Advanced Malware Protection

This module alerts if the Defense Center cannot contact the Collective Security Intelligence Cloud, either to retrieve file disposition information for files detected in network traffic or to submit files for dynamic analysis, or if an excessive number of files are detected in network traffic, based on the file policy configuration. Connections via the FireAMP Private Cloud also generate alerts if the private cloud cannot connect to the public Cisco cloud.

This module runs on all Defense Centers except the DC500, which does not support advanced malware protection.

Appliance Heartbeat

This module determines if an appliance heartbeat is being heard from the appliance and alerts based on the appliance heartbeat status.

Automatic Application Bypass Status

This module determines if an appliance has been bypassed because it did not respond within the number of seconds set in the bypass threshold, and alerts when a bypass occurs.

CPU Usage

This module checks that the CPU on the appliance is not overloaded and alerts when CPU usage exceeds the percentages configured for the module.

This module is not available for health policies applied to 3D9900 devices.

Card Reset

This module checks for network cards which have restarted due to hardware failure and alerts when a reset occurs.

Disk Status

This module examines performance of the hard disk, and malware storage pack (if installed) on the appliance. It alerts when the hard disks and RAID controller (if installed) are in danger of failing, or if the malware storage pack is not detected after installation or inauthentic.

Disk Usage

This module compares disk usage on the appliance’s hard drive and malware storage pack to the limits configured for the module and alerts when usage exceeds the percentages configured for the module. This module also alerts when the system excessively deletes files in monitored disk usage categories, or when disk usage excluding those categories reaches excessive levels, based on module thresholds.

FireAMP Status Monitor

The module alerts if the Defense Center cannot connect to the Cisco cloud after an initial successful connection, if you deregister a cloud connection using the FireAMP portal, or if your private cloud is unable to communicate with the public Cisco cloud.

This module only runs on Defense Centers.

FireSIGHT Host License Limit

This module determines if sufficient FireSIGHT host licenses remain and alerts based on the warning level configured for the module.

This module only runs on Defense Centers.

Hardware Alarms

This module determines if hardware needs to be replaced on a Series 3 or 3D9900 device and alerts based on the hardware status. The module also reports on the status of hardware-related daemons and on the status of clustered appliances.

For more information on the details reported for these devices, see Interpreting Hardware Alert Details for 3D9900 Devices and Interpreting Hardware Alert Details for Series 3 Devices.

Health Monitor Process

This module monitors the status of the health monitor itself and alerts if the number of minutes since the last health event received by the Defense Center exceeds the Warning or Critical limits.

This module only runs on Defense Centers.

Inline Link Mismatch Alarms

This module monitors the ports associated with inline sets and alerts if the two interfaces of an inline pair negotiate different speeds.

Intrusion Event Rate

This module compares the number of intrusion events per second to the limits configured for this module and alerts if the limits are exceeded. If the Intrusion Event Rate is zero, the intrusion process may be down or the managed device may not be sending events. Select Analysis > Intrusions > Events to check if events are being received from the device.

Interface Status

This module determines if the device currently collects traffic and alerts based on the traffic status of physical interfaces and aggregate interfaces. For physical interfaces, the information includes interface name, link state, and bandwidth. For aggregate interfaces, the information includes interface name, number of active links, and total aggregate bandwidth.

License Monitor

This module determines if sufficient licenses for Control, Protection, URL Filtering, Malware, and VPN remain. It also alerts when devices in a stack have mismatched license sets. It alerts based on a warning level automatically configured for the module. You cannot change the configuration of this module.

This module only runs on Defense Centers.

Link State Propagation

This module determines when a link in a paired inline set fails and triggers the link state propagation mode.

Memory Usage

This module compares memory usage on the appliance to the limits configured for the module and alerts when usage exceeds the levels configured for the module.

Power Supply

This module determines if power supplies on the device require replacement and alerts based on the power supply status.

This module runs on these Defense Centers: DC1500, DC2000, DC3500, DC4000.

This module runs on these devices: 3D3500, 3D4500, 3D6500, 3D9900, and Series 3.

Process Status

This module determines if processes on the appliance exit or terminate outside of the process manager. If a process is deliberately exited outside of the process manager, the module status changes to Warning and the health event message indicates which process exited, until the module runs again and the process has restarted. If a process terminates abnormally or crashes outside of the process manager, the module status changes to Critical and the health event message indicates the terminated process, until the module runs again and the process has restarted.

Reconfiguring Detection

This module determines if detection capabilities persist after a failed policy apply on a registered managed device. If detection capabilities appear un-operational after a policy apply fails, the module generates health alerts until detection capabilities are reestablished.

RRD Server Process

This module determines if the round robin data server that stores time series data is running properly and alerts based on the number of recent RRD server restarts.

This module only runs on Defense Centers.

Security Intelligence

This module alerts in a variety of situations involving Security Intelligence filtering, including feed update, feed corruption, and memory issues.

This module runs on all Defense Centers except the DC500, which does not support Security Intelligence filtering.

Time Series Data Monitor

This module tracks the presence of corrupt files in the directory where time series data (such as compliance event counts) are stored and alerts when files are flagged as corrupt and removed.

This module only runs on Defense Centers.

Time Synchronization Status

This module tracks the synchronization of a device clock that obtains time using NTP with the clock on the NTP server and alerts if the difference in the clocks is more than ten seconds.

URL Filtering Monitor

This module tracks communication between the Defense Center and the Cisco cloud, where the system obtains its URL filtering (category and reputation) data for commonly visited URLs. The module alerts if the Defense Center fails to successfully communicate with or retrieve an update from the cloud.

This module also tracks communications between the Defense Center and any managed devices where you have enabled URL filtering. The module alerts if the Defense Center cannot push URL filtering data to those devices.

This module only runs on all Defense Centers except the DC500, which does not support URL filtering.

User Agent Status Monitor

This module alerts when heartbeats are not detected for any User Agents connected to the Defense Center.

This module only runs on Defense Centers.

VPN Status

This module alerts when the system detects that the VPN feature is not functioning.

This module only runs on Defense Centers.

Understanding Health Monitoring Configuration

License: Any

There are several steps to setting up health monitoring on your FireSIGHT System, as indicated in the following procedure:

Step 1 Create health policies for your appliances.

You can set up specific policies for each kind of appliance you have in your FireSIGHT System, enabling only the appropriate tests for that appliance.

Tip If you want to quickly enable health monitoring without customizing the monitoring behavior, you can apply the default policy provided for that purpose.

For more information on setting up health policies, see Configuring Health Policies.

Step 2 Apply a health policy to each appliance where you want to track health status. For information on the default health policy available for immediate application, see Understanding the Default Health Policy.

Step 3 Optionally, configure health monitor alerts.

You can set up email, syslog, or SNMP alerts that trigger when the health status level reaches a particular severity level for specific health modules.

For more information on setting up health monitor alerts, see Configuring Health Monitor Alerts.

After you set up health monitoring on your system, you can view the health status at any time on the Health Monitor page or the Health Events table view. For more information about viewing system health data, see the following topics:

- Using the Health Monitor

- Using Appliance Health Monitors

- Working with Health Events

Configuring Health Policies

License: Any

A health policy contains configured health test criteria for several modules. You can control which health modules run against each of your appliances and configure the specific limits used in the tests run by each module. For more information on the health modules you can configure in a health policy, see Understanding Health Monitoring.

You can create one health policy that can be applied to every appliance in your system, customize each health policy to the specific appliance where you plan to apply it, or use the default health policy provided for you. You can also import a health policy exported from another Defense Center.

When you configure a health policy, you decide whether to enable each health module for that policy. You also select the criteria that control which health status each enabled module reports each time it assesses the health of a process.

For more information on the default health policy, which is applied to the Defense Center automatically, see Understanding the Default Health Policy.

For more information, see the following topics:

- Understanding the Default Health Policy

- Creating Health Policies

- Applying Health Policies

- Editing Health Policies

- Comparing Health Policies

- Deleting Health Policies

Understanding the Default Health Policy

License: Any

The Defense Center health monitor includes a default health policy to make it easier for you to quickly implement health monitoring for your appliances. The default health policy is automatically applied to the Defense Center. You cannot edit the default health policy, but you can copy it to create custom policies based on its configuration. For more information, see Creating Health Policies.

To also monitor device health, you can push health policies to your managed devices.

Note You cannot apply a health policy to Cisco NGIPS for Blue Coat X-Series.

Module

Defense Center

Managed Device

Advanced Malware Protection

yes

no

Appliance Heartbeat

yes

no

Automatic Application Bypass

no

yes

CPU Usage

no

no

Card Reset

no

no

Disk Status

yes

yes

Disk Usage

yes

yes

FireAMP Status Monitor

yes

no

FireSIGHT Host License Limit

yes

no

Hardware Alarm

no

yes

Health Monitor Process

no

no

Inline Link Mismatch Alarms

no

yes

Interface Status

no

yes

Intrusion Event Rate

no

yes

License Monitor

yes

no

Link State Propagation

no

yes

Memory Usage

yes

yes

Power Supply

no

yes

Process Status

yes

yes

Reconfiguring Detection

no

yes

RRD Server Process

yes

no

Security Intelligence

yes

no

Time Series Data Monitor

yes

no

Time Synchronization Status

yes

yes

URL Filtering Monitor

yes

no

User Agent Status Monitor

yes

no

VPN Status

yes

no

Creating Health Policies

License: Any

If you want to customize a health policy to use with your appliances, you can create a new policy. The settings in the policy initially populate with the settings from the health policy you select as a basis for the new policy. You can enable or disable modules within the policy and change the alerting criteria for each module as needed.

Tip Instead of creating a new policy, you can export a health policy from another Defense Center and then import it onto your Defense Center. You can then edit the imported policy to suit your needs before you apply it. For more information, see Importing and Exporting Configurations.

To create a health policy:

Access: Admin/Maint

Step 1 Select Health > Health Policy.

The Health Policy page appears.

Step 2 Click Create Policy.

The Create Health Policy page appears.

Step 3 Select the existing policy that you want to use as the basis for the new policy from the Copy Policy drop-down list.

Step 4 Enter a name for the policy.

Step 5 Enter a description for the policy.

Step 6 Select Save to save the policy information.

The Health Policy Configuration page appears, including a list of the modules.

Step 7 Configure settings on each module you want to use to test the health status of your appliances, as described in the following sections:

- Configuring Policy Run Time Intervals

- Configuring Advanced Malware Protection Monitoring

- Configuring Appliance Heartbeat Monitoring

- Configuring Automatic Application Bypass Monitoring

- Configuring CPU Usage Monitoring

- Configuring Card Reset Monitoring

- Configuring Disk Status Monitoring

- Configuring Disk Usage Monitoring

- Configuring FireAMP Status Monitoring

- Configuring FireSIGHT Host Usage Monitoring

- Configuring Hardware Alarm Monitoring

- Configuring Health Status Monitoring

- Configuring Inline Link Mismatch Alarm Monitoring

- Configuring Interface Status Monitoring

- Configuring Intrusion Event Rate Monitoring

- Understanding License Monitoring

- Configuring Link State Propagation Monitoring

- Configuring Memory Usage Monitoring

- Configuring Power Supply Monitoring

- Configuring Process Status Monitoring

- Configuring Reconfiguring Detection Monitoring

- Configuring RRD Server Process Monitoring

- Configuring Security Intelligence Monitoring

- Configuring Time Series Data Monitoring

- Configuring Time Synchronization Monitoring

- Configuring URL Filtering Monitoring

- Configuring User Agent Status Monitoring

- Configuring VPN Status Monitoring

Note Make sure you enable each module that you want to run to test the health status on each Health Policy Configuration page as you configure the settings. Disabled modules do not produce health status feedback, even if the policy that contains the module has been applied to an appliance.

Step 8 Click Save Policy and Exit to save the policy.

You must apply the policy to each appliance for it to take effect. For more information on applying health policies, see Applying Health Policies.

Configuring Policy Run Time Intervals

License: Any

You can control how often health tests run by modifying the Policy Run Time Interval for the health policy. The maximum run time interval you can set is 99999 minutes.

Caution Do not set a run interval of less than five minutes.

To configure a policy run time interval:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select Policy Run Time Interval.

The Health Policy Configuration — Policy Run Time Interval page appears.

Step 2 In the Run Interval (mins) field, enter the time in minutes that you want to elapse between automatic repetitions of the test.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Advanced Malware Protection Monitoring

License: Malware

This module tracks the state and stability of the Defense Center’s ability to query the Cisco cloud and detect files in network traffic. If the system detects that your connection with the cloud is interrupted, the encryption keys used for the connection are invalid, or the number of files detected in a time frame is excessive, the status classification for this module changes to Warning and the module generates a health alert. Note that if you are using a FireAMP Private Cloud and it is unable to communicate with the public Cisco cloud, the private cloud itself generates an alert; for more information, see the FireAMP Private Cloud Administration Portal User Guide.

Note If your Defense Center loses connectivity to the Internet, the system may take up to 30 minutes to generate an Advanced Malware Protection health alert.

To configure Advanced Malware Protection health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Advanced Malware Protection.

The Health Policy Configuration — Advanced Malware Protection page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Appliance Heartbeat Monitoring

License: Any

The Defense Center receives heartbeats from its managed devices once every two minutes or every 200 events, whichever comes first, as an indicator that the device is running and communicating properly with the Defense Center. Use the Appliance Heartbeat health status module to track whether the Defense Center receives heartbeats from managed appliances. If the Defense Center does not detect a heartbeat from a device, the status classification for this module changes to Critical. That status data feeds into the health monitor.

To configure Appliance Heartbeat health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Appliance Heartbeat.

The Health Policy Configuration — Appliance Heartbeat page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Automatic Application Bypass Monitoring

License: Any

Use this module to detect when a managed device is bypassed because it did not respond within the number of seconds configured as the bypass threshold. If a bypass occurs, this module generates an alert. That status data feeds into the health monitor.

For more information on automatic application bypass, see Automatic Application Bypass.

To configure automatic application bypass monitoring status:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Automatic Application Bypass Status.

The Health Policy Configuration — Automatic Application Bypass Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate managed device if you want your settings to take effect. See Applying Health Policies for more information.

Configuring CPU Usage Monitoring

License: Any

Supported Devices: Any except 3D9900

Supported Defense Centers: Any

Excessive CPU usage may indicate that you need to upgrade your hardware or that there are processes that are not functioning correctly. Use the CPU Usage health status module to set CPU usage limits.

If the CPU usage on the monitored appliance exceeds the Warning limit, the status classification for that module changes to Warning. If the CPU usage on the monitored appliance exceeds the Critical limit, the status classification for that module changes to Critical. That status data feeds into the health monitor.

The maximum percentage you can set for either limit is 100 percent, and the Critical limit must be higher than the Warning limit.

To configure CPU usage limits:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select CPU Usage.

The Health Policy Configuration — CPU Usage page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical Threshold % field, enter the percentage of CPU usage that should trigger a critical health status.

Step 4 In the Warning Threshold % field, enter the percentage of CPU usage that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Card Reset Monitoring

License: Any

Use the card reset monitoring health status module to track when the network card restarts because of hardware failure. If a reset occurs, this module generates an alert. That status data feeds into the health monitor.

To configure card reset monitoring:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Card Reset.

The Health Policy Configuration — Card Reset Monitoring page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate Defense Center if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Disk Status Monitoring

License: Any

Use the Disk Status health module to monitor the current status of your appliance’s hard disk, and malware storage pack if installed. This module generates a Warning (yellow) health alert when the hard disk and RAID controller (if installed) are in danger of failing, or if an additional hard drive is installed that is not a malware storage pack. This module generates an Alert (red) health alert when an installed malware storage pack cannot be detected.

To configure Disk Status health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, click Disk Status.

The Health Policy Configuration — Disk Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Disk Usage Monitoring

License: Any

Without sufficient disk space, an appliance cannot run. The health monitor can identify low disk space conditions on your appliance’s hard drive and malware storage pack before space runs out. The health monitor can also alert when hard drive file draining occurs too frequently. Use the Disk Usage health status module to monitor disk usage for the / and /volume partitions on the appliance and track draining frequency.

Note Although the disk usage module lists the /boot partition as a monitored partition, the size of the partition is static so the module does not alert on the boot partition.

If the overall disk usage on the monitored appliance exceeds the Warning limit, the status classification for that module changes to Warning. If the overall disk usage on the monitored appliance exceeds the Critical limit, the status classification for that module changes to Critical. The maximum percentage you can set for either limit is 100 percent, and the Critical limit must be higher than the Warning limit.

If the system deletes unprocessed events, the status classification for that module changes to Warning. If the system drains files in any disk usage category too frequently based on module thresholds, or if disk usage for files not in a monitored disk usage category grows too large based on module thresholds, the status classification for that module changes to Critical. For more information on disk usage categories, see Understanding the Disk Usage Widget.

To configure Disk Usage health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select Disk Usage.

The Health Policy Configuration — Disk Usage page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical Threshold % field, enter the percentage of disk usage that should trigger a critical health status.

Step 4 In the Warning Threshold % field, enter the percentage of disk usage that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring FireAMP Status Monitoring

License: Any

Use the FireAMP Status Monitor module to alert you in the following situations:

- the Defense Center cannot connect to the Cisco cloud after an initial successful connection

- you deregister a cloud connection using the FireAMP portal

- your FireAMP Private Cloud is unable to communicate with the public Cisco cloud

In these cases, the module status changes to Critical and provides the cloud name associated with the failed connection. For information on configuring a cloud connection, see Working with Cloud Connections for FireAMP.

To configure FireAMP Status Monitor module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select FireAMP Status Monitor.

The Health Policy Configuration — FireAMP Status Monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for FireAMP status monitoring.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the Defense Center if you want your settings to take effect. See Applying Health Policies for more information.

Configuring FireSIGHT Host Usage Monitoring

License: FireSIGHT

Use the FireSIGHT Host License Limit health status module to set FireSIGHT Host amount warning limits. If the number of remaining FireSIGHT Hosts on the monitored device falls below the Warning Hosts limit, the status classification for that module changes to Warning. If the number of remaining FireSIGHT Hosts on the monitored device falls below the Critical Hosts limit, the status classification for that module changes to Critical. That status data feeds into the health monitor.

The maximum number of hosts you can set for either limit is 1000, and the Critical host limit number must be lower than the Warning limit.

To configure FireSIGHT Host License Limit health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select FireSIGHT Host License Limit.

The Health Policy Configuration — FireSIGHT Host License Limit page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical number Hosts field, enter the remaining number of available hosts that should trigger a critical health status.

Step 4 In the Warning number Hosts field, enter the remaining number of available hosts that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Hardware Alarm Monitoring

License: Any

Supported Devices: Series 3, 3D9900

Use the Hardware Alarms health status module to detect hardware failure on a Series 3 or 3D9900 device. If the Hardware Alarms module finds a hardware component that has failed or clustered devices that are not communicating with each other, the status classification for that module changes to Critical. That status data feeds into the health monitor.

For more information on the hardware status conditions that can cause hardware alerts on 3D9900 devices, see Interpreting Hardware Alert Details for 3D9900 Devices.

To configure Hardware Alarm health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Hardware Alarms.

The Health Policy Configuration — Hardware Alarm Monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Health Status Monitoring

License: Any

Use the Health Monitor Process module to monitor the health of the health monitor on a Defense Center by generating alerts when too many minutes elapse between health events received from monitored appliances.

For example, if a Defense Center (myrtle.example.com) monitors a device (dogwood.example.com), you apply a health policy with the Health Monitor Process module enabled to myrtle.example.com. The Health Monitor Process module then reports events that indicate how many minutes have elapsed since the last event was received from dogwood.example.com.

You can configure the elapsed duration between events, in minutes, that causes an alert to be generated. If the wait exceeds the number of minutes configured in the Warning Minutes since last event limit, the status classification for that module changes to Warning. If the wait exceeds the Critical Minutes since last event limit, the status classification for that module changes to Critical. That status data feeds into the health monitor.

The maximum number of minutes you can set for either limit is 144, and the Critical limit must be higher than the Warning limit. The minimum number of minutes is 5.

To configure Health Monitor Process module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Health Monitor Process.

The Health Policy Configuration — Health Monitor Process page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical Minutes since last event field, enter the maximum number of minutes to wait between events, before triggering a critical health status.

Step 4 In the Warning Minutes since last event field, enter the maximum number of minutes to wait between events, before triggering a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the Defense Center for your settings to take effect. See Applying Health Policies for more information.

Configuring Inline Link Mismatch Alarm Monitoring

License: Any

Use the Inline Link Mismatch Alarm health status module to track when the interfaces on either side of an inline set negotiate different connection speeds. If different negotiated speeds are detected, this module generates an alert.

To configure inline link mismatch monitoring:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Inline Link Mismatch Alarms.

The Health Policy Configuration — Inline Link Mismatch Alarms page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate Defense Center if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Interface Status Monitoring

License: FireSIGHT

Use the Interface Status health status module to detect whether a device receives traffic. If the Interface Status module determines that a device does not receive traffic, the status classification for that module changes to Critical. That status data feeds into the health monitor.

Note Interfaces labeled DataPlaneInterfacex, where x is a numerical value, are internal ASA interfaces (not user-defined) and involve packet flow within the system.

To configure Interface Status health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Interface Status.

The Health Policy Configuration — Interface Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Intrusion Event Rate Monitoring

License: Protection

Use the Intrusion Event Rate health status module to set limits for the number of packets per second that trigger a change in the health status. If the event rate on the monitored device exceeds the number of events per second configured in the Events per second (Warning) limit, the status classification for that module changes to Warning. If the event rate exceeds the number of events per second configured in the Events per second (Critical) limit, the status classification for that module changes to Critical. That status data feeds into the health monitor.

Typically, the event rate for a network segment averages 20 events per second. For a network segment with this average rate, Events per second (Critical) should be set to 50 and Events per second (Warning) should be set to 30. To determine limits for your system, find the Events/Sec value on the Statistics page for your device (System > Monitoring > Statistics), then calculate the limits using these formulas:

- Events per second (Critical) = Events/Sec * 2.5

- Events per second (Warning) = Events/Sec * 1.5

The maximum number of events you can set for either limit is 999, and the Critical limit must be higher than the Warning limit.

To configure Intrusion Event Rate Monitor health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select Intrusion Event Rate.

The Health Policy Configuration — Intrusion Event Rate page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Events per second (Critical) field, enter the number of events per second that should trigger a critical health status.

Step 4 In the Events per second (Warning) field, enter the number of events per second that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Understanding License Monitoring

License: Any

Use the License Monitoring health status module to determine if sufficient licenses remain for Control, Protection, URL Filtering, Malware, and VPN. This module alerts if the number of remaining licenses is low or insufficient.

This module also alerts if the system detects that devices in a stacked configuration have mismatched license sets (stacked devices must have identical sets of licenses).

The License Monitoring module is automatically configured. Because you cannot change or disable this module, it does not appear on the Health Policy Configuration page.

Configuring Link State Propagation Monitoring

License: Any

Use the Link State Propagation health status module to detect the link state propagation status on an inline pair. If a link state propagates to the pair, the status classification for that module changes to Critical and the state reads:

Module Link State Propagation: ethx_ethy is Triggered

where x and y are the paired interface numbers.

To configure Link State Propagation health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select Link State Propagation.

The Health Policy Configuration — Link State Propagation monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Memory Usage Monitoring

License: Any

Use the Memory Usage health status module to set memory usage limits. The module calculates free memory by considering free memory, cached memory, and swap memory. If the memory usage on the monitored appliance exceeds the Warning limit, the status classification for that module changes to Warning. If the memory usage on the monitored appliance exceeds the Critical limit, the status classification for that module changes to Critical. That status data feeds into the health monitor.

For appliances with more than 4GB of memory, the preset alert thresholds are based on a formula that accounts for proportions of available memory likely to cause system problems.

Note On <4GB appliances, because the interval between Warning and Critical thresholds may be very narrow, Cisco recommends that you manually set the Warning Threshold % value to 50. This will further ensure that you receive memory alerts for your appliance in time to address the issue.

The maximum percentage you can set for either limit is 100 percent, and the Critical limit must be higher than the Warning limit.

Note If you apply an access control policy with many FireSIGHT features enabled (such as security intelligence, file capture, intrusion policies with many rules, or URL filtering), some lower-end ASA FirePOWER devices may generate intermittent memory usage warnings, as the device’s memory allocation is being used to the fullest extent possible.

To configure Memory Usage health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, select Memory Usage.

The Health Policy Configuration — Memory Usage page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical Threshold % field, enter the percentage of memory usage that should trigger a critical health status.

Step 4 In the Warning Threshold % field, enter the percentage of memory usage that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Power Supply Monitoring

License: Any

Supported Devices: 3D3500, 3D4500, 3D6500, 3D9900, Series 3

Supported Defense Centers: DC1500, DC2000, DC3500, DC4000

Use the Power Supply health status module to detect a power supply failure on any of the supported platforms. If the module finds a power supply that has no power, the status classification for that module changes to No Power. If the module cannot detect the presence of the power supply, the status changes to Critical Error. That status data feeds into the health monitor. You can expand the Power Supply item on the Alert Detail list in the health monitor to see specific status items for each power supply.

To configure Power Supply health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Power Supply.

The Health Policy Configuration — Power Supply page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Process Status Monitoring

License: Any

Use the Process Status health module to monitor for processes running on the appliance that exit or terminate outside of the process manager. The response of the Process Status module to a process ending depends on how the process ends:

- If the process terminates inside the process manager, the module does not report any health events.

- If a process is deliberately exited outside of the process manager, the module status changes to Warning and the health event message indicates which process exited until the module runs again and the process has restarted.

- If a process terminates abnormally or crashes outside of the process manager, the module status changes to Critical and the health event message indicates the terminated process until the module runs again and the process has restarted.

To configure Process Status health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Process Status.

The Health Policy Configuration — Process Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate appliances if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Reconfiguring Detection Monitoring

License: Any

Use the Reconfiguring Detection Monitor module to determine the status of detection capabilities after applying a policy to your managed devices. If a policy apply fails and detection ceases functionality, the module generates an alert in Health Events.

To configure time series data monitoring settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Reconfiguring Detection.

The Health Policy Configuration — Reconfiguring Detection page appears.

Step 2 Select On for the Enabled option to enable use of the module for health alerts.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring RRD Server Process Monitoring

License: Any

Use the RRD Server Process module to see if the RRD server that stores time series data is working properly. The module will alert If the RRD server has restarted since the last time it updated; it will enter Critical or Warning status if the number of consecutive updates with an RRD server restart reaches the numbers specified in the module configuration.

To configure RRD server process monitoring settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select RRD Server Process.

The Health Policy Configuration — RRD Server Process page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 In the Critical Number of restarts field, enter the number of consecutive detected RRD server resets that should trigger a critical health status.

Step 4 In the Warning Number of restarts field, enter the number of consecutive detected RRD server resets that should trigger a warning health status.

Step 5 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Security Intelligence Monitoring

License: Protection

Supported Defense Centers: Any except DC500

Use the Security Intelligence module to warn you in a variety of situations involving Security Intelligence filtering. The module alerts if Security Intelligence is in use and:

- the Defense Center cannot update a feed, or if feed data is corrupt or contains no recognizable IP addresses

- a managed device had a problem receiving updated Security Intelligence data from the Defense Center

- a managed device cannot load all of the Security Intelligence data provided to it by the Defense Center, due to memory issues

Tip If a Security Intelligence memory warning appears in the health monitor, you can reapply the affected device’s access control policy to increase the memory allocated to Security Intelligence; see Applying an Access Control Policy.

For more information on Security Intelligence filtering, see Blacklisting Using Security Intelligence IP Address Reputation and Working with Security Intelligence Lists and Feeds.

To configure Security Intelligence module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Security Intelligence.

The Health Policy Configuration — Security Intelligence page appears.

Step 2 Select On for the Enabled option to enable use of the module for Security Intelligence monitoring.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Time Series Data Monitoring

License: Any

Use the Time Series Data Monitor module to monitor the status of time series data (such as lists of compliance events) that your system has stored. This module scans your time series data storage directory for corrupt files. If the module finds corrupted data, it enters a Warning status and reports the names of all affected files.

To configure time series data monitoring settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Time Series Data Monitor.

The Health Policy Configuration — Time Series Data Monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring Time Synchronization Monitoring

License: Any

Use the Time Synchronization Status module to detect when the time on a managed device that uses NTP to obtain time from an NTP server differs by 10 seconds or more from the time on the server.

To configure time synchronization monitoring settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select Time Synchronization Status.

The Health Policy Configuration — Time Synchronization Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Configuring URL Filtering Monitoring

License: URL Filtering

Supported Defense Centers: Any except DC500

Use the URL Filtering Monitor module to track communications between the Defense Center and the Cisco cloud, where the system obtains its URL filtering (category and reputation) data for commonly visited URLs. If the Defense Center fails to successfully communicate with or retrieve an update from the cloud, the status classification for that module changes to Critical.

In a high availability configuration, only the primary Defense Center communicates with the URL filtering cloud; all data from this module refers only to that primary appliance.

The URL Filtering Monitor module also tracks communications between the Defense Center and any managed devices where you have enabled URL filtering. If the Defense Center is successfully communicating with the cloud, the module status changes to Warning if the Defense Center cannot push new URL filtering data to its managed devices.

To configure URL Filtering Monitor health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select URL Filtering Monitor.

The Health Policy Configuration — URL Filtering Monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the Defense Center if you want your settings to take effect. See Applying Health Policies for more information.

Configuring User Agent Status Monitoring

License: FireSIGHT

You can use the User Agent Status Monitor health module to monitor the heartbeat of agents connected to a Defense Center. If you enable the module in an applied health policy, the module generates a health alert if the Defense Center does not detect a heartbeat for any agent configured on the Defense Center.

To configure User Agent Status Monitor health module settings:

Access: Admin/Maint

Step 1 In the Health Policy Configuration page, select User Agent Status Monitor.

The Health Policy Configuration — User Agent Status Monitor page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the Defense Center if you want your settings to take effect. See Applying Health Policies for more information.

Configuring VPN Status Monitoring

License: VPN

Supported Defense Centers: Any except Series 2

Use the VPN Status health module to monitor the current status of your configured Gateway VPN tunnels; information for each individual tunnel is displayed. This module generates a Critical (red) health alert when any of your VPN tunnels is not working.

To configure VPN Status health module settings:

Access: Admin/Maint

Step 1 On the Health Policy Configuration page, click VPN Status.

The Health Policy Configuration — VPN Status page appears.

Step 2 Select On for the Enabled option to enable use of the module for health status testing.

Step 3 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

You must apply the health policy to the appropriate devices if you want your settings to take effect. See Applying Health Policies for more information.

Applying Health Policies

License: Any

When you apply a health policy to an appliance, the health tests for all the modules you enabled in the policy automatically monitor the health of the processes and hardware on the appliance. Health tests then continue to run at the intervals you configured in the policy, collecting health data for the appliance and forwarding that data to the Defense Center.

If you enable a module in a health policy and then apply the policy to an appliance that does not require that health test, the health monitor reports the status for that health module as disabled.

If you apply a policy with all modules disabled to an appliance, it removes all applied health policies from the appliance so no health policy is applied.

When you apply a different policy to an appliance that already has a policy applied, expect some latency in the display of new data based on the newly applied tests.

Note Custom health policies created on Defense Centers in a high availability pair will be replicated between both appliances. However, changes to default health policies are not replicated; each appliance uses the local default health policy configured for that appliance.

To apply a health policy:

Access: Admin/Maint

Step 1 Select Health > Health Policy.

The Health Policy page appears.

) next to the policy you want to apply.

The Health Policy Apply page appears.

Step 3 Select the appliances where you want to apply the health policy.

Step 4 Click Apply to apply the policy to the selected appliances.

The Health Policy page appears, with a message indicating if the application of the policy was successful. Monitoring of the appliance starts as soon as the policy is successfully applied.

Editing Health Policies

License: Any

You can modify a health policy by enabling or disabling modules or by changing module settings. If you modify a policy that is already applied to an appliance, the changes do not take effect until you reapply the policy.

Module

Applicable Appliance

Advanced Malware Protection

Defense Centers, except DC500

Appliance Heartbeat

Defense Center

Automatic Application Bypass Status

Any managed device

CPU Usage

Any except 3D9900

Card Reset

Any managed device

Disk Status

Any

Disk Usage

Any

FireAMP Status Monitor

Defense Center

FireSIGHT Host License Limit

Defense Center

Hardware Alarms

Series 3, 3D9900

Health Monitor Process

Defense Center

Inline Link Mismatch Alarms

Any managed device

Interface Status

Any managed device

Intrusion Event Rate

Managed devices with Protection

License Monitor

Defense Center

Link State Propagation

Managed devices with Protection

Memory Usage

Any

Power Supply

Defense Centers: DC1500, DC2000, DC3500, DC4000

Devices: 3D3500, 3D4500, 3D6500, 3D9900, Series 3

Process Status

Any

Reconfiguring Detection

Any

RRD Server Process

Defense Center

Security Intelligence

Defense Center, except DC500

Time Series Data Monitor

Defense Center

Time Synchronization Status

Any

URL Filtering Monitor

Defense Centers, except DC500

User Agent Status Monitor

Defense Center

VPN Status

Defense Center

To edit a health policy:

Access: Admin/Maint

Step 1 Select Health > Health Policy.

The Health Policy page appears.

) next to the policy you want to modify.

The Health Policy Configuration page appears, with the Policy Run Time Interval settings selected.

Step 3 Modify settings as needed, as described in the following sections:

- Configuring Policy Run Time Intervals

- Configuring Advanced Malware Protection Monitoring

- Configuring Appliance Heartbeat Monitoring

- Configuring Automatic Application Bypass Monitoring

- Configuring CPU Usage Monitoring

- Configuring Card Reset Monitoring

- Configuring Disk Status Monitoring

- Configuring Disk Usage Monitoring

- Configuring FireAMP Status Monitoring

- Configuring FireSIGHT Host Usage Monitoring

- Configuring Hardware Alarm Monitoring

- Configuring Health Status Monitoring

- Configuring Inline Link Mismatch Alarm Monitoring

- Configuring Interface Status Monitoring

- Configuring Intrusion Event Rate Monitoring

- Understanding License Monitoring

- Configuring Link State Propagation Monitoring

- Configuring Memory Usage Monitoring

- Configuring Power Supply Monitoring

- Configuring Process Status Monitoring

- Configuring Reconfiguring Detection Monitoring

- Configuring RRD Server Process Monitoring

- Configuring Security Intelligence Monitoring

- Configuring Time Series Data Monitoring

- Configuring Time Synchronization Monitoring

- Configuring URL Filtering Monitoring

- Configuring User Agent Status Monitoring

- Configuring VPN Status Monitoring

Step 4 You have three options:

- To save your changes to this module and return to the Health Policy page, click Save Policy and Exit .

- To return to the Health Policy page without saving any of your settings for this module, click Cancel .

- To temporarily save your changes to this module and switch to another module’s settings to modify, select the other module from the list at the left of the page. If you click Save Policy and Exit when you are done, all changes you made will be saved; if you click Cancel , you discard all changes.

Step 5 Reapply the policy to the appropriate appliances as described in Applying Health Policies.

Comparing Health Policies

License: Any

To review policy changes for compliance with your organization’s standards or to optimize health monitoring performance, you can examine the differences between two health policies. You can compare any two health policies or two revisions of the same health policy, for the health policies you can access. To quickly compare your active health policy to another, you can select the Running Configuration option. Optionally, after you compare, you can then generate a PDF report to record the differences between the two policies or policy revisions.

There are two tools you can use to compare health policies or health policy revisions:

- The comparison view displays only the differences between two health policies or health policy revisions in a side-by-side format; the name of each policy or policy revision appears in the title bar on the left and right sides of the comparison view.

You can use this to view and navigate both policy revisions on the web interface, with their differences highlighted.

- The comparison report creates a record of only the differences between two health policies or health policy revisions in a format similar to the health policy report, but in PDF format.

You can use this to save, copy, print and share your policy comparisons for further examination.

For more information on understanding and using the health policy comparison tools, see:

- Using the Health Policy Comparison View

- Using the Health Policy Comparison Report

Using the Health Policy Comparison View

License: Any

The comparison view displays both health policies or policy revisions in a side-by-side format, with each policy or policy revision identified by name in the title bar on the left and right sides of the comparison view. The time of last modification and the last user to modify are displayed to the right of the policy name. Note that the Health Policy page displays the time a policy was last modified in local time, but the health policy report lists the time modified in UTC.

Differences between the two health policies or policy revisions are highlighted:

- Blue indicates that the highlighted setting is different in the two policies or policy revisions, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one policy or policy revision but not the other.

You can perform any of the actions in the following table.

Table 68-4 Health Policy Comparison View Actions

To...

You can...

navigate individually through changes

click Previous or Next above the title bar.
number adjusts to identify which difference you are viewing.

generate a new health policy comparison view

click New Comparison.

The Select Comparison window appears. See Using the Health Policy Comparison Report for more information.

generate a health policy comparison report

click Comparison Report.

The health policy comparison report creates a PDF containing information identical to the comparison view.

Using the Health Policy Comparison Report

License: Any

A health policy comparison report is a record of all differences between two health policies or two revisions of the same health policy identified by the health policy comparison view, presented as a PDF. You can use this report to further examine the differences between two health policy configurations and to save and disseminate your findings.

You can generate a health policy comparison report from the comparison view for any health policies to which you have access. Remember to commit any potential changes before you generate a health policy report; only committed changes appear in the report.

Depending on your configuration, a health policy comparison report can contain one or more sections. Each section uses the same format and provides the same level of detail. Note that the Value A and Value B columns represent the policies or policy revisions you configured in the comparison view.

Tip You can use a similar procedure to compare SSL, network analysis, intrusion, file, system, or access control policies.

To compare two health policies or two revisions of the same policy:

Access: Admin/Maint

Step 1 Select Health > Health Policy.

The Health Policy page appears.

Step 2 Click Compare Policies.

The Select Comparison window appears.

Step 3 From the Compare Against drop-down list, select the type of comparison you want to make:

- To compare two different policies, select Other Policy .

- To compare two revisions of the same policy, select Other Revision .

- To compare another policy to the currently active policy, select Running Configuration.

Remember to commit any changes before you generate a health policy report; only committed changes appear in the report.

Step 4 Depending on the comparison type you selected, you have the following choices:

- If you are comparing two different policies, select the policies you want to compare from the Policy A and Policy B drop-down lists.

- If you are comparing two revisions of the same policy, select the policy from the Policy drop-down list, then select the revisions you want to compare from the Revision A and Revision B drop-down lists.

- If you are comparing the running configuration to another policy, select the second policy from the Policy B drop-down list.

Step 5 Click OK to display the health policy comparison view.

The comparison view appears.

Step 6 Click Comparison Report to generate the health policy comparison report.

The health policy report appears. Depending on your browser settings, the report may appear in a pop-up window, or you may be prompted to save the report to your computer.

Deleting Health Policies

License: Any

You can delete health policies that you no longer need. If you delete a policy that is still applied to an appliance, the policy settings remain in effect until you apply a different policy. In addition, if you delete a health policy that is applied to a device, any health monitoring alerts in effect for the device remain active until you disable the underlying associated alert response; see Enabling and Disabling Alert Responses.

Tip To stop health monitoring for an appliance, create a health policy with all modules disabled and apply it to the appliance. For more information on creating health policies, see Creating Health Policies. For more information on applying health policies, see Applying Health Policies.

To delete a health policy:

Access: Admin/Maint

Step 1 Select Health > Health Policy.

The Health Policy page appears.

) next to the policy you want to delete.

A message appears, indicating if the deletion was successful.

Using the Health Monitor Blacklist

License: Any

In the course of normal network maintenance, you disable appliances or make them temporarily unavailable. Because those outages are deliberate, you do not want the health status from those appliances to affect the summary health status on your Defense Center.

You can use the health monitor blacklist feature to disable health monitoring status reporting on an appliance or module. For example, if you know that a segment of your network will be unavailable, you can temporarily disable health monitoring for a managed device on that segment to prevent the health status on the Defense Center from displaying a warning or critical state because of the lapsed connection to the device.

When you disable health monitoring status, health events are still generated, but they have a disabled status and do not affect the health status for the health monitor. If you remove the appliance or module from the blacklist, the events that were generated during the blacklisting continue to show a status of disabled.

To temporarily disable health events from an appliance, go to the blacklist configuration page and add an appliance to the blacklist. After the setting takes effect, the system no longer includes the blacklisted appliance when calculating the overall health status. The Health Monitor Appliance Status Summary lists the appliance as disabled.

At times it may be more practical to just blacklist an individual health monitoring module on an appliance. For example, when you run out of FireSIGHT host licenses on an appliance, you can blacklist the FireSIGHT Host License Limit status messages.

Note that on the main Health Monitor page you can distinguish between appliances that are blacklisted if you expand to view the list of appliances with a particular status by clicking the arrow in that status row. For more information on expanding that view, see Using the Health Monitor.

) and a notation are visible after you expand the view for a blacklisted or partially blacklisted appliance.

Note On a Defense Center, Health Monitor blacklist settings are local configuration settings. Therefore, if you blacklist a device, then delete it and later re-register it with the Defense Center, the blacklist settings remain persistent. The newly re-registered device remains blacklisted.

For more information, see:

- Blacklisting Health Policies or Appliances

- Blacklisting an Appliance

- Blacklisting a Health Policy Module

Blacklisting Health Policies or Appliances

License: Any

If you want to set health events to disabled for all appliances with a particular health policy, you can blacklist the policy. If you need to disable the results of a group of appliances’ health monitoring, you can blacklist the group of appliances. After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor Appliance Module Summary and Device Management page. Health events for the appliance have a status of disabled.

Note that if your Defense Center is in a high availability configuration, you can blacklist a managed device on one high availability peer and not the other. You can also blacklist the high availability peer to cause it to mark events generated by it and the devices from which it receives health events as disabled. Defense Centers in a high availability pair have the option to completely or partially blacklist their peer.

To blacklist an entire health policy or group of appliances:

Access: Admin/Maint

Step 1 Select Health > Blacklist.

The Blacklist page appears.

Step 2 Use the drop-down list on the right to sort the list by group, policy, or model. (Groups on a Defense Center are managed devices.)

Note that appliances with some, but not all, health modules blacklisted will appear as (Partially Blacklisted). If you edit their blacklist status on the main blacklist page, you can either blacklist all modules on those appliances or remove all blacklisting. For information on blacklisting individual health modules on an appliance, see Blacklisting a Health Policy Module.

Step 3 You have two options:

- To blacklist all appliances in a group, model, or policy category, select the category, then click Blacklist Selected Devices .

- To clear blacklisting from all appliances in a group, model, or policy category, select the category, then click Clear Blacklist on Selected Devices .

The page refreshes, now indicating the new blacklist state of the appliances.

Blacklisting an Appliance

License: Any

If you need to set the events and health status for an individual appliance to disabled, you can blacklist the appliance. After the blacklist settings take effect, the appliance shows as disabled in the Health Monitor Appliance Module Summary and health events for the appliance have a status of disabled.

To blacklist an individual appliance:

Access: Admin/Maint

Step 1 Select Health > Blacklist.

The Blacklist page appears.

Step 2 Use the drop-down list on the right to sort the list by appliance group, model, or by policy.

Step 3 You have two options:

- To blacklist all appliances in a group, model, or policy category, select the category, then click Blacklist Selected Devices .

- To clear blacklisting from all appliances in a group, model, or policy category, select the category, then click Clear Blacklist on Selected Devices .

The page refreshes and indicates the new blacklist state of the appliances. Click Edit and see Blacklisting a Health Policy Module to blacklist individual health policy modules.

Blacklisting a Health Policy Module

License: Any

You can blacklist individual health policy modules on appliances. You may want to do this to prevent events from the module from changing the status for the appliance to warning or critical.

When any part of a module is blacklisted, the line for that module appears in boldface type in the Defense Center web interface.

Tip After the blacklist settings take effect, the appliance shows as Partially Blacklisted or All Modules Blacklisted on the Blacklist page and in the Appliance Health Monitor Module Status Summary, but only in expanded views on the main Appliance Status Summary page. Make sure that you keep track of individually blacklisted modules so you can reactivate them when you need them. You may miss necessary warning or critical messages if you accidentally leave a module disabled.

To blacklist an individual health policy module:

Access: Admin/Maint

Step 1 Select Health > Blacklist.

The Blacklist page appears.

Step 2 Sort by Group, Policy, or Model, then click Edit to display the list of health policy modules for an appliance.

The health policy modules appear.

Step 3 Select each module that you want to blacklist.

Step 4 Click Save.

Configuring Health Monitor Alerts

License: Any

You can set up alerts to notify you through email, through SNMP, or through the system log when the status changes for the modules in a health policy. You can associate an existing alert response with health event levels to trigger and alert when health events of a particular level occur.

For example, if you are concerned that your appliances may run out of hard disk space, you can automatically send an email to a system administrator when the remaining disk space reaches the warning level. If the hard drive continues to fill, you can send a second email when the hard drive reaches the critical level.

For more information, see the following topics:

- Creating Health Monitor Alerts

- Interpreting Health Monitor Alerts

- Editing Health Monitor Alerts

- Deleting Health Monitor Alerts

Creating Health Monitor Alerts

License: Any

When you create a health monitor alert, you create an association between a severity level, a health module, and an alert response. You can use an existing alert or configure a new one specifically to report on system health. When the severity level occurs for the selected module, the alert triggers.

Note that if you create or update a threshold in a way that duplicates an existing threshold, you are notified of the conflict. When duplicate thresholds exist, the health monitor uses the threshold that generates the fewest alerts and ignores the others. The timeout value for the threshold must be between 5 and 4,294,967,295 minutes.

To create health monitor alerts:

Access: Admin

Step 1 Select Health > Health Monitor Alerts.

The Health Monitor Alerts page appears.

Step 2 Type a name for the health alert in the Health Alert Name field.

Step 3 From the Severity list, select the severity level you want to use to trigger the alert.

Step 4 From the Module list, select the modules for which you want the alert to apply.

Tip To select multiple modules, press Shift + Ctrl and click the module names.

Step 5 From the Alert list, select the alert response that you want to trigger when the selected severity level is reached.

Tip Click Alerts to open the Alerts page. For more information on creating alerts, see Working with Alert Responses.

Step 6 Optionally, in the Threshold Timeout field, type the number of minutes that should elapse before each threshold period ends and the threshold count resets. The default value is 5 minutes.

Note that even if the policy run time interval value is less than the threshold timeout value, the interval between two reported health events from a given module is always greater, such that if the threshold timeout is 8 minutes and the policy run time interval is 5 minutes, there will be a 10-minute interval (5 x 2) between reported events.

Step 7 Click Save to save the health alert.

A message appears, indicating if the alert configuration was successfully saved. The Active Health Alerts list now includes the alert you created.

Interpreting Health Monitor Alerts

License: Any

The alerts generated by the health monitor contain the following information:

- Severity, which indicates the severity level of the alert.

- Module, which specifies the health module whose test results triggered the alert.

- Description, which includes the health test results that triggered the alert.

Severity

Description

Critical

The health test results met the criteria to trigger a Critical alert status.

Warning

The health test results met the criteria to trigger a Warning alert status.

Normal

The health test results met the criteria to trigger a Normal alert status.

Error

The health test did not run.

Recovered

The health test results met the criteria to return to a normal alert status, following a Critical or Warning alert status.

For more information on health modules, see Understanding Health Modules.

Editing Health Monitor Alerts

License: Any

You can edit existing health monitor alerts to change the severity level, health module, or alert response associated with the health monitor alert.

To edit health monitor alerts:

Access: Admin

Step 1 Select Health > Health Monitor Alerts.

The Health Monitor Alerts page appears.

Step 2 Select the alert you want to modify in the Active Health Alerts list.

Step 3 Click Load to load the configured settings for the selected alert.

Step 4 Modify settings as needed. For more information, see Creating Health Monitor Alerts.

Step 5 Click Save to save the modified health alert.

A message appears, indicating if the alert configuration was successfully saved.

Deleting Health Monitor Alerts

License: Any

You can delete existing health monitor alerts.

Note Deleting a health monitor alert does not delete the associated alert response. You must disable or delete the underlying alert response to ensure that alerting does not continue. For more information, see Enabling and Disabling Alert Responses and Deleting an Alert Response.

To delete health monitor alerts:

Access: Admin

Step 1 Select Health > Health Monitor Alerts.

The Health Monitor Alerts page appears.

Step 2 Select the alert you want to delete in the Active Health Alerts list.

Step 3 Click Delete.

A message appears, indicating if the alert configuration was successfully deleted.

Using the Health Monitor

License: Any

The Health Monitor page provides the compiled health status for all devices managed by the Defense Center, plus the Defense Center. The Status table provides a count of the managed appliances for this Defense Center by overall health status. The pie chart supplies another view of the health status breakdown, indicating the percentage of appliances currently in each health status category.

To use the health monitor:

Access: Admin/Maint/Any Security Analyst

Step 1 Click Health > Health Monitor.

The Health Monitor page appears.

Step 2 Select the appropriate status in the Status column of the table or the appropriate portion of the pie chart to the list appliances with that status.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

The following topics provide details on the tasks you can perform from the Health Monitor page:

- Interpreting Health Monitor Status

- Using Appliance Health Monitors

- Configuring Health Policies

- Configuring Health Monitor Alerts

Interpreting Health Monitor Status

License: Any

Available status categories, by severity, include Error, Critical, Warning, Normal, Recovered, and Disabled, as described in the following table.

Table 68-6 Health Status Indicator

Status Level

Status Icon

Status Color

Description

Error

White

Indicates that at least one health monitoring module has failed on the appliance and has not been successfully re-run since the failure occurred. Contact your technical support representative to obtain an update to the health monitoring module.

Critical

Red

Indicates that the critical limits have been exceeded for at least one health module on the appliance and the problem has not been corrected.

Warning

Yellow

Indicates that warning limits have been exceeded for at least one health module on the appliance and the problem has not been corrected.

Normal

Green

Indicates that all health modules on the appliance are running within the limits configured in the health policy applied to the appliance.

Recovered

Green

Indicates that all health modules on the appliance are running within the limits configured in the health policy applied to the appliance, including modules that were in a Critical or Warning state.

Disabled

Blue

Indicates that an appliance is disabled or blacklisted, that the appliance does not have a health policy applied to it, or that the appliance is currently unreachable.

Using Appliance Health Monitors

License: Any

The Appliance health monitor provides a detailed view of the health status of an appliance.

Note Your session normally logs you out after 1 hour of inactivity (or another configured interval). If you plan to passively monitor the health monitor for long periods of time, consider exempting some users from session timeout, or changing the system timeout settings. For more information, see Managing User Login Settings and Configuring User Interface Settings.

To view the status summary for a specific appliance:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To show the list of appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details in the health monitor toolbar.

The Health Monitor Appliance page appears.

Step 4 Optionally, in the Module Status Summary graph, click the color for the event status category you want to view. The Alert Detail list toggles the display to show or hide events.

For more information, see the following sections:

- Understanding Health Modules

- Interpreting Health Monitor Status

- Viewing Alerts by Status

- Running All Modules for an Appliance

- Running a Specific Health Module

- Generating Health Module Alert Graphs

- Using the Health Monitor to Troubleshoot

Viewing Alerts by Status

License: Any

You can show or hide categories of alerts by status.

To show alerts by status:

Access: Admin/Maint/Any Security Analyst

Step 1 Click the status icon or the color segment in the pie chart that corresponds to the health status of the alerts you want to view. The alerts for that category appear in the Alert Detail list.

To hide alerts by status:

Access: Admin/Maint/Any Security Analyst

Step 1 Click the status icon or the color segment in the pie chart that corresponds to the health status of the alerts you want to view. The alerts in the Alert Detail list for that category disappear.

Running All Modules for an Appliance

License: Any

Health module tests run automatically at the policy run time interval you configure when you create a health policy. However, you can also run all health module tests on demand to collect up-to-date health information for the appliance.

To run all health modules for the appliance:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To expand the appliance list to show appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.

The Health Monitor Appliance page appears.

Step 4 Click Run All Modules.

The status bar indicates the progress of the tests, then the Health Monitor Appliance page refreshes.

Note When you manually run health modules, the first refresh that automatically occurs may not reflect the data from the manually run tests. If the value has not changed for a module that you just ran manually, wait a few seconds, then refresh the page by clicking the device name. You can also wait for the page to refresh again automatically.

Running a Specific Health Module

License: Any

Health module tests run automatically at the policy run time interval you configure when you create a health policy. However, you can also run a health module test on demand to collect up-to-date health information for that module.

To run a specific health module:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To expand the appliance list to show appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.

The Health Monitor Appliance page appears.

Step 4 In the Module Status Summary graph of the Health Monitor Appliance page, click the color for the health alert status category you want to view.

The Alert Detail list expands to list the health alerts for the selected appliance for that status category.

Step 5 In the Alert Detail row for the alert for which you want to view a list of events, click Run.

The status bar indicates the progress of the test, then the Health Monitor Appliance page refreshes.

Note When you manually run health modules, the first refresh that automatically occurs may not reflect the data from the manually run tests. If the value has not changed for a module that you just manually ran, wait a few seconds, then refresh the page by clicking the device name. You can also wait for the page to refresh automatically again.

Generating Health Module Alert Graphs

License: Any

You can graph the results over a period of time of a particular health test for a specific appliance.

To generate a health module alert graph:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To expand the appliance list to show appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.

The Health Monitor Appliance page appears.

Step 4 In the Module Status Summary graph of the Health Monitor Appliance page, click the color for the health alert status category you want to view.

The Alert Detail list expands to list the health alerts for the selected appliance for that status category.

Step 5 In the Alert Detail row for the alert for which you want to view a list of events, click Graph.

A graph appears, showing the status of the event over time. The Alert Detail section below the graph lists all health alerts for the selected appliance.

Tip If no events appear, you may need to adjust the time range. See Setting Event Time Constraints for more information.

Using the Health Monitor to Troubleshoot

License: Any

In some cases, if you have a problem with your appliance, Support may ask you to generate troubleshooting files to help them diagnose the problem. You can select any of the options listed in the following table to customize the troubleshooting data that the health monitor reports.

Table 68-7 Selectable Troubleshoot Options

This option...

Reports...

Snort Performance and Configuration

data and configuration settings related to Snort on the appliance

Hardware Performance and Logs

data and logs related to the performance of the appliance hardware

System Configuration, Policy, and Logs

configuration settings, data, and logs related to the current system configuration of the appliance

Detection Configuration, Policy, and Logs

configuration settings, data, and logs related to detection on the appliance

Interface and Network Related Data

configuration settings, data, and logs related to inline sets and network configuration of the appliance

Discovery, Awareness, VDB Data, and Logs

configuration settings, data, and logs related to the current discovery and awareness configuration on the appliance

Upgrade Data and Logs

data and logs related to prior upgrades of the appliance

All Database Data

all database-related data that is included in a troubleshoot report

All Log Data

all logs collected by the appliance database

Network Map Information

current network topology data

Note that some options overlap in terms of the data they report, but the troubleshooting files will not contain redundant copies, regardless of what options you select.

For more information, see the following sections:

- Generating Appliance Troubleshooting Files

- Downloading Troubleshooting Files

Generating Appliance Troubleshooting Files

License: Any

Use the following procedure to generate customized troubleshooting files that you can send to Support.

Note You cannot use the primary Defense Center in a high availability configuration to generate troubleshooting files for the secondary Defense Center, or visa versa. You must generate troubleshooting files for a Defense Center from its own web interface.

To generate troubleshooting files:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To expand the appliance list to show appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.

The Health Monitor Appliance page appears.

Step 4 Click Generate Troubleshooting Files.

The Troubleshooting Options pop-up window appears.

Step 5 Select All Data to generate all possible troubleshooting data, or select individual check boxes to customize your report. For more information, see the Selectable Troubleshoot Options table.

Step 6 Click OK.

The Defense Center generates the troubleshooting files. You can monitor the file generation process in the task queue (System > Monitoring > Task Status).

Step 7 Continue with the procedure in the next section, Downloading Troubleshooting Files.

Downloading Troubleshooting Files

License: Any

Use the following procedure to download copies of your generated troubleshooting files.

To download troubleshooting files:

Access: Admin/Maint/Any Security Analyst

Step 1 Select System > Monitoring > Task Status.

The Task Status page appears.

Step 2 Find the task that corresponds to the troubleshooting files you generated.

Step 3 After the appliance generates the troubleshooting files and the task status changes to Completed, click Click to retrieve generated files.

Step 4 Follow your browser’s prompts to download the files.

The files are downloaded in a single .tar.gz file.

Step 5 Follow the directions from Support to send the troubleshooting files to Cisco.

Working with Health Events

License: Any

The Defense Center provides fully customizable event views that allow you to quickly and easily analyze the health status events gathered by the health monitor. These event views allow you to search and view event data and to easily access other information that may be related to the events you are investigating.

Many functions that you can perform on the health event view pages are constant across all event view pages. See Understanding Health Event Views for more information about these common procedures.

From the Health > Health Events menu option, you can view health events and can search for specific events.

See the following sections for more information about viewing events:

- Understanding Health Event Views describes the types of events that FireSIGHT generates.

- Viewing Health Events describes how to access and use the Event View page.

- Searching for Health Events describes how to search for specific events using the Event Search page.

Understanding Health Event Views

License: Any

The Defense Center health monitor logs health events, which you can see on the Health Event View page. If you understand what conditions each health module tests for, you can more effectively configure alerting for health events. For more information on the different types of health modules that generate health events, see Understanding Health Modules.

For more information about viewing and searching for health events, see the following sections:

- Viewing Health Events

- Understanding the Health Events Table

- Searching for Health Events

Viewing Health Events

License: Any

You can view the appliance health data collected by your health monitor in several ways.

For more information, see the following topics:

- Viewing All Health Events

- Viewing Health Events by Module and Appliance

- Working with the Health Events Table View

- Interpreting Hardware Alert Details for 3D9900 Devices

- Interpreting Hardware Alert Details for Series 3 Devices

Viewing All Health Events

License: Any

The Table View of Health Events page provides a list of all health events on the selected appliance. For a description of the health modules that generated the events that you may see on this page, see Understanding Health Modules.

When you access health events from the Health Monitor page on your Defense Center, you retrieve all health events for all managed appliances.

To view all health events on all managed appliances:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Events.

The Events page appears, containing all health events.

Note If no events appear, you may need to adjust the time range. See Setting Event Time Constraints for more information.

Tip You can bookmark this view to allow you to return to the page in the health events workflow containing the Health Events table of events. The bookmarked view retrieves events within the time range you are currently viewing, but you can then modify the time range to update the table with more recent information if needed. For more information, see Setting Event Time Constraints.

Viewing Health Events by Module and Appliance

License: Any

You can query for events generated by a specific health module on a specific appliance.

To view the health events for a specific module:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Monitor.

The Health Monitor page appears.

Step 2 To expand the appliance list to show appliances with a particular status, click the arrow in that status row.

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view details.

The Health Monitor Appliance page appears.

Step 4 In the Module Status Summary graph of the Health Monitor Appliance page, click the color for the health alert status category you want to view.

The Alert Detail list expands to list the health alerts for the selected appliance for that status category.

Step 5 In the Alert Detail row for the alert for which you want to view a list of events, click Events.

The Health Events page appears, containing query results for a query with the name of the appliance and the name of the selected health alert module as constraints.

If no events appear, you may need to adjust the time range. See Setting Event Time Constraints for more information.

Step 6 If you want to view all health events for the selected appliance, expand Search Constraints and click the Module Name constraint to remove it.

Working with the Health Events Table View

License: Any

The following table describes each action you can perform from the Event View page.

Table 68-8 Health Event View Functions

To...

You can...

learn more about the contents of the columns that appear in the Health event view

find more information in Understanding the Health Events Table.

modify the time and date range for events listed in the Health table view

find more information in Setting Event Time Constraints.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

sort the events that appear, change what columns display in the table of events, or constrain the events that appear

find more information in Sorting Drill-Down Workflow Pages.

delete health events

select the check box next to the events you want to delete and click Delete. To delete all the events in the current constrained view, click Delete All, then confirm you want to delete all the events.

navigate through event view pages

find more information in Navigating to Other Pages in the Workflow.

navigate to other event tables to view associated events

find more information in Navigating Between Workflows.

bookmark the current page so that you can quickly return to it

click Bookmark This Page, provide a name for the bookmark and click Save. See Using Bookmarks for more information.

navigate to the bookmark management page

click View Bookmarks from any event view. See Using Bookmarks for more information.

generate a report based on data in the table view

click Report Designer. See Creating a Report Template from an Event View for more information.

select another health events workflow

click (switch workflow). See Selecting Workflows for more information.

view the details associated with a single health event

click the down arrow link on the left side of the event.

view event details for multiple health events

select the check box next to the rows that correspond with the events you want to view details for and then click View.

view event details for all events in the view

click View All.

view all events of a particular status

click the status icon in the Status column for an event with that status.

Interpreting Hardware Alert Details for 3D9900 Devices

License: Any

For 3D9900 device models, hardware alarms generate in response to the events described in the following table. The triggering condition can be found in the message detail for the alert.

Table 68-9 Conditions Monitored for 3D9900 Devices

Condition Monitored

Causes of Yellow or Red Error Conditions

NFE card presence

If NFE hardware is detected that is not valid for the appliance, health status for the Hardware Alarms module changes to red and the message details include a reference to the NFE card presence.

NFE temperature

If NFE temperature exceeds 95 degrees Celsius, health status for the Hardware Alarms module changes to yellow and the message details include a reference to the NFE temperature.

If NFE temperature exceeds 99 degrees Celsius, health status for the Hardware Alarms module changes to red and the message details include a reference to the NFE temperature.

NFE Platform daemon

If the NFE Platform daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

NFE Message daemon

If the NFE Message daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

NFE TCAM daemon

If the NFE TCAM daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

LBIM presence

If the Load Balancing Interface Module (LBIM) switch assembly is not present or not communicating, health status for the Hardware Alarms module changes to red and the message details include a reference to the LBIM presence.

Scmd daemon

If the Scmd daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

Psls daemon

If the Psls daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

Ftwo daemon

If the Ftwo daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

Rulesd (host rules) daemon

If the Rulesd daemon goes down, health status for the Hardware Alarms module changes to yellow and the message details include a reference to the daemon.

nfm_ipfragd (host frag) daemon

If the nfm_ipfragd daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon.

Interpreting Hardware Alert Details for Series 3 Devices

Condition Monitored

Causes of Yellow or Red Error Conditions

Cluster status

If clustered devices are no longer communicating with each other (due, for example, to a cabling problem), the Hardware Alarms module changes to red.

ftwo daemon status

If the ftwo daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon.

NFE cards detected

Indicates the number of NFE cards detected on the system. If this value does not match the appliance’s expected NFE count, the Hardware Alarms module changes to red.

NFE hardware status

If one or more NFE cards are not communicating, the Hardware Alarms module changes to red and the applicable card appears in the message details.

NFE heartbeat

If the system detects no NFE heartbeat, the Hardware Alarms module changes to red and message details include a reference to the relevant card(s).

NFE internal link status

If the link between the NMSB and NFE card(s) goes down, the Hardware Alarms module changes to red and message details include a reference to the relevant ports.

NFE Message daemon

If the NFE Message daemon goes down, health status for the Hardware Alarms module changes to red and the message details include a reference to the daemon (and, if applicable, the NFE card number).

NFE temperature

If NFE temperature exceeds 97 degrees Celsius, health status for the Hardware Alarms module changes to yellow and message details include a reference to the NFE temperature (and, if applicable, the NFE card number).

If NFE temperature exceeds 102 degrees Celsius, health status for the Hardware Alarms module changes to red and message details include a reference to the NFE temperature. (and, if applicable, the NFE card number).

NFE temperature status

Indicates the current temperature status of the given NFE card. The Hardware Alarms module indicates green for OK, yellow for Warning, and red for Critical (and, if applicable, the NFE card number).

NFE TCAM daemon

If the NFE TCAM daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon (and, if applicable, the NFE card number).

nfm_ipfragd (host frag) daemon

If the nfm_ipfragd daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon (and, if applicable, the NFE card number).

NFE Platform daemon

If the NFE Platform daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon (and, if applicable, the NFE card number).

NMSB communications

If the Media assembly is not present or not communicating, health status for the Hardware Alarms module changes to red and message details include a reference to the NFE temperature (and, if applicable, the NFE card number).

psls daemon status

If the psls daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon.

Rulesd (host rules) daemon

If the Rulesd daemon goes down, health status for the Hardware Alarms module changes to yellow and message details include a reference to the daemon (and, if applicable, the NFE card number).

scmd daemon status

If the scmd daemon goes down, health status for the Hardware Alarms module changes to red and message details include a reference to the daemon.

Understanding the Health Events Table

License: Any

You can use the Defense Center’s health monitor to determine the status of critical functionality within the FireSIGHT System. You create and apply health policies to your appliances, which monitor a variety of aspects, including hardware and software status. The Health Monitor modules you choose to enable in your health policy run various tests to determine appliance health status. When the health status meets criteria that you specify, a health event is generated. For more information on health monitoring, see Monitoring the System.

The fields in the health events table are described in the following table.

Table 68-11 Health Event Fields

Field

Description

Test Name

The name of the health module that generated the event. For a list of health modules, see the Health Modules table.

Time

The timestamp for the health event.

Description

The description of the health module that generated the event. For example, health events generated when a process was unable to execute are labeled Unable to Execute.

Value

The value (number of units) of the result obtained by the health test that generated the event.

For example, if the Defense Center generates a health event whenever a device it is monitoring is using 80 percent or more of its CPU resources, the value could be a number from 80 to 100.

Units

The units descriptor for the result. You can use the asterisk (*) to create wildcard searches.

For example, if the Defense Center generates a health event when a device it is monitoring is using 80 percent or more of its CPU resources, the units descriptor is a percentage sign (%).

Status

The status (Critical, Yellow, Green, or Disabled) reported for the appliance.

Device

The appliance where the health event was reported.

To display the table view of health events:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Health > Health Events.

The table view appears. For information on working with health events, see Working with Health Events.

Tip If you are using a custom workflow that does not include the table view of health events, click (switch workflow). On the Select Workflow page, click Health Events.

Searching for Health Events

License: Any

You can search for specific health events. You may want to create searches customized for your network environment, then save them to reuse later. The following table describes the search criteria you can use.

Table 68-12 Health Event Search Criteria

Search Field

Description

Module Name

Specify the name of the module which generated the health events you want to view. For example, to view events that measure CPU performance, type CPU. The search should retrieve applicable CPU Usage and CPU temperature events.

Value

Specify the value (number of units) of the result obtained by the health test for the events you want to view.

For example, if you specify a value of 15 and type CPU in the Units field, you retrieve events where the appliance CPU was running at 15% utilization at the time the test ran.

Description

Specify the description of the events you want to view. For example, you could enter Unable to Execute to view any health events where a process was unable to execute. You can use an asterisk (*) in this field to create wildcard searches.

Units

Specify the units descriptor for the result obtained by the health test for the events you want to view. You can use an asterisk (*) in this field to create wildcard searches.

For example, if you type % in the Units field, you retrieve all events for the Disk Usage modules, because the Disk Usage module has a “%” label in the Units field (and no additional text). However, if you type *% in the Units field, you retrieve all events for any modules that contain text followed by a “%” sign in the Units field.

Status

Specify the status for the health events that you want to view. Valid status levels are Critical, Warning, Normal, Error, and Disabled.

For example, type Critical to retrieve all health events that indicate a critical status.

Device

Type the device name or IP address, or a device group, stack, or cluster name to restrict the search to health events generated by one or more specific devices. For detailed information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.

For more information on searching, including information on special search syntax as well as saving and loading searches, see Performing and Saving Searches.

To search for health events:

Access: Admin/Maint/Any Security Analyst

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Health Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in the Health Event Search Criteria table.

If you enter multiple criteria, the search returns only the records that match all the criteria.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have to following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so you can run it at a later time.

- Click Save as New to save a new search or assign a name to a search you created by altering a previously-save search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default health events workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Auditing the System

You can audit activity on your system in two ways. The appliances that are part of the FireSIGHT System generate an audit record for each user interaction with the web interface, and also record system status messages in the system log.

The following sections provide more information about the monitoring features that the system provides:

- Managing Audit Records describes how to view and manage system audit information.

- Viewing the System Log describes how to view the system log, which contains system status messages.

Tip Defense Centers and managed devices with Protection licenses also provide full reporting features that allow you to generate reports for almost any type of data accessible in an event view, including auditing data. For more information, see Working with Reports.

Managing Audit Records

License: Any

Defense Centers and managed devices log read-only auditing information for user activity. Audit logs are presented in a standard event view that allows you to view, sort, and filter audit log messages based on any item in the audit view. You can easily delete and report on audit information and can view detailed reports of the changes that users make.

The audit log stores a maximum of 100,000 entries. When the number of audit log entries exceeds 100,000, the appliance prunes the oldest records from the database to reduce the number to 100,000.

Note If you reboot a Series 3 appliance, then log into the CLI as soon as you are able, any commands you execute are not recorded in the audit log until the web interface is available.

For more information, see the following sections:

- Viewing Audit Records

- Suppressing Audit Records

- Understanding the Audit Log Table

- Using the Audit Log to Examine Changes

- Searching Audit Records

Viewing Audit Records

License: Any

You can use the appliance to view a table of audit records. Then, you can manipulate the view depending on the information you are looking for. The predefined audit workflow includes a single table view of events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on an audit log workflow page.

Using the Audit Log to Examine Changes

Table 69-1 Audit Log Actions

To...

You can...

learn more about the contents of the columns in the table

find more information in Understanding the Audit Log Table.

modify the time range used when viewing audit records

find more information at Setting Event Time Constraints.

Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.

sort and constrain events on the current workflow page

find more information in Sorting Table View Pages and Changing Their Layout.

navigate within the current workflow page

find more information in Navigating to Other Pages in the Workflow.

navigate between pages in the current workflow, keeping the current constraints

click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.

drill down to the next page in the workflow

use one of the following methods:

- To drill down to the next workflow page constraining on a specific value, click a value within a row. Note that this only works on drill-down pages. Clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

- To drill down to the next workflow page constraining on some events, select the check boxes next to the events you want to view on the next workflow page, then click View .

- To drill down to the next workflow page keeping the current constraints, click View All .

Tip Table views always include “Table View” in the page name.
For more information, see Constraining Events.

constraining on a specific value

Click a value within a row.

If you click a value on a drill-down page, you move to the next page and constrain on the value.

Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

Tip Table views always include “Table View“ in the page name.
For more information, see Constraining Events.

delete audit records

use one of the following methods:

- To delete some items, select the check boxes next to events you want to delete, then click Delete .

- To delete all items in the current constrained view, click Delete All , then confirm you want to delete all the events.

temporarily use a different workflow

click (switch workflow). For more information, see Selecting Workflows.

bookmark the current page so you can quickly return to it

click Bookmark This Page. For more information, see Using Bookmarks.

navigate to the bookmark management page

click View Bookmarks. For more information, see Using Bookmarks.

generate a report based on the data in the current view

click Report Designer. For more information, see Creating a Report Template from an Event View.

view a summary of a change recorded in the audit log

column. For more information, see .

To view audit records:

Access: Admin

Step 1 Select System > Monitoring > Audit.

The first (and only) page of the default audit log workflow appears. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range. For more information, see Setting Event Time Constraints.

Tip If you are using a custom workflow that does not include the table view of audit events, click (switch workflow), then select Audit Log.

Working with Audit Events

License: Any

. When you disable a column, it is disabled for the duration of your session (unless you add it back later). Note that when you disable the first column, the Count column is added.

To hide or show other columns, or to add a disabled column back to the view, select or clear the appropriate check boxes before you click Apply.

Clicking a value within a row in a table view constrains the table view and does not drill down to the next page.

Tip Table views always include “Table View” in the page name.

For more information, see the following topics:

- Constraining Events.

- Using Compound Constraints

- Sorting Drill-Down Workflow Pages

- Understanding the Audit Log Table

Suppressing Audit Records

License: Any

If your auditing policy does not require that you audit specific types of user interactions with the FireSIGHT System, you can prevent those interactions from generating audit records. For example, by default, each time a user views the online help, the FireSIGHT System generates an audit record. If you do not need to keep a record of these interactions, you can automatically suppress them.

To configure audit event suppression, you must have access to an appliance’s admin user account, and you must be able to either access the appliance’s console or open a secure shell.

Caution Make sure that only authorized personnel have access to the appliance and to its admin account.

To suppress audit records, you must create one or more files in the /etc/sf directory in the following form:

AuditBlock.type

where type is address, message, subsystem, or user.

Note If you create an AuditBlock.type file for a specific type of audit message, but later decide that you no longer want to suppress them, you must delete the contents of the AuditBlock.type file but leave the file itself on the FireSIGHT System.

Table 69-2 Audit Block Types

Type

Description

Address

Create a file named AuditBlock.address and include, one per line, each IP address that you want to suppress from the audit log. You can use partial IP addresses provided that they map from the beginning of the address. For example, the partial address 10.1.1 matches addresses from 10.1.1.0 through 10.1.1.255.

Message

Create a file named AuditBlock.message and include, one per line, the message substrings that you want to suppress.

Note that substrings are matched so that if you include backup in your file, all messages that include the word backup are suppressed.

Subsystem

Create a file named AuditBlock.subsystem and include, one per line, each subsystem that you want to suppress.

Note that substrings are not matched. You must use exact strings. See the Subsystem Names table for a list of subsystems that are audited.

User

Create a file named AuditBlock.user and include, one per line, each user account that you want to suppress. You can use partial string matching provided that they map from the beginning of the username. For example, the partial username IPSAnalyst matches the user names IPSAnalyst1 and IPSAnalyst2.

Note that when you add an AuditBlock file, an audit record with a subsystem of Audit and a message of Audit Filter type Changed is added to the audit events. For security reasons, this audit record cannot be suppressed.

Table 69-3 Subsystem Names

Name

Includes user interactions with...

Admin

Administrative features such as system and access configuration, time synchronization, backup and restore, device management, user account management, and scheduling

Alerting

Alerting functions such as email, SNMP, and syslog alerting

Audit Log

Audit event views

Audit Log Search

Audit event searches

Command Line

Command line interface

Configuration

Email alerting

COOP

Continuity of operations feature

Date

Date and time range for event views

Default Subsystem

Options that do not have assigned subsystems

Detection & Prevention Policy

Menu options for intrusion policies

Error

System-level errors

eStreamer

eStreamer configuration

EULA

Reviewing the end user license agreement

Events

Intrusion and discovery event views

Events Clipboard

Intrusion event clipboard

Events Reviewed

Reviewed intrusion events

Events Search

Any event search

Failed to install rule update rule_update_id

Installing rule updates

Header

Initial presentation of the user interface after a user logs in

Health

Health monitoring

Health Events

Health monitoring event views

Help

Online help

High Availability

High availability feature

IDS Impact Flag

Impact flag configuration

IDS Policy

Intrusion policies

IDSPolicy > policy_name > Appliance > det_engine_name

Applying intrusion policies

IDSRule sid:sig_id rev:rev_num

Intrusion rules by SID

Incidents

Intrusion incidents

Insert Policy Apply Job

Applying policies

Install

Installing updates

Intrusion Events

Intrusion events

Login

Web interface login and logout functions

Menu

Any menu option

Configuration export > config_type > config_name

Importing configurations of a specific type and name

Permission Escalation

User role escalation

Preferences

User preferences, such as the time zone for a user account and individual event preferences

Policy

Any policy, including intrusion policies

Register

Registering devices on a Defense Center

RemoteStorageDevice

Configuring remote storage devices

Reports

Report listing and report designer features

Rules

Intrusion rules, including the rule editor and the rule importation process

Rule Update Import Log

Viewing the rule update import log

Rule Update Install

Installing rule updates

Status

Syslog, as well as host and performance statistics

System

Various system-wide settings

System Policy > policy_name Appliance > appliance_name

Applying system policies

Task Queue

Viewing the task queue

Users

Creating and modifying user accounts and roles

Understanding the Audit Log Table

License: Any

Table 69-4 Audit Log Fields

Field

Description

Time

Time and date that the appliance generated the audit record.

User

User name of the user that triggered the audit event.

Subsystem

Menu path the user followed to generate the audit record. For example, System > Monitoring > Audit is the menu path to view the audit log.

In a few cases where a menu path is not relevant, the Subsystem field displays only the event type. For example, Login classifies user login attempts.

Message

Action the user performed.

For example, Page View signifies that the user simply viewed the page indicated in the Subsystem, while Save means that the user clicked the Save button on the page.
) that you can click to see a summary of the changes. For more information, see Using the Audit Log to Examine Changes.

Source IP

IP address associated with the host used by the user.

Count

The number of events that match the information that appears in each row. Note that the Count field appears only after you apply a constraint that creates two or more identical rows.

Using the Audit Log to Examine Changes

License: Any

You can use the audit log to view detailed reports of changes to your system. These reports compare the current configuration of your system to its most recent configuration before a particular change.

) appears next to audit log events that reflect changes to the system. You can click the compare icon to access the Compare Configurations page and view a detailed report of a change.

The Compare Configurations page displays the differences between the system configuration before changes and the running configuration in a side-by-side format. The audit event type, time of last modification, and name of the user who made the change are displayed in the title bar above each configuration.

Differences between the two configurations are highlighted:

- Blue indicates that the highlighted setting is different in the two configurations, and the difference is noted in red text.

- Green indicates that the highlighted setting appears in one configuration but not the other.

To examine a change in the audit log:

Access: Admin

Step 1 Select System > Monitoring > Audit.

The first page of the default audit log workflow appears.

If you are using a custom workflow that does not include the table view of audit events, click (switch workflow), then select Audit Log.

column.

The Compare Configurations page appears. Note that you can navigate through changes individually by clicking Previous or Next above the title bar. If the change summary is more than one page long, you can also use the scroll bar on the right to view additional changes.

Searching Audit Records

License: Any

You can search audit records to find information specific to a user, a specific subsystem, or an audit record message.

Table 69-5 Audit Record Search Criteria

Search Field

Description

Example

User

Enter the user name of the user who triggered the audit events you want to see. You can use an asterisk (*) as a wildcard character in this field.

jsmith returns all audit records involving the user jsmith.

Subsystem

Enter the full menu path a user would follow to generate the audit records you want to see. You can use an asterisk (*) as a wildcard character in this field.

System > Monitoring > Audit and *Audit both return audit records that involve using the audit log.

*Audit* returns all of the above records, plus records that involve searching for audit records.

Message

The action the user performed or the button the user clicked on the page. You can use an asterisk (*) as a wildcard character in this field.

Apply returns audit records where the user applied an intrusion policy.

Save Rule returns audit records where the user saved a correlation rule.

Page View returns audit records where the user viewed the page.

Time

Specify the date and time the audit record was generated. See Specifying Time Constraints in Searches for the syntax for entering time.

> 2006-01-15 13:30:00 returns all audit records generated after January 15, 2006 at 1:30 PM.

Source IP

Enter the IP address of the host that you want to view audit records for.
type a specific IP address. You cannot use IP ranges when searching audit logs.

172.16.1.37 returns all audit records generated by a user from the 172.16.1.37 IP address.

Configuration Change

Specify whether or not you want to view audit records of configuration changes.

yes returns audit records of configuration changes.

For more information on searching, including how to load and delete saved searches, see Searching for Events.

To search for audit records:

Access: Admin

Step 1 Select Analysis > Search.

The Search page appears.

Step 2 Select Audit Log Events from the table drop-down list.

The Audit Log search page appears.

Tip To search the database for a different kind of event, select it from the table drop-down list.

Step 3 Enter your search criteria in the appropriate fields, as described in the Audit Record Search Criteria table.

If you enter criteria for multiple fields, the search returns only the records that match search criteria specified for all fields.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

- Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save. If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

- Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save. The search is saved (and visible only to your account if you selected Private) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default audit log workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow). For information on specifying a different default workflow, see Configuring Event View Settings.

Viewing the System Log

License: Any

The System Log (syslog) page provides you with system log information for the appliance. The system log displays each message generated by the system. The following items are listed in order:

- the date that the message was generated

- the time that the message was generated

- the host that generated the message

- the message itself

Note System log information is local. For example, you cannot use the Defense Center to view system status messages in the system logs on your managed devices.

You can view system log messages for specific components by using the filter feature. For more information, see Filtering System Log Messages.

To view the syslog:

Access: Admin/Maint

Step 1 Select System > Monitoring > Syslog.

The System Log page appears.

Tip On the 3D9900, the Load Balancing Interface Module (LBIM) forwards messages to the device's syslog. You can find these messages by filtering on lbim.

Filtering System Log Messages

License: Any

You can view system log messages for specific components by using the filter feature. Filtering allows you to search for specific messages based on content.

The filter functionality uses the UNIX file search utility Grep, and as such, you can use most syntax accepted by Grep. This includes using Grep-compatible regular expressions for pattern matching. You can use a single word as a filter, or you can use Grep-supported regular expressions to search for content.

The following table shows the regular expression syntax you can use in System Log filters:

Table 69-6 System Log Filter Syntax

Syntax Component

Description

Example

.

Matches any character or white space

Admi. matches Admin, AdmiN, Admi1, and Admi&

[[:alpha:]]

Matches any alphabetic character

[[:alpha:]]dmin matches Admin, bdmin, and Cdmin

[[:upper:]]

Matches any uppercase alphabetic character

[[:upper:]]dmin matches Admin, Bdmin, and Cdmin

[[:lower:]]

Matches any lowercase alphabetic character

[[:lower:]]dmin matches admin, bdmin, and cdmin

[[:digit:]]

Matches any numeric character

[[:digit:]]dmin matches 0dmin, 1dmin, and 2dmin

[[:alnum:]]

Matches any alphanumeric character

[[:alnum:]]dmin matches 1dmin, admin, 2dmin, and bdmin

[[:space:]]

Matches any white space, including tabs

Feb[[:space:]]29 matches logs from February 29th.

*

Matches zero or more instances of the character or expression it follows

ab* matches a, ab, abb, ca, cab, and cabb

[ab]* matches anything

?

Matches zero or one instances

ab? matches a or ab.

\

Allows you to search for a character typically interpreted as regular expression syntax

alert\? matches alert?.

Table 69-7 System Log Filter Examples

To search for all log entries that...

Use...

Are generated on November 5

Nov[[:space:]]*5

Contain the user name “Admin”

Admin

Contain authorization debugging information on November 5

Nov[[:space:]]*5.*AUTH.*DEBUG

To search for specific message content in the system log:

Access: Admin/Maint

Step 1 Select System > Monitoring > Syslog.

The System Log page appears.

Step 2 Enter a word or query in the filter field.

See the tables above for more information about the filter syntax you can use.

Note Only Grep-compatible search syntax is supported. For example, you could search for all NTP-related system log messages by using ntp as a filter, or search for all messages generated in November by using Nov as a filter. You could view messages from November 27th by using Nov[[:space:]]*27 or Nov.*27, but you could not, however, use Nov 27 or Nov*27 to view these messages.

Step 3 Optionally, to make your search case-sensitive, check Case-sensitive. (By default, filters are not case-sensitive.)

Step 4 Optionally, check Exclusion to search for all system log messages that do not meet the criteria you entered.

Step 5 Click Go.

The messages that match the filter appear.

Using Backup and Restore

Backup and restoration is an essential part of any system maintenance plan. While each organization’s backup plan is highly individualized, the FireSIGHT System provides a mechanism for archiving data so that data from a Defense Center or physical managed device can be restored in case of disaster.

Note the following limitations about backup and restore:

- Backups are valid only for the product version on which you create them.

- Backups do not include captured file data.

- You cannot create or restore backup files for virtual managed devices, Cisco NGIPS for Blue Coat X-Series, or Cisco ASA with FirePOWER Services. To back up all event data, perform a backup of the managing Defense Center.

- You can restore a backup onto a replacement appliance only if the two appliances are the same model and are running the same version of the FireSIGHT System software.

Caution Do not use the backup and restore process to copy the configuration files between managed devices. The configuration files include information that uniquely identifies a device and cannot be shared.

Caution If you applied any intrusion rule updates, those updates are not backed up. You need to apply the latest rule update after you restore.

You can save backup files to the appliance or to your local computer. Additionally, if you are using a Defense Center, you can use remote storage as detailed in Managing Remote Storage.

Caution Never insert a USB drive into any USB port on a 3D9900. Additionally, remove any device with external storage (for example, a KVM switch with external storage) from a 3D9900 before upgrading or restoring the device.

See the following sections for more information:

- See Creating Backup Files for information about creating backup files for Defense Centers and physical managed devices.

- See Creating Backup Profiles for information about creating backup profiles that you can use later as templates for creating backups.

- See Uploading Backups from a Local Host for information about uploading backup files from a local host.

- See Restoring the Appliance from a Backup File for information about how to restore a backup file to the appliance.

Creating Backup Files

License: Any

Supported Devices: Any except virtual, X-Series, and ASA FirePOWER

Supported Defense Centers: Any

You can perform backups of physical managed devices from the devices themselves, backups of physical managed devices from their managing Defense Center, and backups of Defense Centers. The system backs up different data depending on the type of backup you perform. Note that the system does not back up captured file data. Use the following table to determine what kind of backup you want to perform.

Table 70-1 Data Stored by Backup Type

Backup type

Includes configuration data?

Includes event data?

Includes unified files?

Defense Center

Yes

Yes

No

Physical managed device, performed from the device itself

Yes

No

No

Physical managed device, performed from the managing Defense Center

Yes

No

Yes

Note You cannot create or restore backup files for virtual managed devices, Cisco NGIPS for Blue Coat X-Series, or Cisco ASA with FirePOWER Services. To back up event data, perform a backup of the managing Defense Center.

To view and use existing system backups, go to the Backup Management page. You should periodically save a backup file that contains all of the configuration files required to restore the appliance, in addition to event data. You may also want to back up the system when testing configuration changes so that you can revert to a saved configuration if needed. You can choose to save the backup file on the appliance or on your local computer.

You cannot create a backup file if your appliance does not have enough disk space; backups may fail if the backup process uses more than 90% of available disk space. If necessary, delete old backup files, transfer old backup files off the appliance, or use remote storage.

As an alternative, or if your backup file is larger than 4GB, copy it via SCP to a remote host. Uploading a backup from your local computer does not work on backup files larger than 4GB because web browsers do not support uploading files that large. On Defense Centers, the backup file can be saved to a remote location; see Managing Remote Storage for more information.

Note While your backup task is collecting discovery events, data correlation is temporarily suspended.

Note the following:

- Private keys associated with PKI objects are encrypted with a randomly generated key when stored on the appliance. If you perform a backup that contains private keys associated with PKI objects, the private keys are decrypted before being included in the unencrypted backup file. Store the backup file in a secure location.

- If you restore a backup that contains private key associated with PKI objects, the system encrypts the keys with a randomly generated key before storing them on the appliance.

- If you perform a backup, then delete reviewed intrusion events, your backup restores the deleted intrusion events but does not restore their reviewed status. You view those restored intrusion events under Intrusion Events, not under Reviewed Events. See Reviewing Intrusion Events.

- If you restore a backup that contains intrusion event data on an appliance that already contains that data, duplicate events are created. To avoid this, restore intrusion event backups only on appliances without prior intrusion event data.

Caution If you configured any interface associations with security zones, these associations are not backed up. You must reconfigure them after you restore. For more information, see Working with Security Zones.

To create a backup file of a Defense Center:

Access: Admin/Maint

Step 1 Select System > Tools > Backup/Restore.

The Backup Management page appears.

Step 2 Click Defense Center Backup.

The Create Backup page appears.

Step 3 In the Name field, type a name for the backup file. You can use alphanumeric characters, punctuation, and spaces.

Step 4 On Defense Centers, you have two further options:

- To archive the configuration, select Back Up Configuration .

- To archive the entire event database, select Back Up Events .

Step 5 Optionally, to be notified when the backup is complete, select the Email check box and type your email address in the accompanying text box.

Note To receive email notifications, you must configure a relay host as described in Configuring a Mail Relay Host and Notification Address.

Step 6 Optionally, on Defense Centers, to use secure copy (SCP) to copy the backup archive to a different machine, select the Copy when complete check box, then type the following information in the accompanying text boxes:

- in the Host field, the hostname or IP address of the machine where you want to copy the backup

- in the Path field, the path to the directory where you want to copy the backup

- in the User field, the user name you want to use to log into the remote machine

- in the Password field, the password for that user name

If you prefer to access your remote machine with an SSH public key instead of a password, you must copy the contents of the SSH Public Key field to the specified user’s authorized_keys file on that machine.

With this option cleared, the system stores temporary files used during the backup on the remote server; temporary files are not stored on the remote server when this option is selected.

Tip Cisco recommends that you periodically save backups to a remote location so the appliance can be restored in case of system failure.

Step 7 You have the following options:

- To save the backup file to the appliance, click Start Backup .

The backup file is saved in the /var/sf/backup directory. You can direct the backup file to a remote location; see Managing Remote Storage.

When the backup process is complete, you can view the file on the Restoration Database page. For information about restoring a backup file, see Restoring the Appliance from a Backup File.

- To save this configuration as a backup profile that you can use later, click Save As New .

You can modify or delete the backup profile by selecting System > Tools > Backup/Restore, then clicking Backup Profiles. See Creating Backup Profiles for more information.

To create a backup file of a physical managed device from the device itself:

Access: Admin/Maint

Step 1 Select System > Tools > Backup/Restore.

The Device Backups page appears.

Step 2 Click Device Backup.

The Create Backup page appears.

Step 3 In the Name field, type a name for the backup file. You can use alphanumeric characters, punctuation, and spaces.

Step 4 Optionally, to be notified when the backup is complete, select the Email check box and type your email address in the accompanying text box.

Note To receive email notifications, you must configure a relay host as described in Configuring a Mail Relay Host and Notification Address.

Step 5 Optionally, to use secure copy (SCP) to copy the backup archive to a different machine, select the Copy when complete check box, then type the following information in the accompanying text boxes:

- in the Host field, the hostname or IP address of the machine where you want to copy the backup

- in the Path field, the path to the directory where you want to copy the backup

- in the User field, the user name you want to use to log into the remote machine

- in the Password field, the password for that user name

If you prefer to access your remote machine with an SSH public key instead of a password, you must copy the contents of the SSH Public Key field to the specified user’s authorized_keys file on that machine.

With this option cleared, the system stores temporary files used during the backup on the remote server; temporary files are not stored on the remote server when this option is selected.

Tip Cisco recommends that you periodically save backups to a remote location so the appliance can be restored in case of system failure.

Step 6 You have the following options:

- To save the backup file to the appliance, click Start Backup .

The backup file is saved in the /var/sf/backup directory. On Defense Centers, you can direct the backup file to a remote location; see Managing Remote Storage.

When the backup process is complete, you can view the file on the Restoration Database page. For information about restoring a backup file, see Restoring the Appliance from a Backup File.

- To save this configuration as a backup profile that you can use later, click Save As New .

You can modify or delete the backup profile by selecting System > Tools > Backup/Restore, then clicking Backup Profiles. See Creating Backup Profiles for more information.

To create a backup file of a physical managed device from its managing Defense Center:

Access: Admin/Maint

Step 1 Select System > Tools > Backup/Restore.

The Backup Management page appears.

Step 2 Click Managed Device Backup.

The Create Backup page appears.

Step 3 In the Managed Devices field, select one or more managed devices. Use the Shift or Ctrl keys to select multiple managed devices.

Step 4 To include unified files in addition to configuration data, select the Include All Unified Files check box.

Step 5 To save the backup file on the Defense Center, select the Retrieve to Defense Center check box. To save each device’s backup file on the device itself, leave this check box unselected.

Note If you select Retrieve to Defense Center and your Defense Center is configured for remote storage of backups, the device backup file will be saved to the configured remote location, not the Defense Center itself.

Step 6 Click Start Backup.

A success message appears and the backup task is created.

The backup file is saved in the /var/sf/backup directory. Using the Defense Center, you can direct the backup file to a remote location; see Managing Remote Storage.

When the backup process is complete, you can view the file on the Restoration Database page. For information about restoring a backup file, see Restoring the Appliance from a Backup File.

Step 7 Optionally, to save this configuration as a backup profile that you can use later, click Save As New.

You can modify or delete the backup profile by selecting System > Tools > Backup/Restore, then clicking Backup Profiles. See Creating Backup Profiles for more information.

Creating Backup Profiles

License: Any

Supported Devices: Any except virtual, X-Series, and ASA FirePOWER

Supported Defense Centers: Any

You can use the Backup Profiles page to create backup profiles that contain the settings that you want to use for different types of backups. You can later select one of these profiles when you back up the files on your appliance.

Tip When you create a backup file as described in Creating Backup Files, a backup profile is automatically created.

To create a backup profile:

Access: Admin/Maint

Step 1 Select System > Tools > Backup/Restore.

The Backup Management page appears.

Step 2 Click the Backup Profiles tab.

The Backup Profiles page appears with a list of existing backup profiles.

Step 3 Click Create Profile.

The Create Backup page appears.

Step 4 Type a name for the backup profile. You can use alphanumeric characters, punctuation, and spaces.

Step 5 Configure the backup profile according to your needs.

See Creating Backup Files for more information about the options on this page.

Step 6 Click Save As New to save the backup profile.

The Backup Profiles page appears and your new profile appears in the list.

Uploading Backups from a Local Host

License: Any

Supported Devices: Series 2 and Series 3

Supported Defense Centers: Any

If you download a backup file to your local host using the download function described in the Backup Management table, you can upload it to a Defense Center.

If your backup file contains PKI objects, private keys associated with internal CA and internal certificate objects are re-encrypted on upload with a randomly generated key.

Tip You cannot upload a backup larger than 4GB from your local host because web browsers do not support uploading files that large. As an alternative, copy the backup via SCP to a remote host and retrieve it from there. On Defense Centers, the backup file can be saved to and retrieved from a remote location; see Managing Remote Storage.

To upload a backup from your local host:

Access: Admin/Maint

Step 1 Select System > Tools > Backup/Restore.

The Backup Management page appears.

Step 2 Click Upload Backup.

The Upload Backup page appears.

Step 3 Click Browse and navigate to the backup file you want to upload.

After you select the file to upload, click Upload Backup.

Step 4 Click Backup Management to return to the Backup Management page.

The backup file is uploaded and appears in the backup list. After the Defense Center appliance verifies the file integrity, refresh the Backup Management page to reveal detailed file system information.

Restoring the Appliance from a Backup File

License: Any

Supported Devices: Series 2 and Series 3

Supported Defense Centers: Any

You can restore the appliance from backup files using the Backup Management page. To restore a backup, the VDB version in the backup file must match the current VDB version on your appliance. After you complete the restoration process, you must apply the latest Sourcefire Rule Update.

Caution Do not restore backups created on virtual Defense Centers to physical Defense Centers — this may stress system resources. If you must restore a virtual backup on a physical Defense Center, contact Support.

If your backup file contains PKI objects, private keys associated with internal CA and internal certificate objects are reencrypted on upload with a randomly generated key.

If you use local storage, backup files are saved to /var/sf/backup, which is listed with the amount of disk space used in the /var partition at the bottom of the Backup Management page. On Defense Centers, select Remote Storage at the top of the Backup Management page to configure remote storage options; then, to enable remote storage, select the Enable Remote Storage for Backups check box on the Backup Management page. If you use remote storage, the protocol, backup system, and backup directory are listed at the bottom of the page.

Note If you add licenses after a backup has completed, these licenses will not be removed or overwritten if this backup is restored. To prevent a conflict on restore, remove those licenses before restoring the backup, noting where the licenses were used, and add and reconfigure them after restoring the backup. If a conflict occurs, contact Support.

Table 70-2 Backup Management

Functionality

Description

System Information

The originating appliance name, type, and version. Note that you can only restore a backup to an identical appliance type and version.

Date Created

The date and time that the backup file was created

File Name

The full name of the backup file

VDB Version

The build of the vulnerability database (VDB) running on the appliance at the time of backup.

Location

The location of the backup file

Size (MB)

The size of the backup file, in megabytes

Events?

“Yes” indicates the backup includes event data

View

Click the name of the backup file to view a list of the files included in the compressed backup file.

Restore

Click with the backup file selected to restore it on the appliance. If your VDB version does not match the VDB version in the backup file, this option is disabled.

Download

Click with the backup file selected to save it to your local computer.

Delete

Click with the backup file selected to delete it.

Move

On a Defense Center, when you have a previously created local backup selected, click to send the backup to the designated remote backup location.

To restore the appliance from a backup file:

Access: Admin

Step 1 Select System > Tools > Backup/Restore.

The Backup Management page appears.

Step 2 To view the contents of a backup file, click the name of the file.

The manifest appears, listing the name of each file, its owner and permissions, and its file size and date.

Step 3 Click Backup Management to return to the Backup Management page.

Step 4 Select the backup file that you want to restore and click Restore.

The Restore Backup page appears.

Note that if the VDB version in the backup does not match the VDB version currently installed on your appliance, the Restore button is grayed out.

Caution This procedure overwrites all configuration files and, on the managed device, all event data.

Step 5 To restore files, select either or both:

- Replace Configuration Data

- Restore Event Data

Note Note that, when you restore the configuration of a managed device from a backup file, any device configuration changes you made from the device’s managing Defense Center will also be restored, even changes you made after you created that backup file.

Step 6 Click Restore to begin the restoration.

The appliance is restored using the backup file you specified.

Step 7 Reboot the appliance.

Step 8 Apply the latest Sourcefire Rule Update to reapply rule updates.

Step 9 Reapply any access control, intrusion, network discovery, health, and system policies to the restored system.

Specifying User Preferences

You can configure the preferences that are tied to a single user account, such as the home page, account password, time zone, dashboard, and event viewing preferences.

Depending on your user role, you can specify certain preferences for your user account, including passwords, event viewing preferences, time zone settings, and home page preferences. See the following sections for more information:

- Changing Your Password explains how to change the password for your user account.

- Specifying Your Home Page explains how to use one of the existing pages as your default home page. After setting this value, this becomes the first page you see upon logging into the appliance.

- Configuring Event View Settings describes how the event preferences affect what you see as you view events.

- Setting Your Default Time Zone explains how to set the time zone for your user account and describes how that affects the time stamp on the events that you view.

- Specifying Your Default Dashboard explains how to choose which of the dashboards you want to use as your default dashboard.

Changing Your Password

License: Any

Supported Devices: Series 2, Series 3

Supported Defense Centers: Any

All user accounts are protected with a password. You can change your password at any time, and depending on the settings for your user account, you may have to change your password periodically; see Changing an Expired Password.

Note that if password strength checking is enabled, passwords must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. Passwords cannot be a word that appears in a dictionary or include consecutive repeating characters.

Note If you are an LDAP or a RADIUS user, you cannot change your password through the web interface.

To change your password:

Access: Any

Step 1 From the drop-down list under your user name, select User Preferences.

The Change Password page appears.

Step 2 In the Current Password field, type your current password and click Change.

Step 3 In the New Password and Confirm fields, type your new password.

Step 4 Click Change.

A success message appears on the page when your new password is accepted by the system.

Changing an Expired Password

License: Any

Supported Devices: Series 2, Series 3

Supported Defense Centers: Any

Depending on the settings for your user account, your password may expire. Note that the password expiration time period is set when your account is created and cannot be changed. If your password has expired, the Password Expiration Warning page appears.

To respond to the password expiration warning:

Access: Any

Step 1 You have two choices:

- Click Change Password to change your password now.

If you have zero warning days left, you must change your password. Also, if password strength checking is enabled, passwords must be at least eight alphanumeric characters of mixed case and must include at least one numeric character. Passwords cannot be a word that appears in a dictionary or include consecutive repeating characters.

- Click Skip to change your password later.

Specifying Your Home Page

License: Any

You can specify a page within the web interface as your home page for the appliance. The default home page is the Summary Dashboard (Overview > Dashboards), except for user accounts with no dashboard access, which use the Welcome page.

To specify your home page:

Access: Any except External Database User

Step 1 From the drop-down list under your user name, select User Preferences.

The Change Password page appears.

Step 2 Click Home Page.

The Home Page page appears.

Step 3 Select the page you want to use as your home page from the drop-down list.

The options in the drop-down list are based on the access privileges for your user account. For more information, see User Account Privileges.

Step 4 Click Save.

Your home page preference is saved.

Configuring Event View Settings

License: Any

Use the Event View Settings page to configure characteristics of event views in the FireSIGHT System. Note that some event view configurations are available only for specific user roles. Users with the External Database User role can view parts of the event view settings user interface, but changing those settings has no meaningful result. For details, see the individual sections linked below.

To configure event preferences:

Access: feature dependent

Step 1 From the drop-down list under your user name, select User Preferences.

The User Preferences page appears.

Step 2 Click Event View Settings.

The Event View Settings page appears.

Step 3 Configure the basic characteristics of event views.

For more information, see Event Preferences.

Step 4 Configure file download preferences.

For more information, see File Preferences.

Step 5 Configure the default time window or windows.

For more information, see Default Time Windows.

Step 6 Configure default workflows.

For more information, see Default Workflows.

Step 7 Click Save.

Your changes are implemented.

Event Preferences

License: Any

Use the Event Preferences section of the Event View Settings page to configure basic characteristics of event views in the FireSIGHT System. This section is available for all user roles, although it has little to no significance for users who cannot view events.

The following fields appear in the Event Preferences section:

- The Confirm “All” Actions field controls whether the appliance forces you to confirm actions that affect all events in an event view.

For example, if this setting is enabled and you click Delete All on an event view, you must confirm that you want to delete all the events that meet the current constraints (including events not displayed on the current page) before the appliance will delete them from the database.

- The Resolve IP Addresses field allows the appliance, whenever possible, to display host names instead of IP addresses in event views.

Note that an event view may be slow to display if it contains a large number of IP addresses and you have enabled this option. Note also that for this setting to take effect, you must have a DNS server configured in the system settings; see Configuring Management Interfaces.

- The Expand Packet View field allows you to configure how the packet view for intrusion events appears. By default, the appliance displays a collapsed version of the packet view:

– None - collapse all subsections of the Packet Information section of the packet view

– Packet Text - expand only the Packet Text subsection

– Packet Bytes - expand only the Packet Bytes subsection

– All - expand all sections

Regardless of the default setting, you can always manually expand the sections in the packet view to view detailed information about a captured packet. For more information on the packet view, see Using the Packet View.

- The Rows Per Page field controls how many rows of events per page you want to appear in drill-down pages and table views.

- The Refresh Interval field sets the refresh interval for event views in minutes. Entering 0 disables the refresh option. Note that this interval does not apply to dashboards.

- The Statistics Refresh Interval controls the refresh interval for event summary pages such as the Intrusion Event Statistics and Discovery Statistics pages. Entering 0 disables the refresh option. Note that this interval does not apply to dashboards.

- The Deactivate Rules field controls which links appear on the packet view of intrusion events generated by standard text rules:

– All Policies - a single link that deactivates the standard text rule in all the locally defined custom intrusion policies

– Current Policy - a single link that deactivates the standard text rule in only the currently applied intrusion policy. Note that you cannot deactivate rules in the default policies.

– Ask - links for each of these options

To see these links on the packet view, your user account must have either Administrator or Intrusion Admin access.

File Preferences

License: Any

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

Use the File Preferences section of the Event View Settings page to configure basic characteristics of local file downloads. This section is only available to users with the Administrator, Security Analyst, or Security Analyst (Read Only) user roles.

Note that if your appliance does not support downloading captured files, these options are disabled. Because you cannot use a Malware license with a DC500, you cannot use those appliances to download files or modify these options.

The following fields appear in the File Preferences section:

- The Confirm ‘Download File’ Actions check box controls whether a File Download pop-up window appears each time you download a file, displaying a warning and prompting you to continue or cancel.

Caution Cisco strongly recommends you do not download malware, as it can cause adverse consequences. Exercise caution when downloading any file, as it may contain malware. Ensure you have taken any necessary precautions to secure the download destination before downloading files.

Note that you can disable this option any time you download a file. For more information on downloading files, see Downloading Stored Files to Another Location.

- When you download a captured file, the system creates a password-protected .zip archive containing the file. The Zip File Password field defines the password you want to use to restrict access to the .zip file. If you leave this field blank, the system creates archive files without passwords.

- The Show Zip File Password check box toggles displaying plain text or obfuscated characters in the Zip File Password field. When this field is cleared, the Zip File Password displays obfuscated characters.

Default Time Windows

License: Any

The time window, sometimes called the time range, imposes a time constraint on the events in any event view. Use the Default Time Windows section of the Event View Settings page to control the default behavior of the time window.

User role access to this section is as follows:

- Administrators and Maintenance Users can access the full section.

- Security Analysts and Security Analysts (Read Only) can access all options except Audit Log Time Window .

- Access Admins, Discovery Admins, External Database Users, Intrusion Admins, Network Admins, and Security Approvers can access only the Events Time Window option.

Note that, regardless of the default time window setting, you can always manually change the time window for individual event views during your event analysis. Also, keep in mind that time window settings are valid for only the current session. When you log out and then log back in, time windows are reset to the defaults you configured on this page. For more information, see Setting Event Time Constraints.

There are three types of events for which you can set the default time window:

- The Events Time Window sets a single default time window for most events that can be constrained by time.

- The Audit Log Time Window sets the default time window for the audit log.

- The Health Monitoring Time Window sets the default time window for health events.

You can only set time windows for event types your user account can access. All user types can set event time windows. Administrators, Maintenance Users, and Security Analysts can set health monitoring time windows. Administrators and Maintenance Users can set audit log time windows.

Note that because not all event views can be constrained by time, time window settings have no effect on event views that display hosts, host attributes, applications, clients, vulnerabilities, user identity, or white list violations.

You can either use Multiple time windows, one for each of these types of events, or you can use a Single time window that applies to all events. If you use a single time window, the settings for the three types of time window disappear and a new Global Time Window setting appears.

There are three types of time window:

- static , which displays all the events generated from a specific start time to a specific end time

- expanding , which displays all the events generated from a specific start time to the present; as time moves forward, the time window expands and new events are added to the event view

- sliding , which displays all the events generated from a specific start time (for example, one day ago) to the present; as time moves forward, the time window “slides” so that you see only the events for the range you configured (in this example, for the last day)

The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM on January 19, 2038 (UTC).

The following options appear in the Time Window Settings drop-down list:

- The Show the Last - Sliding option allows you configure a sliding default time window of the length you specify.

The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to the present. As you change event views, the time window “slides” so that you always see events from the last hour.

- The Show the Last - Static/Expanding option allows you to configure either a static or expanding default time window of the length you specify.

For static time windows, enable the Use End Time check box. The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows, disable the Use End Time check box. The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to the present. As you change event views, the time window expands to the present time.

- The Current Day - Static/Expanding option allows you to configure either a static or expanding default time window for the current day. The current day begins at midnight, based on the time zone setting for your current session.

For static time windows, enable the Use End Time check box. The appliance displays all the events generated from midnight to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows, disable the Use End Time check box. The appliance displays all the events generated from midnight to the present. As you change event views, the time window expands to the present time. Note that if your analysis continues for over 24 hours before you log out, this time window can be more than 24 hours.

- The Current Week - Static/Expanding option allows you to configure either a static or expanding default time window for the current week. The current week begins at midnight on the previous Sunday, based on the time zone setting for your current session.

For static time windows, enable the Use End Time check box. The appliance displays all the events generated from midnight to the time when you first viewed the events. As you change event views, the time window stays fixed so that you see only the events that occurred during the static time window.

For expanding time windows, disable the Use End Time check box. The appliance displays all the events generated from midnight Sunday to the present. As you change event views, the time window expands to the present time. Note that if your analysis continues for over 1 week before you log out, this time window can be more than 1 week.

Default Workflows

License: Any

A workflow is a series of pages displaying data that analysts use to evaluate events. For each event type, the appliance ships with at least one predefined workflow. For example, as a Security Analyst, depending on the type of analysis you are performing, you can choose among ten different intrusion event workflows, each of which presents intrusion event data in a different way.

The appliance is configured with a default workflow for each event type. For example, the Events by Priority and Classification workflow is the default for intrusion events. This means whenever you view intrusion events (including reviewed intrusion events), the appliance displays the Events by Priority and Classification workflow.

You can, however, change the default workflow for each event type using the Default Workflows sections of the Event View Settings page.

Keep in mind that the default workflows you are able to configure depend on your user role. For example, intrusion event analysts cannot set default discovery event workflows. For general information on workflows, see Understanding and Using Workflows.

Setting Your Default Time Zone

License: Any

You can change the time zone used to display events from the standard UTC time that the appliance uses. When you configure a time zone, it applies only to your user account and is in effect until you make further changes to the time zone.

Caution The Time Zone function assumes that the default system clock is set to UTC time. If you have changed the system clock on the appliance to use a local time zone, you must change it back to UTC time in order to view accurate local time on the appliance. For more information about time synchronization between the Defense Center and the managed devices, see Synchronizing Time.

To change your time zone:

Access: Any

Step 1 From the drop-down list under your user name, select User Preferences.

The Change Password page appears.

Step 2 Click Time Zone Settings.

The Time Zone Preference page appears.

Step 3 From the left list box, select the continent or area that contains the time zone you want to use.

For example, if you want to use a time zone standard to North America, South America, or Canada, select America.

Step 4 From the right list box, select the zone (city name) that corresponds with the time zone you want to use.

For example, if you want to use Eastern Standard Time, you would select New York after selecting America in the first time zone box.

Step 5 Click Save.

The time zone is set.

Specifying Your Default Dashboard

License: Any

You can specify one of the dashboards on the appliance as the default dashboard. The default dashboard appears when you select Overview > Dashboards. If you do not have a default dashboard defined, the Dashboard List page appears. For general information on dashboards, see Using Dashboards.

To specify your default dashboard:

Access: Admin/Maint/Any Security Analyst

Step 1 From the drop-down list under your user name, select User Preferences.

The Change Password page appears.

Step 2 Click Dashboard Settings.

The Dashboard Settings page appears.

Step 3 Select the dashboard you want to use as your default from the drop-down list.

If you select None, when you select Overview > Dashboards, the Dashboard List page appears. You can then select a dashboard to view.

Step 4 Click Save.

Your default dashboard preference is saved.

Importing and Exporting Configurations

You can use the Import/Export feature to copy several types of configurations, including policies, from one appliance to another appliance of the same type. Configuration import and export is not intended as a backup tool, but can be used to simplify the process of adding new appliances to your FireSIGHT System.

You can import and export the following configurations:

- access control policies and their associated network analysis, SSL, and file policies

- intrusion policies

- health and system policies

- alert responses

- application detectors

- dashboards, custom tables, custom workflows, and saved searches

- custom user roles

- report templates

- third-party product and vulnerability mappings

To import an exported configuration, both appliances must be running the same version of the FireSIGHT System. To import an exported intrusion or access control policy, the rule update versions on both appliances must also match.

For more information, see the following sections:

- Exporting Configurations

- Importing Configurations

Exporting Configurations

License: Any

You can export a single configuration, or you can export a set of configurations (of the same type or of different types) at once. When you later import the package onto another appliance, you can choose which configurations in the package to import.

When you export a configuration, the appliance also exports revision information for that configuration. The FireSIGHT System uses that information to determine whether you can import that configuration onto another appliance; you cannot import a configuration revision that already exists on an appliance.

In addition, when you export a configuration, the appliance also exports system configurations that the configuration depends on, such as authentication objects. For example, if you set up authentication to an LDAP server on your Defense Center, then export a Defense Center system policy with authentication enabled, the authentication object is exported as well.

You can export the following configurations:

- Alert responses — An alert response is a set of configurations that allows the FireSIGHT System to interact with the external system where you plan to send the alert.

- Custom tables — A custom table is a table you can construct that combines fields from two or more of the predefined tables delivered with the FireSIGHT System.

- Custom user roles — A custom user role is a user role that you create with a specialized set of access privileges. Exporting a custom user role that requires saved searches also exports all of the necessary saved searches.

- Custom workflows — A custom workflow is a workflow that you create to meet the unique needs of your organization. On the Defense Center, you can export custom workflows that you create as well as the predefined custom workflows delivered with the appliance.

Note that if a Defense Center does not allow you to view the table on which an exported custom workflow is based, you can import the workflow but will not be able to view it.

- Dashboards — A dashboard is a customizable tabbed view that provides you with an at-a-glance display of your current system status. Dashboards use various widgets to present data about the events collected and generated by the FireSIGHT System, as well as information about the status and overall health of the appliances in your deployment.

Note that the dashboard widgets that you can view depend on the type of appliance you are using and on your user role. For more information, see Understanding Widget Availability.

- Access control policies — Access control policies include a variety of components that you can configure to determine how the system manages traffic on your network. These components include access control rules; associated intrusion, file, network analysis, and SSL policies; and objects the rules and policies use, including intrusion variable sets. Exporting an access control policy exports all settings and components for the policy except (where present) URL reputations and categories, which are equivalent across appliances and which users cannot change. Any custom URL objects or groups referenced in the access control policy are included when the policy is exported. Note that to import an access control policy, the rule update version on the exporting and importing Defense Center must match. Note that to import an access control policy, the rule update version on the exporting and importing Defense Center must match.

If an access control policy that you export, or the SSL policy it invokes, contains rules that reference geolocation data, the importing Defense Center’s geolocation database (GeoDB) update version is used.

PKI objects containing private key information are encrypted with a randomly generated key when stored on the appliance. If an access control policy that you export references an SSL policy that uses PKI objects containing private keys, the private keys are decrypted before export.

If an access control policy that you export references an unsupported DC500 or Series 2 device policy feature or rule condition, you cannot use a DC500 to apply the policy and you cannot apply the policy to a Series 2 device. Neither the DC500 nor Series 2 devices support user or URL rule conditions, Security Intelligence, or file policies that include rules that use the Block Malware or Malware Cloud Lookup action. Additionally, Series 2 devices do not support application rule conditions.

- Health policies — A health policy comprises the criteria used when checking the health of appliances in your deployment, that is, whether your Cisco hardware and software are working correctly.

- Intrusion policies — Intrusion policies include a variety of components that you can configure to inspect your network traffic for intrusions and policy violations. These components intrusion rules that inspect the protocol header values, payload content, and certain packet size characteristics; FireSIGHT recommended rules configurations; and other advanced settings.

Exporting an intrusion policy exports all settings for the policy. For example, if you choose to set a rule to generate events, or if you set SNMP alerting for a rule, or if you turn on the sensitive data preprocessor in a policy, those settings remain in place in the exported policy. Custom rules, custom rule classifications, and user-defined variables are also exported with the policy.

Note that if you export an intrusion policy that uses a layer that is shared by a second intrusion policy, that shared layer is copied into the policy you are exporting and the sharing relationship is broken. When you import the intrusion policy on another appliance, you can edit the imported policy to suit your needs, including deleting, adding, and sharing layers.

If you export an intrusion policy from one Defense Center to another, the imported policy may behave differently if the second Defense Center has differently configured default variables.

Note You cannot use the Import/Export feature to update rules created by Cisco’s Vulnerability Research Team (VRT). Instead, download and apply the latest rule update version; see Importing Rule Updates and Local Rule Files.

- Report templates — Reports are document files formatted in PDF, HTML, or CSV that collate specific FireSIGHT System data. A report template specifies the data searches and formats for the report and its sections. When you export a report template, all saved searches, images, objects created in the object manager, and custom tables that are necessary for the report are exported also.

- Saved searches — A saved search provides access to predefined FireSIGHT System data for users with limited permissions. When you export a custom user role that requires saved searches, the necessary saved searches are exported also. You can also export individual user-defined saved searches.

- SSL policies - SSL policies include a variety of components that you can configure to determine how the system manages encrypted traffic on your network, including SSL rules and references reusable objects. Exporting an SSL policy exports all settings and components for the policy except (where present) URL reputations and categories, which are equivalent across appliances and which users cannot change. Note that to import an SSL policy, the rule update version on the exporting and importing Defense Center must match.

PKI objects containing private key information are encrypted with a randomly generated key when stored on the appliance. If an SSL policy you export uses PKI objects containing private keys, the private keys are decrypted before export.

If an SSL policy that you export contains rules that reference geolocation data, the importing Defense Center’s geolocation database (GeoDB) update version is used.

- System policies — A system policy controls the aspects of an appliance that are likely to be similar to other FireSIGHT System appliances in your deployment, including database event limits, time settings, login banners, and so on.

If external authentication is enabled in the system policy you are exporting, the associated authentication objects are exported as well.

Note that system policies on Defense Centers contain database settings that do not apply to managed devices. If you export a system policy from a managed device and then import it onto a Defense Center, the database limits that you could not configure on the device are set to the default values on the Defense Center.

- Third-party product mappings — If you import data from a third-party application, you must map the product to the third-party name to assign vulnerabilities and perform impact correlation using that data. Mapping the product associates Cisco vulnerability information with the third-party product name, which allows the FireSIGHT System to perform impact correlation using that data. For information on creating a third-party product mapping, see Mapping Third-Party Products.

- Third-party vulnerability mappings — To add vulnerability information from a third-party application to the vulnerability database, you must map the third-party identification string for each imported vulnerability to any existing Cisco, Bugtraq, or Snort ID. After you create a mapping for the vulnerability, the mapping works for all vulnerabilities imported to hosts in your network map and allows impact correlation for those vulnerabilities. For information on creating a third-party vulnerability mapping, see Mapping Third-Party Vulnerabilities.

- Application detectors — When the system analyzes IP traffic, it uses detectors to collect information about and then identify the commonly used applications running on hosts on your network. You can export two kinds of detectors: user-defined detectors and individual add-on detectors provided by Cisco Professional Services. For more information on detectors, see Working with Application Detectors.

Note Depending on the number of configurations being exported and the number of objects those configurations reference, the export process may take several minutes.

To export one or more configurations:

Access: Admin

Step 1 Make sure that the appliance where you are exporting the configurations and the appliance where you plan to import the configurations are running the same version of the FireSIGHT System. If you are exporting an intrusion or access control policy, make sure that the rule update versions match.

If the versions of the FireSIGHT System (and, if applicable, the rule update versions) do not match, the import will fail.

Step 2 Select Systems > Tools > Import/Export.

The Import/Export page appears, including a list of the configurations on the appliance. Note that configuration categories with no configurations to export do not appear in this list.

Step 3 Select the check boxes next to the configurations you want to export and click Export.

Step 4 Follow your web browser’s prompts to save the exported package to your computer.

Importing Configurations

License: Any

After you export a configuration from an appliance, you can import it onto a different appliance as long as that appliance supports it. Note, however, that some imported configurations may not be useful depending on the type of appliance you are using and on your user role.

Depending on the type of configuration you are importing, you should keep the following points in mind:

- You must make sure that the appliance where you import a configuration is running the same version of the FireSIGHT System as the appliance you used to export the configuration. If you are importing an intrusion or access control policy, the rule update versions on both appliances must also match. If the versions do not match, the import will fail.

- When you import a custom user role that requires saved searches, the necessary saved searches are imported also.

- The dashboard widgets that you can view depend on the type of appliance you are using and on your user role. For example, a dashboard created on the Defense Center and imported onto a managed device may display some invalid, disabled widgets.

- If you import an access control policy that evaluates traffic based on zones, you must map the zones in the imported policy to zones on devices managed by the importing Defense Center. When you map zones, their types must match. Therefore, you must create any zone types you need on the importing Defense Center before you begin the import. For more information about security zones, see Working with Security Zones.

- If you import an access control policy or saved search that includes an object or object group that has an identical name to an existing object or group, you must rename the object or group.

- If you import an access control policy or an intrusion policy, the import process replaces existing default variables in the default variable set with the imported default variables. If your existing default variable set contains a custom variable not present in the imported default variable set, the unique variable is preserved.

- If you import an intrusion policy that used a shared layer from a second intrusion policy, the export process breaks the sharing relationship and the previously shared layer is copied into the package. In other words, imported intrusion policies do not contain shared layers.

Note You cannot use the Import/Export feature to update rules created by Cisco’s Vulnerability Research Team (VRT). Instead, download and apply the latest rule update version; see Importing Rule Updates and Local Rule Files.

- If you import an SSL policy that references PKI objects that contain private keys, the system encrypts the keys with a randomly generated key before storing them on the appliance.

- When you import a system policy that was exported from a Defense Center where external authentication is enabled, you also import the authentication objects on which the system policy depends.

Because you can export several configurations in a single package, when you import the package you must choose which configurations in the package to import. You can only import configurations that are supported on the destination appliance.

When you attempt to import a configuration, your appliance determines whether that configuration already exists on the appliance. If a conflict exists, you can:

- keep the existing configuration,

- replace the existing configuration with a new configuration,

- keep the newest configuration, or

- import the configuration as a new configuration.

If you import a configuration and then later make a modification to the configuration on the destination system, and then re-import the configuration, you must choose which version of the configuration to keep.

Depending on the number of configurations being imported and the number of objects those configurations reference, the import process may take several minutes.

To import one or more configurations:

Access: Admin

Step 1 Make sure that the appliance where you are exporting the configurations and the appliance where you plan to import the configurations are running the same version of the FireSIGHT System. If you want to import an intrusion or access control policy, you must also make sure that the rule update versions match.

If the versions of the FireSIGHT System (and, if applicable, the rule update versions) do not match, the import will fail.

Step 2 Export the configurations you want to import; see Exporting Configurations.

Step 3 On the appliance where you want to import the configurations, select System > Tools > Import/Export.

The Import/Export page appears.

Step 4 Click Upload Package.

The Upload Package page appears.

Step 5 You have two options:

- Type the path to the package you want to upload.

- Click Browse to browse to locate the package.

Step 6 Click Upload.

The result of the upload depends on the contents of the package:

- If the configurations in the package exactly match versions that already exist on your appliance, a message displays indicating that the versions already exist. The appliance has the most recent configurations, so you do not need to import them.

- If there is a FireSIGHT System or (if applicable) rule update version mismatch between your appliance and the appliance where the package was exported, a message appears, indicating that you cannot import the package. Update the FireSIGHT System or the rule update version and attempt the process again.

- If the package contains any configurations or rule versions that do not exist on your appliance, the Package Import page appears. Continue with the next step.

Step 7 Select the configurations you want to import and click Import.

The import process resolves, with the following results:

- If the configurations you import do not have previous revisions on your appliance, the import completes automatically and a success message appears. Skip the rest of the procedure.

- If you are importing an access control policy that includes security zones, the Access Control Import Resolution page appears. Continue with step 8 .

- If the configurations you import do have previous revisions on your appliance, the Import Resolution page appears. Continue with step 9 .

Step 8 Next to each incoming security zone, select an existing local security zone of a matching type to map to and click Import.

Return to step 7.

Step 9 Expand each configuration and select the appropriate option:

- To keep the configuration on your appliance, select Keep existing .

- To replace the configuration on your appliance with the imported configuration, select Replace existing .

- To keep the newest configuration, select Keep newest .

- To save the imported configuration as a new configuration, select Import as new and, optionally, edit the configuration name.

If you are importing an access control policy that includes a file policy with either the clean list or custom detection list enabled, the Import as new option is not available.

- If you are importing an access control policy or saved search that includes a dependent object, either accept the suggested name or rename the object. The system always imports these dependent objects as new. You do not have the option to keep or to replace existing objects. Note that the system treats objects and object groups in the same manner.

Step 10 Click Import.

The configurations are imported.

Purging Discovery Data from the Database

You can use the Discovery Data Purge page to purge files from the network discovery and user discovery event databases. Note that when you purge a database, the appropriate process is restarted.

Caution Purging a database removes the data you specify from the Defense Center. After the data is deleted, it cannot be recovered.

To purge the network and user discovery database:

Access: Admin/Any Security Analyst

Step 1 Select System > Tools > Data Purge.

The Data Purge page appears.

Step 2 Under Network Discovery, perform any or all of the following:

- Select Network Discovery Events to remove all network discovery events from the database.

- Select Hosts to remove all hosts and Indications of Compromise flags from the database.

- Select User Activity to remove all user events from the database.

- Select User Identities to remove all user login and user history data from the database.

Step 3 Under Connections, perform any or all of the following:

- Select Connection Events to remove all connection data from the database.

- Select Connection Summary Events to remove all connection summary data from the database.

- Select Security Intelligence Events to remove all Security Intelligence data from the database.

Note Selecting Connection Events does not remove Security Intelligence events; connections with Security Intelligence data will still appear in the Security Intelligence event viewer. Correspondingly, selecting Security Intelligence Events does not remove connection events with associated Security Intelligence data.

Step 4 Click Purge Selected Events.

The items are purged and the appropriate processes are restarted.

Viewing the Status of Long-Running Tasks

Some tasks that you can perform on the FireSIGHT System, such as applying a policy or installing updates, do not complete instantly and require some time to run. You can check the progress of these long-running tasks in the task queue. The task queue also reports when they are successfully or unsuccessfully resolved.

For more information, see the following sections:

- Viewing the Task Queue

- Managing the Task Queue

Viewing the Task Queue

License: Any

When you perform long-running tasks, such as applying a policy or installing updates, the status of these tasks is reported in the task queue. The task queue provides information about complex tasks and reports when they are complete.

You view the task queue on the Task Status page, which automatically refreshes every 10 seconds. You can always see the status of tasks that you initiated. If your user account has the Administrator user role, or a user role with the View Other Users’ Tasks permission enabled, you can see the status of every task, regardless of who initiated it. For more information on configuring user roles, see Configuring User Roles.

The Job Summary section displays the state of the tasks listed on the page, as described in the following table.

Table C-1 Task Queue Task Types

Task Type

Description

Running

The number of tasks currently in progress.

Waiting

The number of tasks waiting for an in-progress task to complete before running.

Completed

The number of tasks that completed successfully.

Retrying

The number of tasks that are automatically retrying. Note that not all tasks are permitted to try again.

Stopped

The number of tasks that were interrupted due to a system update. Stopped tasks cannot be resumed; you must manually delete them from the task queue.

Failed

The number of tasks that did not complete successfully.

The Jobs section provides information about each task, including a brief description, when the task was launched, the current status of the task, and when the status last changed. Tasks of the same type, such as Network Discovery Policy Apply, appear together in a task group.

To make sure that the Task Status page loads quickly, once per week, the FireSIGHT System removes from the queue all completed, failed, and stopped tasks that are over a month old, as well the oldest tasks from any task group that contains over 1000 tasks. You can also manually remove tasks from the queue; see Managing the Task Queue for directions.

To view the task queue:

Access: Admin/Maint/Network Admin/Security Approver/Security Analyst

Step 1 You have two options:

- If you manually launched the task, click the Task Status link in the notification box that appeared when you launched the task.

The Task Status page appears in a pop-up window.

- If you scheduled a task, or if a task was launched from a page you are not viewing, select System > Monitoring > Task Status .

The Task Status page appears.

For information on the actions you can perform on the Task Status page, see Managing the Task Queue.

Managing the Task Queue

License: Any

If your user account is assigned the Administrator, Maintenance User, Network Admin, Security Approver, or Security Analyst user role, there are several actions you can perform while viewing the task queue (see Viewing the Task Queue), as described in the following table.

Note that you cannot delete a running task. If you need to delete a running task (for example, if a task repeatedly fails), contact Support.

Table C-2 Task Queue Actions

To...

You can...

remove all completed tasks from the task queue

click Remove Completed Jobs.

remove all failed tasks from the task queue

click Remove Failed Jobs.

remove a single task from the task queue

) next to the task you want to delete.

collapse a task group and hide tasks

) next to the expanded task group.

expand a task group and view tasks

) next to the collapsed task group.

Command Line Reference

This reference explains the command line interface (CLI) for FirePOWER appliances, virtual devices, and the ASA FirePOWER modules of ASA FirePOWER devices. You can use the CLI to view, configure, and troubleshoot your FireSIGHT System.

Note The command line interface is not supported on Defense Centers, Series 2 appliances, Cisco NGIPS for Blue Coat X-Series, or the ASA module of ASA FirePOWER devices.

There are numerous CLI modes, such as show and configure, that contain sets of commands beginning with the mode name. You may enter a mode and then enter valid commands within that mode, or you may enter an entire full command from any mode. For example, to display information about a user account called Analyst1, you can enter the following at the CLI prompt:

show user Analyst1

If you have previously entered show mode, enter the following at the CLI prompt:

user Analyst1

Within each mode, the commands available to a user depend on the user’s CLI access. When you create a user account, you can assign it one of the following CLI access levels:

- Basic

The user has read-only access and cannot run commands that impact system performance.

- Configuration

The user has read-write access and can run commands that impact system performance.

- None

The user is unable to log in to the shell.

On Series 3 devices, you can assign command line permissions on the User Management page in the web interface; see Managing Users for more information. On virtual devices and ASA FirePOWER devices, you assign command line permissions through the CLI itself.

Note If you reboot a Series 3 device and then log in to the CLI as soon as you are able, any commands you execute are not recorded in the audit log until the web interface is available.

Note that CLI commands are case-insensitive with the exception of parameters whose text is not part of the CLI framework, such as user names and search filters.

For information about logging into the command line, see Logging into the Appliance.

The following sections describe the CLI commands:

- Basic CLI Commands

- Show Commands

- Configuration Commands

- System Commands

Basic CLI Commands

The basic CLI commands provide the ability to interact with the CLI. These commands do not affect the operation of the device. Basic commands are available to all CLI users.

The following sections describe the basic commands:

- configure password

- end

- exit

- help

- history

- logout

- ? (question mark)

- ?? (double question marks)

configure password

Allows the current user to change their password. After issuing the command, the CLI prompts the user for their current (or old) password, then prompts the user to enter the new password twice.

Access

Basic

Syntax

configure password

Example

> configure password

Enter current password:

Enter new password:

Confirm new password:

end

Returns the user to the default mode. (Moves the user up to the default mode from any lower-level CLI context.)

Access

Basic

Syntax

end

Example

configure network ipv4> end

>

exit

Moves the CLI context up to the next highest CLI context level. Issuing this command from the default mode logs the user out of the current CLI session, and is equivalent to issuing the logout CLI command.

Access

Basic

Syntax

exit

Example

configure network ipv4> exit

configure network>

help

Displays an overview of the CLI syntax.

Access

Basic

Syntax

help

Example

> help

history

Displays the command line history for the current session.

Access

Basic

Syntax

history limit

where limit sets the size of the history list. To set the size to unlimited, enter zero.

Example

history 25

logout

Logs the current user out of the current CLI console session.

Access

Basic

Syntax

logout

Example

> logout

? (question mark)

Displays context-sensitive help for CLI commands and parameters. Use the question mark (?) command as follows:

- To display help for the commands that are available within the current CLI context, enter a question mark ( ? ) at the command prompt.

- To display a list of the available commands that start with a particular character set, enter the abbreviated command immediately followed by a question mark ( ? ).

- To display help for a command’s legal arguments, enter a question mark ( ? ) in place of an argument at the command prompt.

Note that the question mark (?) is not echoed back to the console.

Access

Basic

Syntax

?

abbreviated_command ?

command [arguments] ?

Example

> ?

?? (double question marks)

Displays detailed context-sensitive help for CLI commands and parameters.

Access

Basic

Syntax

??

abbreviated_command end??

command [arguments] ??

Example

> configure manager add ??

Show Commands

Show commands provide information about the state of the device. These commands do not change the operational mode of the device and running them has minimal impact on system operation. Most show commands are available to all CLI users; however, only users with configuration CLI access can issue the show user command.

The following sections describe the show commands:

- access-control-config

- alarms

- arp-tables

- audit-log

- bypass

- clustering

- cpu

- database

- device-settings

- disk

- disk-manager

- dns

- expert

- fan-status

- fastpath-rules

- gui

- hostname

- hosts

- hyperthreading

- iab

- ifconfig

- inline-sets

- interfaces

- lcd

- link-state

- log-ips-connection

- managers

- memory

- model

- mpls-depth

- NAT

- netstat

- network

- network-modules

- network-static-routes

- ntp

- perfstats

- portstats

- power-supply-status

- process-tree

- processes

- route

- routing-table

- serial-number

- ssl-policy-config

- stacking

- summary

- time

- traffic-statistics

- user

- users

- version

- virtual-routers

- virtual-switches

- vmware-tools

access-control-config

Displays the currently applied access control configurations, including: Security Intelligence settings; the name of referenced SSL, network analysis, intrusion, and file policies; intrusion variable set data; logging settings; and other advanced settings, including policy-level performance, preprocessing, and general settings.

Also displays policy-related connection information, such as source and destination port data (including type and code for ICMP entries) and the number of connections that matched each access control rule (hit counts).

Access

Basic

Syntax

show access-control-config

Example

> show access-control-config

alarms

Displays currently active (failed/down) hardware alarms on the device. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show alarms

Example

> show alarms

arp-tables

Displays the Address Resolution Protocol tables applicable to your network. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show arp-tables

Example

> show arp-tables

audit-log

Displays the audit log in reverse chronological order; the most recent audit log events are listed first.

Access

Basic

Syntax

show audit-log

Example

> show audit-log

bypass

On Series 3 devices, lists the inline sets in use and shows the bypass mode status of those sets as one of the following:

- armed —the interface pair is configured to go into hardware bypass if it fails, or has been forced into fail-close with the configure bypass close command

- engaged —the interface pair has failed open or has been forced into hardware bypass with the configure bypass open command

- off —the interface pair is set to fail-close ( Bypass Mode: Non-Bypass ); packets are blocked if the interface pair fails

Access

Basic

Syntax

show bypass

Example

> show bypass

s1p1 <-> s1p2: status ‘armed’

s1p1 <-> s1p2: status ‘engaged’

clustering

Displays information about device clustering configuration, status, and member stacks. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

config

Displays the clustering configuration on the device.

Syntax

show clustering config

Example

> show clustering config

clustering ha-statistics

Displays state sharing statistics for a device in a cluster.

Syntax

show clustering ha-statistics

Example

> show clustering ha-statistics

cpu

Displays the current CPU usage statistics appropriate for the platform for all CPUs on the device. For managed devices, the following values are displayed:

- CPU

Processor number.

- Load

The CPU utilization, represented as a number from 0 to 100. 0 is not loaded and 100 is completely loaded.

For virtual devices and ASA FirePOWER devices, the following values are displayed:

- CPU

Processor number.

- %user

Percentage of CPU utilization that occurred while executing at the user level (application).

- %nice

Percentage of CPU utilization that occurred while executing at the user level with nice priority.

- %sys

Percentage of CPU utilization that occurred while executing at the system level (kernel). This does not include time spent servicing interrupts or softirqs. A softirq (software interrupt) is one of up to 32 enumerated software interrupts that can run on multiple CPUs at once.

- %iowait

Percentage of time that the CPUs were idle when the system had an outstanding disk I/O request.

- %irq

Percentage of time spent by the CPUs to service interrupts.

- %soft

Percentage of time spent by the CPUs to service softirqs.

- %steal

Percentage of time spent in involuntary wait by the virtual CPUs while the hypervisor was servicing another virtual processor.

- %guest

Percentage of time spent by the CPUs to run a virtual processor.

- %idle

Percentage of time that the CPUs were idle and the system did not have an outstanding disk I/O request.

Access

Basic

Syntax

show cpu [procnum]

where procnum is the number of the processor for which you want the utilization information displayed. Valid values are 0 to one less than the total number of processors on the system. If procnum is used for a managed device, it is ignored because for that platform, utilization information can only be displayed for all processors.

Example

> show cpu

database

The show database commands configure the device’s management interface.

Access

Basic

processes

Displays a list of running database queries.

Access

Basic

Syntax

show database processes

Example

> show database processes

slow-query-log

Displays the slow query log of the database.

Access

Basic

Syntax

show database slow-query-log

Example

> show database slow-query-log

device-settings

Displays information about application bypass settings specific to the current device.

Access

Basic

Syntax

show device-settings

Example

> show device-settings

disk

Displays the current disk usage.

Access

Basic

Syntax

show disk

Example

> show disk

disk-manager

Displays detailed disk usage information for each part of the system, including silos, low watermarks, and high watermarks.

Access

Basic

Syntax

show disk-manager

Example

> show disk-manager

dns

Displays the current DNS server addresses and search domains.

Access

Basic

Syntax

show dns

Example

> show dns

expert

Invokes the shell.

Access

Basic

Syntax

expert

Example

> expert

fan-status

Displays the current status of hardware fans. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show fan-status

Example

> show fan-status

fastpath-rules

Displays the currently configured fastpath rules. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show fastpath-rules

Example

> show fastpath-rules

gui

Displays the current state of the web interface. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show gui

Example

> show gui

hostname

Displays the device’s host name and appliance UUID. If you edit the host name of a device using the CLI, confirm that the changes are reflected on the managing Defense Center. In some cases, you may need to edit the device management settings manually. For more information, see Editing Device Management Settings.

Access

Basic

Syntax

show hostname

Example

> show hostname

hosts

Displays the contents of an ASA FirePOWER module’s /etc/hosts file.

Access

Basic

Syntax

show hosts

Example

> show hosts

hyperthreading

Displays whether hyperthreading is enabled or disabled. This command is not available on ASA FirePOWER devices.

Access

Basic

Syntax

show hyperthreading

Example

> show hyperthreading

iab

Displays the current Intelligent Application Bypass (IAB) configuration. This command requires Version 5.4.0.10 or later on the managed device. The Defense Center requires Version 5.4.1.9 or later to implement IAB functionality, and Version 5.4.1.10 or later to provide IAB events.

Access

Basic

Syntax

show iab

Example

> show iab

IAB configuration:

Performance Sample Interval 5 seconds

Bytes per Flow 500000 kbytes

Flow Velocity 25000 kbytes/second

Drop Percentage 1%

Processor Utilization Percentage 95%

Packet Latency 250 microseconds

inline-sets

Displays configuration data for all inline security zones and associated interfaces. This command is not available on ASA FirePOWER devices.

Access

Basic

Syntax

show inline-sets

Example

> show inline-sets

interfaces

If no parameters are specified, displays a list of all configured interfaces. If a parameter is specified, displays detailed information about the specified interface.

Access

Basic

Syntax

show interfaces [interface]

where interface is the specific interface for which you want the detailed information.

Example

> show interfaces

ifconfig

Displays the interface configuration for an ASA FirePOWER module.

Access

Basic

Syntax

show ifconfig

Example

> show ifconfig

lcd

Displays whether the LCD hardware display is enabled or disabled. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show lcd

Example

> show lcd

link-aggregation

The show link-aggregation commands display configuration and statistics information for link aggregation groups (LAGs). This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

configuration

Displays configuration details for each configured LAG, including LAG ID, number of interfaces, configuration mode, load-balancing mode, LACP information, and physical interface type.

Access

Basic

Syntax

show link-aggregation configuration

Example

> show link-aggregation configuration

statistics

Displays statistics, per interface, for each configured LAG, including status, link state and speed, configuration mode, counters for received and transmitted packets, and counters for received and transmitted bytes.

Access

Basic

Syntax

show link-aggregation statistics

Example

> show link-aggregation statistics

link-state

Displays type, link, speed, duplex state, and bypass mode of the ports on the device. This command is not available on ASA FirePOWER devices.

Access

Basic

Syntax

show link-state

Example

> show link-state

log-ips-connection

Displays whether the logging of connection events that are associated with logged intrusion events is enabled or disabled.

Access

Basic

Syntax

show log-ips-connection

Example

> show log-ips-connection

managers

Displays the configuration and communication status of the Defense Center. Registration key and NAT ID are only displayed if registration is pending. If a device is registered to a high availability pair, information about both managing Defense Centers is displayed. If a device is configured as a secondary device in a stacked configuration, information about both the managing Defense Center and the primary device is displayed.

Access

Basic

Syntax

show managers

Example

> show managers

memory

Displays the total memory, the memory in use, and the available memory for the device.

Access

Basic

Syntax

show memory

Example

> show memory

model

Displays model information for the device.

Access

Basic

Syntax

show model

Example

> show model

mpls-depth

Displays the number of MPLS layers configured on the management interface, from 0 to 6. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show mpls-depth

Example

> show mpls-depth

NAT

The show nat commands display NAT data and configuration information for the management interface. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

active-dynamic

Displays NAT flows translated according to dynamic rules. These entries are displayed when a flow matches a rule, and persist until the rule has timed out. Therefore, the list can be inaccurate. Timeouts are protocol dependent: ICMP is 5 seconds, UDP is 120 seconds, TCP is 3600 seconds, and all other protocols are 60 seconds.

Syntax

show nat active-dynamic

Example

> show nat active-dynamic

active-static

Displays NAT flows translated according to static rules. These entries are displayed as soon as you apply the rule to the device, and the list does not indicate active flows that match a static NAT rule.

Syntax

show nat active-static

Example

> show nat active-static

allocators

Displays information for all NAT allocators, the pool of translated addresses used by dynamic rules.

Syntax

show nat allocators

Example

> show nat allocators

config

Displays the current NAT policy configuration for the management interface.

Syntax

show nat config

Example

> show nat config

dynamic-rules

Displays dynamic NAT rules that use the specified allocator ID.

Syntax

show nat dynamic-rules allocator_id

Example

> show nat dynamic-rules 9

where allocator_id is a valid allocator ID number.

flows

Displays the number of flows for rules that use the specified allocator ID.

Syntax

show nat flows allocator-id

Example

> show nat flows 81

where allocator_id is a valid allocator ID number.

static-rules

Displays all static NAT rules.

Syntax

show nat static-rules

Example

> show nat static-rules

netstat

Displays the active network connections for an ASA FirePOWER module.

Access

Basic

Syntax

show netstat

Example

> show netstat

network

Displays the IPv4 and IPv6 configuration of the management interface, its MAC address, and HTTP proxy address, port, and username if configured.

Access

Basic

Syntax

show network

Example

> show network

network-modules

Displays all installed modules and information about them, including serial numbers. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show network-modules

Example

> show network-modules

network-static-routes

Displays all configured network static routes and information about them, including interface, destination address, network mask, and gateway address.

Access

Basic

Syntax

show network-static-routes

Example

> show network-static-routes

ntp

Displays the ntp configuration.

Access

Basic

Syntax

show ntp

Example

> show ntp

perfstats

Displays performance statistics for the device.

Access

Basic

Syntax

show perfstats

Example

> show perfstats

portstats

Displays port statistics for all installed ports on the device. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show portstats [copper | fiber | internal | external | all]

where copper specifies for all copper ports, fiber specifies for all fiber ports, internal specifies for all internal ports, external specifies for all external (copper and fiber) ports, and all specifies for all ports (external and internal).

Example

> show portstats fiber

power-supply-status

Displays the current state of hardware power supplies. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show power-supply-status

Example

> show power-supply-status

process-tree

Displays processes currently running on the device, sorted in tree format by type.

Access

Basic

Syntax

show process-tree

Example

> show process-tree

processes

Displays processes currently running on the device, sorted by descending CPU usage.

Access

Basic

Syntax

show processes [sort-flag] [filter]

where sort-flag can be -m to sort by memory (descending order), -u to sort by username rather than the process name, or verbose to display the full name and path of the command. The filter parameter specifies the search term in the command or username by which results are filtered. The header row is still displayed.

Example

> show processes -u user1

route

Displays the routing information for an ASA FirePOWER module.

Access

Basic

Syntax

show route

Example

> show route

routing-table

If no parameters are specified, displays routing information for all virtual routers. If parameters are specified, displays routing information for the specified router and, as applicable, its specified routing protocol type. All parameters are optional. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show routing-table [name] [ ospf | rip | static ]

where name is the name of the specific router for which you want information, and ospf, rip, and static specify the routing protocol type.

Example

> show routing-table Vrouter1 static

serial-number

Displays the chassis serial number. This command is not available on virtual devices.

Access

Basic

Syntax

show serial-number

Example

> show serial-number

ssl-policy-config

Displays the currently applied SSL policy configuration, including policy description, default logging settings, all enabled SSL rules and rule configurations, trusted CA certificates, and undecryptable traffic actions.

Access

Basic

Syntax

show ssl-policy-config

Example

> show ssl-policy-config

stacking

Shows the stacking configuration and position on managed devices; on devices configured as primary, also lists data for all secondary devices. For clustered stacks, this command also indicates that the stack is a member of a cluster. The user must use the web interface to enable or (in most cases) disable stacking; if stacking is not enabled, the command will return Stacking not currently configured. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show stacking

Example

> show stacking

summary

Displays a summary of the most commonly used information (version, type, UUID, and so on) about the device. For more detailed information, see the following show commands: version, interfaces, device-settings, and access-control-config.

Access

Basic

Syntax

show summary

Example

> show summary

time

Displays the current date and time in UTC and in the local time zone configured for the current user.

Access

Basic

Syntax

show time

Example

> show time

traffic-statistics

If no parameters are specified, displays details about bytes transmitted and received from all ports. If a port is specified, displays that information only for the specified port. You cannot specify a port for ASA FirePOWER devices, and the system displays only the data plane interfaces.

Access

Basic

Syntax

show traffic-statistics [port]

where port is the specific port for which you want information.

Example

> show traffic-statistics s1p1

user

Applicable to virtual devices only. Displays detailed configuration information for the specified user(s). The following values are displayed:

- Login — the login name

- UID — the numeric user ID

- Auth ( Local or Remote ) — how the user is authenticated

- Access ( Basic or Config ) — the user's privilege level

- Enabled ( Enabled or Disabled ) — whether the user is active

- Reset ( Yes or No ) — whether the user must change password at next login

- Exp ( Never or a number) — the number of days until the user's password must be changed

- Warn ( N/A or a number) — the number of days a user is given to change their password before it expires

- Str ( Yes or No ) — whether the user's password must meet strength checking criteria

- Lock ( Yes or No ) — whether the user's account has been locked due to too many login failures

- Max ( N/A or a number) — the maximum number of failed logins before the user's account is locked

Access

Configuration

Syntax

show user username username username ...

where username specifies the name of the user and the usernames are space-separated.

Example

> show user jdoe

users

Applicable to virtual devices only. Displays detailed configuration information for all local users. The following values are displayed:

- Login — the login name

- UID — the numeric user ID

- Auth ( Local or Remote ) — how the user is authenticated

- Access ( Basic or Config ) — the user's privilege level

- Enabled ( Enabled or Disabled ) — whether the user is active

- Reset ( Yes or No ) — whether the user must change password at next login

- Exp ( Never or a number) — the number of days until the user's password must be changed

- Warn ( N/A or a number) — the number of days a user is given to change their password before it expires

- Str ( Yes or No ) — whether the user's password must meet strength checking criteria

- Lock ( Yes or No ) — whether the user's account is locked due to too many login failures

- Max ( N/A or a number) — the maximum number of failed logins before the user's account is locked

Access

Configuration

Syntax

show users

Example

> show users

version

Displays the product version and build. If the detail parameter is specified, displays the versions of additional components.

Access

Basic

Syntax

show version [detail]

Example

> show version

virtual-routers

If no parameters are specified, displays a list of all currently configured virtual routers with DHCP relay, OSPF, and RIP information. If parameters are specified, displays information for the specified router, limited by the specified route type. All parameters are optional. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show virtual-routers [ dhcprelay | ospf | rip ] [name]

where dhcprelay, ospf, and rip specify for route types, and name is the name of the specific router for which you want information. If you specify ospf, you can then further specify neighbors, topology, or lsadb between the route type and (if present) the router name.

Example

> show virtual-routers ospf VRouter2

virtual-switches

If no parameters are specified, displays a list of all currently configured virtual switches. If parameters are specified, displays information for the specified switch. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

Syntax

show virtual-switches [name]

Example

> show virtual-switches Vswitch1

vmware-tools

Indicates whether VMware Tools are currently enabled on a virtual device. This command is available only on virtual devices.

VMware Tools is a suite of utilities intended to enhance the performance of the virtual machine. These utilities allow you to make full use of the convenient features of VMware products. The system supports the following plugins on all virtual appliances:

- guestInfo

- powerOps

- snapshot

- timeSync

- vmbackup

For more information about VMware Tools and the supported plugins, see the VMware website (http://www.vmware.com).

Access

Basic

Syntax

show vmware-tools

Example

> show vmware-tools

VPN

The show VPN commands display VPN status and configuration information for VPN connections. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Basic

config

Displays the configuration of all VPN connections.

Syntax

show vpn config

Example

> show vpn config

config by virtual router

Displays the configuration of all VPN connections for a virtual router.

Syntax

show vpn config [virtual router]

Example

> show vpn config VRouter1

status

Displays the status of all VPN connections.

Syntax

show vpn status

Example

> show vpn status

status by virtual router

Displays the status of all VPN connections for a virtual router.

Syntax

show vpn status [virtual router]

Example

> show vpn status VRouter1

counters

Displays the counters for all VPN connections.

Syntax

show vpn counters

Example

> show vpn counters

counters by virtual router

Displays the counters of all VPN connections for a virtual router.

Syntax

show vpn counters [virtual router]

Example

> show vpn counters VRouter1

Configuration Commands

The configuration commands enable the user to configure and manage the system. These commands affect system operation; therefore, with the exception of Basic-level configure password, only users with configuration CLI access can issue these commands.

The following sections describe the configuration commands:

- clustering

- bypass

- gui

- iab

- lcd

- log-ips-connections

- manager

- mpls-depth

- network

- password

- stacking disable

- user

- vmware-tools

clustering

Disables or configures bypass for clustering on the device. This command is not available on virtual devices, ASA FirePOWER devices, or on devices configured as secondary stack members.

Access

Configuration

Syntax

configure clustering {disable | bypass}

Example

> configure clustering disable

bypass

On Series 3 devices, places an inline pair in fail-open (hardware bypass) or fail-close mode. You can use this command only when the Bypass Mode inline set option is set to Bypass.

Caution You cannot apply an access control policy or reapply an intrusion policy to a managed device where this command has put an inline set into fail-open mode.

Note that rebooting a device takes an interface pair out of fail-open made.

Access

Configuration

Syntax

configure bypass {open | close} {interface}

where interface is the name of either hardware port in the inline pair.

Example

> configure bypass open s1p1

gui

Enables or disables the device web interface, including the streamlined upgrade web interface that appears during major updates to the system. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Configuration

Syntax

configure gui {enable | disable}

Example

> configure gui disable

iab

Configure Intelligent Application Bypass (IAB). This command requires Version 5.4.0.10 or later on the managed device. The Defense Center requires Version 5.4.1.9 or later to implement IAB functionality, and Version 5.4.1.10 or later to provide IAB events.

IAB trusts traffic to traverse your network without further inspection if performance and flow thresholds are exceeded. The system implements IAB on traffic allowed by access control rules or the access control policy's default action, before the traffic is subject to deep inspection. A test mode allows you to determine whether thresholds are exceeded and, if so, to identify the flows that would have been trusted if you had actually enabled IAB. You must deploy your access control policy to the managed device after configuring IAB.

Parameter

Description

on

Configures IAB in active mode.

test

Configures IAB in test mode.

disable

Disables IAB.

Performance and Flow Thresholds

You must set a performance scan interval and configure at least one of four inspection performance thresholds and one of four flow bypass thresholds. When a performance threshold is exceeded, the system examines flow thresholds and, if a flow threshold is exceeded, trusts traffic. If you configure more than one of either type of threshold, only one of each must be exceeded. All thresholds are disabled (set to 0) by default.

Inspection performance thresholds—provide intrusion inspection performance limits that, if exceeded, trigger the inspection of flow thresholds. IAB does not use inspection performance thresholds set to 0.

Table D-2 Inspection Performance Threshold Parameters

Parameter

Descriptive Name

Description

Range

interval

Performance Sample Interval

The time between IAB performance sampling scans, during which the system collects system performance metrics for comparison to IAB performance thresholds.

1 - 1000 seconds

drops

Drop Percentage

Average packets dropped as a percentage of total packets, when packets are dropped because of performance overloads caused by expensive intrusion rules, file policies, decompression, and so on. This does not refer to packets dropped by normal configurations such as intrusion rules. Note that specifying an integer greater than 1 activates IAB when the specified percentage of packets is dropped. When you specify 1, any percentage from 0 through 1 activates IAB. This allows a small number of packets to activate IAB.

0 - 100 percent

cpu

Processor Utilization Percentage

Average percentage of processor resources used.

0 - 100 percent

latency

Packet Latency

Average packet latency.

0 - 1000000 microseconds

rate

Flow Rate

The rate at which the system processes flows, measured as the number of flows per second. Note that this option configures IAB to measure flow rate, not flow count.

0 - 1000000 flows/second

Flow bypass thresholds—provide flow limits that, if exceeded, trigger IAB to trust traffic in active mode or allow traffic subject to further inspection in test mode. IAB does not use flow bypass thresholds set to 0.

Table D-3 Flow Bypass Threshold Parameters

Parameter

Descriptive Name

Description

Range

kbytes

Bytes per Flow

The maximum number of kilobytes a flow can include.

0 - 2147483647 kilobytes

packets

Packets per Flow

The maximum number of packets a flow can include.

0 - 2147483647 packets

duration

Flow Duration

The maximum number of seconds a flow can remain open.

0 - 2147483647 seconds

velocity

Flow Velocity

The maximum transfer rate in kilobytes per second.

0 - 2147483647 kilobytes/second

You configure all parameters at the same time and in order. The system prompts you for the next parameter if you enter fewer than the maximum number of parameters.

Access

Configuration

Syntax

configure iab {on | test} interval drops cpu latency rate kbytes packets duration velocity

Example

configure iab on 5 1 95 250 0 500000 0 0 25000

Related Command

show iab

lcd

Enables or disables the LCD display on the front of the device. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Configuration

Syntax

configure lcd {enable | disable}

Example

> configure lcd disable

log-ips-connections

Enables or disables logging of connection events that are associated with logged intrusion events.

Access

Configuration

Syntax

configure log-ips-connections {enable | disable}

Example

> configure log-ips-connections disable

manager

The configure manager commands configure the device’s connection to its managing Defense Center.

Access

Configuration

add

Configures the device to accept a connection from a managing Defense Center. This command works only if the device is not actively managed.

A unique alphanumeric registration key is always required to register a device to a Defense Center. In most cases, you must provide the hostname or the IP address along with the registration key. However, if the device and the Defense Center are separated by a NAT device, you must enter a unique NAT ID, along with the registration key, and specify DONTRESOLVE instead of the hostname.

Syntax

configure manager add {hostname | IPv4_address | IPv6_address | DONTRESOLVE} regkey [nat_id]

where {hostname | IPv4_address | IPv6_address | DONTRESOLVE} specifies the DNS host name or IP address (IPv4 or IPv6) of the Defense Center that manages this device. If the Defense Center is not directly addressable, use DONTRESOLVE. If you use DONTRESOLVE,nat_id is required. regkey is the unique alphanumeric registration key required to register a device to the Defense Center. nat_id is an optional alphanumeric string used during the registration process between the Defense Center and the device. It is required if the hostname is set to DONTRESOLVE.

Example

> configure manager add DONTRESOLVE abc123 efg456

delete

Removes the Defense Center’s connection information from the device. This command only works if the device is not actively managed.

Syntax

configure manager delete

Example

> configure manager delete

mpls-depth

Configures the number of MPLS layers on the management interface. This command is not available on virtual devices and ASA FirePOWER devices.

Access

Configuration

Syntax

configure mpls-depth {depth}

where depth is a number between 0 and 6.

Example

> configure mpls-depth 3

network

The configure network commands configure the device’s management interface.

Access

Configuration

dns searchdomains

Replaces the current list of DNS search domains with the list specified in the command.

Syntax

configure network dns searchdomains {searchlist}

where searchlist is a comma-separated list of domains.

Example

> configure network dns searchdomains foo.bar.com,bar.com

dns servers

Replaces the current list of DNS servers with the list specified in the command.

Syntax

configure nework dns servers {dnslist}

where dnslist is a comma-separated list of DNS servers.

Example

> configure network dns servers 10.123.1.10,10.124.1.10

hostname

Sets the hostname for the device.

Syntax

configure network hostname {name}

where name is the new hostname.

Example

> configure network hostname sfrocks

http-proxy

On Series 3 and virtual devices, configures an HTTP proxy. After issuing the command, the CLI prompts the user for the HTTP proxy address and port, whether proxy authentication is required, and if it is required, the proxy username, proxy password, and confirmation of the proxy password.

Use this command on a virtual device to configure an HTTP proxy server so the virtual device can submit files to the Collective Security Intelligence Cloud for dynamic analysis.

Syntax

configure network http-proxy

Example

> configure network http-proxy

Manual proxy configuration

Enter HTTP Proxy address:

Enter HTTP Proxy Port:

Use Proxy Authentication? (y/n) [n]:

Enter Proxy Username:

Enter Proxy Password:

Confirm Proxy Password:

http-proxy-disable

On Series 3 and virtual devices, deletes any HTTP proxy configuration.

Syntax

configure network http-proxy-disable

Example

> configure network http-proxy-disable

Are you sure that you wish to delete the current http-proxy configuration? (y/n):

ipv4 delete

Disables the IPv4 configuration of the device’s management interface.

Syntax

configure network ipv4 delete

Example

> configure network ipv4 delete

ipv4 dhcp

Sets the IPv4 configuration of the device’s management interface to DHCP. The management interface communicates with the DHCP server to obtain its configuration information.

Syntax

configure network ipv4 dhcp

Example

> configure network ipv4 dhcp

ipv4 manual

Manually configures the IPv4 configuration of the device’s management interface.

Syntax

configure network ipv4 manual ipaddr netmask gw

where ipaddr is the IP address, netmask is the subnet mask, and gw is the IPv4 address of the default gateway.

Example

> configure network ipv4 manual 10.123.1.10 255.255.0.0 10.123.1.1

ipv6 delete

Disables the IPv6 configuration of the device’s management interface.

Syntax

configure network ipv6 delete

Example

> configure network ipv6 delete

ipv6 dhcp

Sets the IPv6 configuration of the device’s management interface to DHCP. The management interface communicates with the DHCP server to obtain its configuration information.

Syntax

configure network ipv6 dhcp

Example

> configure network ipv6 dhcp

ipv6 router

Sets the IPv6 configuration of the device’s management interface to Router. The management interface communicates with the IPv6 router to obtain its configuration information.

Syntax

configure network ipv6 router

Example

> configure network ipv6 router

ipv6 manual

Manually configures the IPv6 configuration of the device’s management interface.

Syntax

configure network ipv6 manual ip6addr/ip6prefix [ip6gw]

where ip6addr/ip6prefix is the IP address and prefix length and ip6gw is the IPv6 address of the default gateway.

Example

> configure network ipv6 manual 2001:DB8:3ffe:1900:4545:3:200:f8ff:fe21:67cf 64

management-interface disable

Disables the specified management interface.

Syntax

configure network management-interface disable ethn

where n is the number of the management interface you want to disable.

Example

> configure network management-interface disable eth1

management-interface disable-event-channel

Disables event transmission over the specified management interface.

Syntax

configure network management-interface disable-event-channel ethn

where n is the number of the management interface you want to disable.

Example

> configure network management-interface disable-event-channel eth1

management-interface disable-management-channel

Disables management transmission over the specified management interface.

Syntax

configure network management-interface disable-management-channel ethn

where n is the number of the management interface you want to disable.

Example

> configure network management-interface disable-management-channel eth1

management-interface enable

Enables the specified management interface.

Syntax

configure network management-interface enable ethn

where n is the number of the management interface you want to enable.

Example

> configure network management-interface enable eth1

management-interface enable-event-channel

Enables event transmission over the specified management interface.

Syntax

configure network management-interface enable-event-channel ethn

where n is the number of the management interface you want to enable.

Example

> configure network management-interface enable-event-channel eth1

management-interface enable-management-channel

Enables management transmission over the specified management interface.

Syntax

configure network management-interface enable-management-channel ethn

where n is the number of the management interface you want to enable.

Example

> configure network management-interface enable-management-channel eth1

management-interface tcpport

Changes the value of the TCP port for management.

Syntax

configure network management-interface tcpport port

where port is the management port value you want to configure.

Example

> configure network management-interface tcpport 8500

management-port

Sets the value of the device’s TCP management port.

Syntax

configure network management-port number

where number is the management port value you want to configure.

Example

> configure network management-port 8500

static-routes ipv4 add

Adds an IPv4 static route for the specified management interface.

Syntax

configure network static-routes ipv4 add interface destination netmask gateway

where interface is the management interface, destination is the destination IP address, netmask is the network mask address, and gateway is the gateway address you want to add.

Example

> configure network static-routes ipv4 add eth1 10.115.24.0 255.255.255.0 10.115.9.2

static-routes ipv4 delete

Deletes an IPv4 static route for the specified management interface.

Syntax

configure network static-routes ipv4 delete interface destination netmask gateway

where interface is the management interface, destination is the destination IP address, netmask is the network mask address, and gateway is the gateway address you want to delete.

Example

> configure network static-routes ipv4 delete eth1 10.115.24.0 255.255.255.0 10.115.9.2

static-routes ipv6 add

Adds an IPv6 static route for the specified management interface.

Syntax

configure network static-routes ipv6 add interface destination prefix gateway

where interface is the management interface, destination is the destination IP address, prefix is the IPv6 prefix length, and gateway is the gateway address you want to add.

Example

> configure network static-routes ipv6 add eth1 2001:DB8:3ffe:1900:4545:3:200: f8ff:fe21:67cf 64

static-routes ipv6 delete

Deletes an IPv6 static route for the specified management interface.

Syntax

configure network static-routes ipv6 delete interface destination prefix gateway

where interface is the management interface, destination is the destination IP address, prefix is the IPv6 prefix length, and gateway is the gateway address you want to delete.

Example

> configure network static-routes ipv6 delete eth1 2001:DB8:3ffe:1900:4545:3:200:f8ff: fe21:67cf 64

password

Allows the current user to change their password. After issuing the command, the CLI prompts the user for their current (or old) password, then prompts the user to enter the new password twice.

Access

Basic

Syntax

configure password

Example

> configure password

Enter current password:

Enter new password:

Confirm new password:

stacking disable

On managed devices, removes any stacking configuration present on that device: on devices configured as primary, the stack is removed entirely; on devices configured as secondary, that device is removed from the stack. This command is not available on virtual devices or ASA FirePOWER devices and you cannot use it to break a clustered stack.

Use this command when you cannot establish communication with appliances higher in the stacking hierarchy. If the Defense Center is available for communication, a message appears instructing you to use the Defense Center web interface instead; likewise, if you enter stacking disable on a device configured as secondary when the primary device is available, a message appears instructing you to enter the command from the primary device.

Access

Configuration

Syntax

configure stacking disable

Example

> configure stacking disable

user

Applicable only to virtual devices, the configure user commands manage the device’s local user database.

Access

Configuration

Access

Modifies the access level of the specified user. This command takes effect the next time the specified user logs in.

Syntax

configure user access username [basic | config]

Example

> configure user access jdoe basic

where username specifies the name of the user for which you want to modify access, basic indicates basic access, and config indicates configuration access.

add

Creates a new user with the specified name and access level. This command prompts for the user’s password.

Syntax

configure user add username [basic | config]

where username specifies the name of the new user, basic indicates basic access, and config indicates configuration access.

Example

> configure user add jdoe basic

Enter new password for user jdoe:

Confirm new password for user jdoe:

aging

Forces the expiration of the user’s password.

Syntax

configure user aging username max_days warn_days

where username specifies the name of the user, max_days indicates the maximum number of days that the password is valid, and warn_days indicates the number of days that the user is given to change the password before it expires.

Example

> configure user aging jdoe 100 3

delete

Deletes the user and the user’s home directory.

Syntax

configure user delete username

where username specifies the name of the user.

Example

> configure user delete jdoe

disable

Disables the user. Disabled users cannot login.

Syntax

configure user disable username

where username specifies the name of the user.

Example

> configure user disable jdoe

enable

Enables the user.

Syntax

configure user enable username

where username specifies the name of the user.

Example

> configure user enable jdoe

forcereset

Forces the user to change their password the next time they login. When the user logs in and changes the password, strength checking is automatically enabled.

Syntax

configure user forcereset username

where username specifies the name of the user.

Example

> configure user forcereset jdoe

maxfailedlogins

Sets the maximum number of failed logins for the specified user.

Syntax

configure user maxfailedlogins username number

where username specifies the name of the user and number specifies the maximum number of failed logins.

Example

> configure user maxfailedlogins jdoe 3

password

Sets the user’s password. This command prompts for the user’s password.

Syntax

configure user password username

where username specifies the name of the user.

Example

> configure user pasword jdoe

Enter new password for user jdoe:

Confirm new password for user jdoe:

strengthcheck

Enables or disables the strength requirement for a user’s password. When a user’s password expires or if the configure user forcereset command is used, this requirement is automatically enabled the next time the user logs in.

Syntax

configure user strengthcheck username {enable | disable}

where username specifies the name of the user, enable sets the requirement for the specified users password, and disable removes the requirement for the specified user’s password.

Example

> configure user strengthcheck jdoe enable

unlock

Unlocks a user that has exceeded the maximum number of failed logins.

Syntax

configure user unlock username

where username specifies the name of the user.

Example

> configure user unlock jdoe

vmware-tools

Enables or disables VMware Tools functionality on a virtual device. This command is available only on virtual devices.

VMware Tools is a suite of utilities intended to enhance the performance of the virtual machine. These utilities allow you to make full use of the convenient features of VMware products. The system supports the following plugins on all virtual appliances:

- guestInfo

- powerOps

- snapshot

- timeSync

- vmbackup

For more information about VMware Tools and the supported plugins, see the VMware website (http://www.vmware.com).

Access

Basic

Syntax

configure vmware-tools (enable | disable)

Example

> configure vmware-tools enable

System Commands

The system commands enable the user to manage system-wide files and access control settings. Only users with configuration CLI access can issue commands in system mode.

The following sections describe the system commands:

- access-control

- disable-http-user-cert

- file

- generate-troubleshoot

- ldapsearch

- lockdown-sensor

- nat rollback

- reboot

- restart

- shutdown

access-control

The system access-control commands enable the user to manage the access control configuration on the device.

Access

Configuration

archive

Saves the currently applied access control policy as a text file on /var/common.

Syntax

system access-control archive

Example

> system access-control archive

clear-rule-counts

Resets the access control rule hit count to 0.

Syntax

system access-control clear-rule-counts

Example

> system access-control clear-rule-counts

rollback

Reverts the system to the previously applied access control configuration. You cannot use this command with clustered or stacked devices.

Syntax

system access-control rollback

Example

> system access-control rollback

disable-http-user-cert

Removes all HTTP user certification present on the system.

Access

Configuration

Syntax

system disable-http-user-cert

Example

> system disable-http-user-cert

file

The system file commands enable the user to manage the files in the common directory on the device.

Access

Configuration

copy

Uses FTP to transfer files to a remote location on the host using the login username. The local files must be located in the common directory.

Syntax

system file copy hostname username path filenames filenames ...

where hostname specifies the name or ip address of the target remote host, username specifies the name of the user on the remote host, path specifies the destination path on the remote host, and filenames specifies the local files to transfer; the file names are space-separated.

Example

> system file copy sfrocks jdoe /pub *

delete

Removes the specified files from the common directory.

Syntax

system file delete filenames filenames ...

where filenames specifies the files to delete; the file names are space-separated.

Example

> system file delete *

list

If no file names are specified, displays the modification time, size, and file name for all the files in the common directory. If file names are specified, displays the modification time, size, and file name for files that match the specified file names.

Syntax

system file list {filenames filenames ...}

where filenames specifies the files to display; the file names are space-separated.

Example

> system file list

secure-copy

Uses SCP to transfer files to a remote location on the host using the login username. The local files must be located in the /var/common directory.

Syntax

system file secure-copy hostname username path filenames filenames ...

where hostname specifies the name or ip address of the target remote host, username specifies the name of the user on the remote host, path specifies the destination path on the remote host, and filenames specifies the local files to transfer; the file names are space-separated.

Example

> system file secure-copy 10.123.31.1 jdoe /tmp *

generate-troubleshoot

Generates troubleshooting data for analysis by Cisco.

Access

Configuration

Syntax

system generate-troubleshoot

This syntax displays a list of optional parameters to specify what troubleshooting data should be displayed.

Example

> system generate-troubleshoot

ldapsearch

Enables the user to perform a query of the specified LDAP server. Note that all parameters are required.

Access

Configuration

Syntax

system ldapsearch host port baseDN userDN basefilter

where host specifies the LDAP server domain, port specifies the LDAP server port, baseDN specifies the DN (distinguished name) that you want to search under, userDN specifies the DN of the user who binds to the LDAP directory, and basefilter specifies the record or records you want to search for.

Example

> system ldapsearch ldap.example.com 389 cn=users,

dc=example,dc=com cn=user1,cn=users,dc=example,dc=com, cn=user2

lockdown-sensor

Removes the expert command and access to the bash shell on the device.

Caution This command is irreversible without a hotfix from Support. Use with care.

Access

Configuration

Syntax

system lockdown-sensor

Example

> system lockdown-sensor

nat rollback

Reverts the system to the previously applied NAT configuration. This command is not available on virtual devices and ASA FirePOWER devices. You cannot use this command with clustered or stacked devices.

Access

Configuration

Syntax

system nat rollback

Example

> system nat rollback

reboot

Reboots the device.

Access

Configuration

Syntax

system reboot

Example

> system reboot

restart

Restarts the device application.

Access

Configuration

Syntax

system restart

Example

> system restart

shutdown

Shuts down the device. This command is not available on ASA FirePOWER modules.

Access

Configuration

Syntax

system shutdown

Example

> system shutdown

Security, Internet Access, and Communication Ports

To safeguard the Defense Center, you should install it on a protected internal network. Although the Defense Center is configured to have only the necessary services and ports available, you must make sure that attacks cannot reach it (or any managed devices) from outside the firewall.

If the Defense Center and its managed devices reside on the same network, you can connect the management interfaces on the devices to the same protected internal network as the Defense Center. This allows you to securely control the devices from the Defense Center. You can also configure multiple management interfaces to allow the Defense Center to manage and isolate traffic from devices on other networks.

Regardless of how you deploy your appliances, intra-appliance communication is encrypted. However, you must still take steps to ensure that communications between FireSIGHT System appliances cannot be interrupted, blocked, or tampered with; for example, with a distributed denial of service (DDoS) or man-in-the-middle attack.

Also note that specific features of the FireSIGHT System require an Internet connection. By default, all FireSIGHT System appliances are configured to directly connect to the Internet. Additionally, the system requires certain ports remain open for basic intra-appliance communication, for secure appliance access, and so that specific system features can access the local or Internet resources they need to operate correctly.

Tip With the exception of Cisco NGIPS for Blue Coat X-Series, FireSIGHT System appliances support the use of a proxy server. For more information, see Configuring Management Interfaces and http-proxy.

For more information, see:

- Internet Access Requirements

- Communication Ports Requirements

Internet Access Requirements

By default, FireSIGHT System appliances are configured to directly connect to the Internet on ports 443/tcp (HTTPS) and 80/tcp (HTTP), which are open by default on all FireSIGHT System appliances; see Communication Ports Requirements. Note that most FireSIGHT System appliances support use of a proxy server; see Configuring Management Interfaces. Note also that a proxy server cannot be used for whois access.

To ensure continuity of operations, both Defense Centers in a high availability pair must have Internet access. For specific features, the primary Defense Center contacts the Internet, then shares information with the secondary during the synchronization process. Therefore, if the primary fails, you should promote the secondary to Active as described in Monitoring and Changing High Availability Status.

The following table describes the Internet access requirements of specific features of the FireSIGHT System.

Table E-1 FireSIGHT System Feature Internet Access Requirements

Feature

Internet access is required to...

Appliances

High Availability Considerations

dynamic analysis: querying

Defense Center

Paired Defense Centers query the cloud for threat scores independently.

dynamic analysis: submitting

submit files to the cloud for dynamic analysis.

Any device except Series 2 and X-Series

n/a

FireAMP integration

receive endpoint-based (FireAMP) malware events from the Cisco cloud.

Defense Center

Cloud connections are not synchronized. Configure them on both Defense Centers.

intrusion rule, VDB, and GeoDB updates

download or schedule the download of a intrusion rule, GeoDB, or VDB update directly to an appliance.

Defense Center

Intrusion rule, GeoDB, and VDB updates are synchronized.

network-based AMP

perform malware cloud lookups.

Defense Center

Paired Defense Centers perform cloud lookups independently.

RSS feed dashboard widget

download RSS feed data from an external source, including Cisco.

Any except virtual devices and X-Series

Feed data is not synchronized.

Security Intelligence filtering

download Security Intelligence feed data from an external source, including the Intelligence Feed.

Defense Center

The primary Defense Center downloads feed data and shares it with the secondary. In case of primary failure, promote the secondary to active.

system software updates

download or schedule the download of a system update directly to an appliance.

Any except virtual devices and X-Series

System updates are not synchronized.

URL filtering

download cloud-based URL category and reputation data for access control, and perform lookups for uncategorized URLs.

Defense Center

The primary Defense Center downloads URL filtering data and shares it with the secondary. In case of primary failure, promote the secondary to active.

whois

request whois information for an external host.

Any except virtual devices and X-Series

Any appliance requesting whois information must have Internet access.

Communication Ports Requirements

FireSIGHT System appliances communicate using a two-way, SSL-encrypted communication channel, which by default uses port 8305/tcp. The system requires this port remain open for basic intra-appliance communication. Other open ports allow:

- access to an appliance’s web interface

- secure remote connections to an appliance

- certain features of the system to access the local or Internet resources they need to function correctly

In general, feature-related ports remain closed until you enable or configure the associated feature. For example, until you connect the Defense Center to a User Agent, the agent communications port (3306/tcp) remains closed. As another example, port 623/udp remains closed on Series 3 appliances until you enable LOM.

Caution Do not close an open port until you understand how this action will affect your deployment.

For example, closing port 25/tcp (SMTP) outbound on a manage device blocks the device from sending email notifications for individual intrusion events (see Configuring External Alerting for Intrusion Rules). As another example, you can disable access to a physical managed device’s web interface by closing port 443/tcp (HTTPS), but this also prevents the device from submitting suspected malware files to the cloud for dynamic analysis.

Note that the system allows you to change some of its communication ports:

- You can specify custom ports for LDAP and RADIUS authentication when you configure a connection between the system and the authentication server; see Identifying the LDAP Authentication Server and Configuring RADIUS Connection Settings.

- You can change the management port (8305/tcp); see Configuring Management Interfaces. However, Cisco strongly recommends that you keep the default setting. If you change the management port, you must change it for all appliances in your deployment that need to communicate with each other.

- You can use port 32137/tcp to allow upgraded Defense Centers to communicate with the Cisco cloud. However, Cisco recommends you switch to port 443, which is the default for fresh installations of Version 5.3 and later. For more information, see Enabling Cloud Communications.

Port

Description

Direction

Is Open on...

To...

22/tcp

SSH/SSL

Bidirectional

Any

allow a secure remote connection to the appliance.

25/tcp

SMTP

Outbound

Any

send email notices and alerts from the appliance.

53/tcp

DNS

Outbound

Any

use DNS.

67/udp

68/udp

DHCP

Outbound

Any except X-Series

use DHCP.

by default.

80/tcp

HTTP

Outbound

Any except virtual devices and X-Series

Bidirectional

Defense Center

update custom and third-party Security Intelligence feeds via HTTP.

download URL category and reputation data (port 443 also required).

161/udp

SNMP

Bidirectional

Any except X-Series

allow access to an appliance’s MIBs via SNMP polling.

162/udp

SNMP

Outbound

Any

send SNMP alerts to a remote trap server.

389/tcp

636/tcp

LDAP

Outbound

Any except virtual devices and X-Series

communicate with an LDAP server for external authentication.

389/tcp

636/tcp

LDAP

Outbound

Defense Center

obtain metadata for detected LDAP users.

443/tcp

HTTPS

Inbound

Any except virtual devices and X-Series

access an appliance’s web interface.

443/tcp

HTTPS

AMQP

cloud comms.

Bidirectional

Defense Center

obtain:

- software, intrusion rule, VDB, and GeoDB updates

- URL category and reputation data (port 80 also required)

- the Intelligence Feed and other secure Security Intelligence feeds

- endpoint-based (FireAMP) malware events

- malware dispositions for files detected in network traffic

- dynamic analysis information on submitted files

Series 2 and Series 3 devices

download software updates using the device’s local web interface.

Series 3 and virtual devices

submit files to for dynamic analysis.

514/udp

syslog

Outbound

Any

send alerts to a remote syslog server.

623/udp

SOL/LOM

Bidirectional

Series 3

allow you to perform Lights-Out Management using a Serial Over LAN (SOL) connection.

1500/tcp

2000/tcp

database access

Inbound

Defense Center

allow read-only access to the database by a third-party client.

1812/udp

1813/udp

RADIUS

Bidirectional

Any except virtual devices and X-Series

communicate with a RADIUS server for external authentication and accounting.

3306/tcp

User Agent

Inbound

Defense Center

communicate with User Agents.

8302/tcp

eStreamer

Bidirectional

Any except virtual devices and X-Series

communicate with an eStreamer client.

8305/tcp

appliance comms.

Bidirectional

Any

securely communicate between appliances in a deployment. Required.

8307/tcp

host input client

Bidirectional

Defense Center

communicate with a host input client.

32137/tcp

cloud comms.

Bidirectional

Defense Center

Third-Party Products

Table F-1 Open Source Software Licensing

Open Source Software

License Agreement

Apache HTTPD Web Server 2.4.3

Apache License

Linux Kernel 2.6.32.24 (Series 2)

GNU General Public License Version 2 (GPLv2)

Linux Kernel 2.6.35.14 (Series 3)

GNU General Public License Version 2 (GPLv2)

Perl 5.10.1 and related modules

Perl Artistic License

Snort 2.9.7

GNU General Public License Version 2 (GPLv2)

A complete list of all third-party open source code products and the full text of all applicable license agreements that are distributed with the FireSIGHT System products can be obtained by logging into the product command line and viewing the following:

/usr/share/license-files

If you would like to receive the source code to any of the third-party open source code products used in combination with the FireSIGHT System products, you may do so by submitting a request to the Support Site.

Glossary

7000 Series

A group of Series 3 managed devices. The devices in this series include the 70xx Family (the 3D7010/7020/7030/7050 models) and the 71xx Family (3D7110/7120/3D7115/3D7125 and AMP7150 models).

8000 Series

A group of Series 3 managed devices. The devices in this series include the 81xx Family (the 3D8120/8130/8140 and AMP8150 models), the 82xx Family (the 3D8250/8260/8270/8290 models), the 83xx Family (the 3D8350/8360/8370/8390 models), and the AMP83xx Family (the AMP8350/AMP8360/AMP8370/AMP8390 models). 8000 Series devices are generally more powerful than 7000 Series devices.

access control

A feature of the FireSIGHT System that allows you to specify, inspect, and log the traffic that traverses your network. Access control invokes Security Intelligence, SSL inspection, preprocessor options, intrusion detection and prevention, file control, and advanced malware protection. It also determines the traffic you can inspect with discovery.

access control policy

A policy that you apply to managed devices to perform access control on the network traffic monitored by those devices. An access control policy may include multiple access control rules; it also specifies a default action, which determines the handling and logging of traffic that does not meet the criteria of any of those rules. Other settings in the access control policy govern Security Intelligence, SSL inspection, performance options, preprocessor options, and other advanced configurations.

access control rule

A set of conditions the FireSIGHT System uses to examine your monitored network traffic and achieve granular access control. Access control rules, which populate an access control policy, may perform simple IP address matching, or may characterize complex connections involving many different criteria. The access control rule action determines how the system handles traffic that meets the rule’s conditions. Other rule settings determine how (and whether) the connection is logged, and whether an intrusion policy or file policy inspects traffic allowed by the rule.

access control rule action

A setting that determines how the system handles network traffic that meets the conditions of an access control rule. You can block matching traffic (with or without resetting the connection); for HTTP traffic you can provide users with the option to bypass the block. You can also trust traffic to pass without further inspection, allow matching traffic, which optionally can be inspected with an intrusion policy and file policy, or continue to monitor the traffic with additional access control rules.

access-controlled user

A user whose network use you can control using access control. You specify the LDAP groups that access-controlled users must belong to when you configure a connection between a Microsoft Active Directory server and the Defense Center. When the User Agent reports logins by access-controlled users, those users are associated with IP addresses, which in turn allows access control rules with user conditions to trigger. Compare with non-access-controlled user.

access list

A list of IP addresses, configured in the system policy, that represents the hosts that can access an appliance. By default, anyone can access the web interface of an appliance using port 443 (HTTPS), as well as the command line using port 22 (SSH). You can also add SNMP access using port 161.

action

A setting that determines how the system handles, inspects, or logs network traffic that meets (or does not meet) certain criteria. Actions are associated with various types of rule, as well as with certain policies as the policy’s default action.

active detection

The discovery of host, application, and user information using active sources. Active sources include scanners such as Nmap, user input to the system’s web interface, or host input to the network map using the command line or third-party application API calls. Compare with passive detection.

adaptive profile

Recommended for passive deployments, an advanced access control policy setting that uses discovery data to determine the operating system for the target host of a packet. Targeted profiles within network analysis policies then defragment IP packets and reassemble streams in the same way as the operating system on the target host. Intrusion policies then analyze the data in the same format as that used by the destination host.

advanced malware protection

Abbreviated AMP, the FireSIGHT System’s network-based malware detection and malware blocking feature. Compare this functionality with FireAMP, Cisco’s endpoint-based AMP tool that requires a FireAMP subscription.

alert

A notification that the system has generated a specific event. You can alert based on intrusion events (including their impacts), discovery events, network-based malware events, correlation policy violations, health status changes, and logged connections. In most cases, you can alert via email, syslog, or SNMP trap.

alert response

A set of configurations that allows the system to send an alert via email, syslog, or SNMP trap. You can use a single alert response to alert you to multiple types of events.

appliance

A FireSIGHT System Defense Center, managed device, Cisco ASA with FirePOWER Services, or Cisco NGIPS for Blue Coat X-Series. An appliance can be physical or software-based.

appliance statistics

Information you can obtain about an appliance, including uptime, system memory usage, load average, disk usage, a summary of system processes, and, on the Defense Center, information about data correlator processes.

application

A detected network asset, communications method, or HTTP content. The system detects three types of application: application protocol, client application, and web application.

application business relevance

See business relevance.

application category

A general classification for an application that describes its most essential function. Each application belongs to at least one category.

application control

A feature that, as part of access control, allows you to specify which application traffic can traverse your network.

application detector

A tool that the system uses to identify applications on your network. Application detectors identify applications using ASCII or hexadecimal patterns in the packet headers, the port that the traffic uses, or both. Cisco may deliver additional detectors via system update, vulnerability database update, or the import/ export feature. You can also create your own application protocol detectors.

application filter

One or more applications grouped according to criteria associated with the application risk, business relevance, type, categories, and tags. You create application filters in the object manager.

application protocol

A type of application that represents application protocol traffic detected during communications between server and client applications on hosts; for example, SSH or HTTP.

application risk

The likelihood that an application’s use may violate your organization’s security policy. An application’s risk can range from very low to very high.

application tag

Information about an application that is not covered by its application category. For example, video streaming web applications often are tagged “high bandwidth” and “displays ads.” An application may have any number of tags, including none.

application type

Whether an application is an application protocol, client application, or web application.

apply

The action you take to have a policy, or changes to that policy, take effect. You apply most policies from the Defense Center to its managed devices; however, you activate and deactivate correlation policies because they do not involve changes to the configuration of managed devices.

ASA FirePOWER

The short name for Cisco ASA with FirePOWER Services.

audit event

An event that describes a specific FireSIGHT System user interaction. Each audit event contains a time stamp, the user name of the user whose action generated the event, a source IP address, and text describing the event. Audit events are recorded in the audit log.

audit log

A record of user interactions with the system. The audit log comprises audit events.

authentication object

A collection of settings that allows you to connect to an external authentication server to enable external authentication (RADIUS or LDAP) to the FireSIGHT System’s web interface.

automatic application bypass (AAB)

An advanced device setting that limits the time allowed to process packets through an interface and allows packets to bypass processing if the time is exceeded.

banner

See server banner.

base policy

An intrusion policy or network analysis policy that serves as the base policy layer for a custom policy.

base policy layer

The lowest, built-in layer in an intrusion policy or network analysis policy. The base policy determines the settings in the base policy layer, and thus the default settings for the policy.

blacklist

See health monitor blacklist or Security Intelligence blacklist.

bookmark

A saved link to a specific location and time in an event analysis. Bookmarks retain information about the workflow you are using, the part of the workflow you are viewing, the page number within the workflow you are viewing, the time window you selected, and any columns you disabled, as well as any constraints you imposed.

built-in layer

A read-only layer in an intrusion policy or network analysis policy. These policies always include a built-in base policy layer; intrusion policies can also include a built-in FireSIGHT Recommendations layer.

business relevance

The likelihood that an application is used within the context of your organization’s business operations, as opposed to recreationally. An application’s business relevance can range from very low to very high.

bypass mode

A characteristic of an inline set that allows traffic to continue flowing if the sensing interfaces in the set fail for any reason.

CA

See certificate authority.

CAC authentication and authorization

A type of LDAP authentication that allows users to log in to the web interface of an appliance using only the credentials provided by a Common Access Card (CAC).

captured file

A file detected in network traffic that a device copies, either for submission to the Collective Security Intelligence Cloud for dynamic analysis or Spero analysis, or for file storage to the device.

category

See application category, file category, or URL category.

certificate

See public key certificate.

certificate authority

The certificate issuer used to create server certificates or user public key certificates. Server and user certificates provide an additional confirmation of a server or a user identity.

certificate revocation list (CRL)

A list of certificates revoked by the certificate authority that issued the user certificates for your appliance. This allows you to restrict access to the FireSIGHT System web interface using client browser certificate checking. If the user selects a certificate that is listed in the CRL as a revoked certificate, the browser cannot load the web interface. During SSL inspection, a device can detect a public key certificate on a CRL and not trust the encrypted traffic.

change reconciliation report

A detailed report of all system changes in the last 24 hours, based on snapshots taken whenever a new configuration is saved. You can configure the system to email these reports daily at a time that you specify.

cipher suite list

A reusable object that represents multiple cipher suites used to encrypt traffic.

Cisco ASA with FirePOWER Services

A group of Cisco Adaptive Security Appliance (ASA) managed devices with an ASA FirePOWER module installed. The devices in this series include the ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5512-X, ASA5515-X, ASA5516-X, ASA5525-X, ASA5545-X, ASA5555-X, ASA5585-X-SSP-10, ASA5585-X-SSP-20, ASA5585-X-SSP-40, and ASA5585-X-SSP-60 models.

Cisco Cloud

See Collective Security Intelligence Cloud.

Cisco NGIPS for Blue Coat X-Series

A software-based application built on Blue Coat’s scalable chassis-based system that provides most of the capabilities of a virtual device.

Cisco VRT

Cisco’s Vulnerability Research Team.

clean list

A list of files as represented by their SHA-256 hash values. When the system detects a file in the list, it does not perform a malware cloud lookup, treating the file as clean, even if the disposition for the file in the Collective Security Intelligence Cloud is Malware.

CLI

See command line interface (CLI).

client

Also called a client application, an application that runs on one host and relies on another host (a server) to perform some operation. For example, email clients allow you to send and receive email. When the system detects that a user on a host is using a specific client to access another host, it reports that information in the host profile and network map, including the name and version (if available) of the client.

client application

See client.

clipboard

A holding area where you can copy up to 25,000 intrusion events that you can later add to incidents.

cloud services

See Collective Security Intelligence Cloud.

clustering

A feature that allows you to achieve redundancy of networking functionality and configuration data between two peer Series 3 devices or stacks. Clustering provides a single logical system for policy applies, system updates, and registration. Compare with high availability, which allows you to configure redundant Defense Centers.

Collective Security Intelligence Cloud

Sometimes called cloud services or the Cisco cloud , a Cisco-hosted server where the Defense Center can obtain up-to-date, relevant information including malware, Security Intelligence, and URL filtering data. See also malware cloud lookup and FireAMP Private Cloud.

command line interface (CLI)

A restricted text-based interface on Series 3 and virtual devices. The commands that CLI users can run depend on the users’ assigned level of access.

Common Access Card (CAC)

A United States Department of Defense-issued identification card used for CAC authentication and authorization.

complex constraint

A constraint set in an event view or event search that constrains an event query using all the criteria from a specific event.

compliance white list

Along with correlation rules, one of the ways you can specify criteria that network traffic must meet in order to violate a correlation policy. You can use the Defense Center to configure compliance white lists to specify which operating systems, applications, and protocols are allowed to run on the hosts in a specific subnet. You can also configure the Defense Center to launch a response, such as an alert or remediation, when a white list is violated. Note that compliance white lists are not associated with the other types of whitelist.

compliance white list event

See white list event.

compliance white list violation

See white list violation.

configurable bypass

A characteristic of an inline set that allows you to configure bypass mode.

configuration, for import or export

A set of configurations, such as a policy or custom workflow, that is created on an appliance and can be exported from that appliance and imported by another appliance.

connection

A monitored session between two hosts. You can log connections detected by FireSIGHT System managed devices as well as import connection data from NetFlow-enabled devices.

connection event

An event generated when the system detects a connection between a monitored host and any other host. Security Intelligence events are a special kind of connection event. Connection events include information about the detected traffic. Various settings give you granular control over which connections you log, when you log them, and where you store the data. For connections detected by managed devices, you can log unblocked connections at their beginning and end, but most blocked connections at their beginning only. You can log these connections to the Defense Center database; depending on the rule or default action, you can also log connection events to an external syslog or SNMP trap server. NetFlow records log the ends of connections and are always saved to the database.

connection graph

A way of displaying connection events in graphical form.

connection log

See connection event.

connection summary

Connection data aggregated over a five-minute interval. The system uses connection summaries to build connection graphs and traffic profiles. To be aggregated, multiple connections must represent the end of connections, have the same source and destination IP addresses, and use the same port on the responder (destination) host. They must use the same protocol (TCP or UDP) and application protocol. Finally, they must either be detected by the same managed device, or be exported by the same NetFlow-enabled device.

connection tracker

One or more conditions that constrain a correlation rule so that after the rule’s initial criteria are met, the system begins tracking certain connections. The rule then triggers only if the tracked connections meet additional criteria.

Context Explorer

A page that displays detailed, interactive graphical information about your monitored network. Distinct sections present information in the form of vivid line, bar, pie, and donut graphs, accompanied by detailed lists. You can easily create and apply custom filters to fine-tune your analysis, and you can examine data sections in more detail by clicking or hovering your cursor over graph areas. Compared with a dashboard, which is highly customizable, compartmentalized, and updates in real time, the Context Explorer is manually updated, designed to provide broader context for its data, and has a single, consistent layout designed for active user exploration.

context menu

A pop-up menu, available on many of the pages in the web interface, that you can use as a shortcut for accessing other features in the FireSIGHT System. The contents of the menu depend on several factors, including the page you are viewing, the specific data you are investigating, and your user role.

Control license

A license that allows you to implement user control and application control. It also allows you to configure supported managed devices to perform hardware-based tasks such as switching and routing (including DHCP relay and NAT), VPN, and device clustering.

correlation

A feature you can use to build a correlation policy that responds in real time to threats on your network. The remediation component of correlation provides a flexible API that allows you to create and upload your own custom remediation modules to respond to policy violations.

correlation event

An event generated by the Defense Center when a correlation rule triggers. Note that white list events, generated by white list violations, are a special kind of correlation event.

correlation policy

A policy that describes the network activity that constitutes a security policy violation, using correlation rules and compliance white lists. You can specify responses to each rule or white list within a policy.

correlation rule

With compliance white lists, one of the ways you can specify criteria that network traffic must meet in order to violate a correlation policy. You can use the Defense Center to configure correlation rules to trigger (and generate a correlation event) when a specific event occurs, or when your network traffic deviates from your normal network traffic pattern as characterized in a traffic profile. You can constrain correlation rules with host profile qualifications, connection trackers, snooze periods, and inactive periods. You can also configure the Defense Center to launch a response, such as an alert or remediation, when a correlation rule triggers.

CRL

See certificate revocation list (CRL).

current identity

The operating system or server identity that the system finds most likely to be correct for a particular network asset. The system uses this data in many ways; for example, to calculate statistics, assign vulnerability information, assess impact of an attack, and evaluate correlation rules.

current user

The user that the system associates with a host. If the user is an access-controlled user, the system can perform user control on traffic to or from that host. If no access-controlled user is associated with the host, a non-access-controlled user can be the current user for the host. However, after an access-controlled user logs into the host, only a login by another access-controlled user changes the current user.

custom detection list

A list of files as represented by their SHA-256 hash values. When the system detects a file in the list, it does not perform a malware cloud lookup, treating the file as malware, even if the disposition for the file in the Collective Security Intelligence Cloud is Clean.

custom fingerprint

See fingerprint.

custom table

A table you can construct that combines fields from two or more of the predefined tables delivered with the FireSIGHT System. For example, you could combine the host criticality information from the host attributes table with information from the connection data table to examine connection data in a new context.

custom topology

A feature that allows you to meaningfully organize and identify subnets in the host, mobile device, and network device network maps.

custom user role

A user role with specialized access privileges. Custom user roles may have any set of menu-based and system permissions, and may be completely original or based on a predefined user role.

custom workflow

A workflow that you create to meet the unique needs of your organization.

dashboard

A display that provides at-a-glance views of current system status, including data about the events collected and generated by the system. To augment the dashboards delivered with the system, you can create multiple custom dashboards, populated with the dashboard widgets you choose. Compare with the Context Explorer, which offers a broad, brief, and colorful picture of how your monitored network looks and acts.

dashboard widget

A small, self-contained dashboard component that provides insight into an aspect of the FireSIGHT System.

data correlator

A program that generates events and creates the network map on the Defense Center, using the data collected by the system.

database access

A feature that allows read-only access to the Defense Center database by a third-party client.

decoder

A component of intrusion detection and prevention, configured in a network analysis policy, that places sniffed packets into a format that can be understood by a preprocessor.

default action

As part of an access control policy or SSL policy, the action that specifies how to handle, inspect, and log traffic that does not meet the conditions of any non- Monitor rule in the policy.

Defense Center

A central management point that allows you to manage devices and automatically aggregate and correlate the events they generate.

defragmentation policy

A sub-policy that describes how the IP defragmentation preprocessor (configured in a network analysis policy) should reassemble fragmented IP packets, based on the target host’s operating system. Note that adaptive profiles use adaptive defragmentation policies.

derived fingerprint

An operating system fingerprint created by the system from all passively collected fingerprints for a host by applying a formula which calculates the most likely identity, using the confidence value of each collected fingerprint and the amount of corroborating fingerprint data between identities.

device

A physical fault-tolerant, purpose-built appliance (including Cisco ASA with FirePOWER Services) available in a range of throughputs, or a software-based deployment with many of the same capabilities. Depending on the licensed capabilities you enable on your devices, you can use them to passively monitor traffic to build a comprehensive map of your network assets, application traffic, and user activity, as well as perform access control. Many devices can also perform switching, routing (including DHCP relay and NAT), and VPN. You must manage devices with a Defense Center.

device clustering

See clustering.

device stacking

See stacking.

discovery

A component of the FireSIGHT System that uses managed devices to monitor your network and provide you with a complete, persistent view of your network. Network discovery determines the number and types of hosts (including network devices and mobile devices) on your network, as well as information about the operating systems, active applications, and open ports on those hosts. You can also configure managed devices to monitor user activity on your network, which allows you to identify the source of policy breaches, attacks, or network vulnerabilities.

discovery data

Host, user, and application information that qualifies your network assets and traffic flow, as gathered by the discovery feature.

discovery event

An event that details the discovery of new assets or changes to existing assets. A host input event is a special kind of discovery event. Sometimes, “discovery event” refers to any discovery data or vulnerability information.

discovery policy

See network discovery policy.

discovery rule

Within a network discovery policy, specifies the networks and zones you want to monitor and the devices (including NetFlow-enabled devices) or you want to use to monitor them, as well as any ports you want to exclude from monitoring. Each rule also specifies whether you want to discover hosts, users, or applications on the monitored networks.

disposition

See malware disposition.

distinguished name object

A reusable object that represents a public key certificate's subject or issuer distinguished name.

drill-down page

An intermediate workflow page used to constrain event views. Generally, a drill-down page presents constraints that you can select to advance to a more narrowly constrained page or a table view.

drop event

An intrusion event generated when a drop rule triggers. In the event viewer, drop events are marked with black down arrows.

drop rule

An intrusion rule whose rule state is set to Drop and Generate Events. When a malicious packet triggers the rule in an inline deployment, and the intrusion policy you apply is set to drop when inline, the system drops the packet and generates an intrusion event (specifically, a drop event).

dynamic analysis

A method of submitting captured files from a device to the Collective Security Intelligence Cloud for malware analysis. The cloud runs the file in a test environment and returns a threat score and dynamic analysis summary report to the Defense Center. From the dynamic analysis summary report, you can also view the VRT Analysis Report.

dynamic analysis summary report

A summary of why the Collective Security Intelligence Cloud assigned a threat score to a file, including any threats discovered during dynamic analysis, as well as additional processes detected when running the file in the test environment. From here, you can also view the VRT Analysis Report.

dynamic rule state

A intrusion rule state that is set for a specified period of time in response to a detected rate anomaly in traffic matching the rule.

elliptic curve (EC) cryptography

A cryptographic method based on calculating points on a random elliptic curve over a finite field. Contrast with RSA cryptography.

endpoint

A computer or mobile device where your users install a FireAMP Connector as part of your organization’s advanced malware protection strategy.

eStreamer

A component of the FireSIGHT System that allows you to stream event data from a Defense Center or managed device to external client applications.

event

A collection of details about a specific occurrence that you can view in the event viewer, using workflows. Events may represent attacks on your network, changes in your detected network assets, violations of your organization’s security and network use policies, and so on. The system also generates events that contain information about the changing health status of appliances, your use of the web interface, rule updates, and launched remediations. Finally, the system presents certain other information as events, even though these “events” do not represent particular occurrences. For example, you can use the event viewer to view detailed information about detected hosts, applications, and their vulnerabilities.

Event Streamer

See eStreamer.

event suppression

A feature that allows you to use suppress intrusion events when a specific IP address or range of IP addresses triggers an intrusion rule. Event suppression is useful for eliminating false positives. For example, if you have an email server that transmits packets that look like a specific exploit, you can suppress events for the rules that are triggered by that server, so you only see the events for legitimate attacks.

event thresholding

A feature that allows you to limit the number of times the system logs and displays an intrusion event, based on how many times the event is generated within a specified time period. Use event thresholding if you are overwhelmed with a large number of identical events.

event traffic channel

See traffic channel.

event viewer

A component of the system that allows you to view and manipulate events. The event viewer uses workflows to present a broad, then a more focused event view that contains only the events of interest to you. You can constrain the events in an event view by drilling down through the workflow, or by using a search.

export

A method that you can use to transfer various configurations (such as policies) from appliance to appliance. After you export a configuration from one appliance, you can import it onto another appliance of the same type.

external authentication

A method (such as LDAP authentication or RADIUS authentication) that uses externally stored user credentials to authenticate user names and passwords when users log into FireSIGHT System appliances. Compare with internal authentication.

failsafe

A characteristic of an inline set that allows packets to bypass processing and continue through the device if internal traffic buffers are full.

fast-path rule

A rule that you configure at a device’s hardware level, using a limited set of criteria, to allow traffic that does not need to be analyzed to bypass processing.

feed

See Security Intelligence feed.

fingerprint

An established definition that the system compares against specific packet header values and other unique data from network traffic to identify a host's operating system. If the system misidentifies or cannot identify a host's operating system, you can create a custom fingerprint that identifies the host.

file capture

See captured file.

file category

A general classification for file types, such as graphics, executables, or archives.

file control

A feature that, as part of access control, allows you to specify and log the types of files that can traverse your network.

file disposition

See malware disposition.

file event

An event that represents a file detected in network traffic by a managed device.

file list

See clean list and custom detection list.

file policy

A policy that the system uses to perform file control and network-based advanced malware protection. Populated by file rules, a file policy is invoked by an access control rule within an access control policy.

file rule

A set of criteria within a file policy that the FireSIGHT System uses to examine network traffic. If a transmitted file matches the rule criteria, the rule triggers and generates a file event. The file rule action determine whether you block the file (based on file type or malware disposition) or simply allow the file to pass and log the transmission.

file rule action

A setting that determines how the system handles a file that meets the conditions of a file rule. You can detect and alert on specific file types, as well as block the transmission of those files. You can also perform malware cloud lookups on a subset of those file types and block the transmission of those files based on malware disposition.

file storage

See stored file.

file trajectory

See network file trajectory.

file type

A specific type of file format, such as PDF, EXE, or MP3.

FireAMP

Cisco’s enterprise-class, endpoint-based, advanced malware analysis and protection solution that discovers, understands, and blocks malware outbreaks, persistent threats, and targeted attacks. If your organization has a FireAMP subscription, individual users install lightweight FireAMP Connectors on endpoints (computers, mobile devices), which then communicate with the Collective Security Intelligence Cloud. This allows you to quickly identify and quarantine malware, as well as identify outbreaks when they occur, track their trajectory, understand their effects, and learn how to successfully recover. You can also use the FireAMP portal to create custom protections, block execution of certain applications, and create custom whitelists. Compare with network-based advanced malware protection.

FireAMP Connector

A lightweight agent that users in a subscription-based FireAMP deployment install on endpoints, such as computers and mobile devices. Connectors communicate with the Collective Security Intelligence Cloud, exchanging information that allow you to quickly identify and quarantine malware throughout your organization. They can also identify indications of compromise (IOC) on endpoint hosts.

FireAMP portal

The website, http://amp.sourcefire.com/ , where you can configure your organization’s subscription-based FireAMP deployment.

FireAMP Private Cloud

A FireAMP-provided virtual machine that acts as a secure mediator between your monitored network and the Collective Security Intelligence Cloud for FireAMP-based (file and malware) features. All connections to the cloud occur over the private cloud’s anonymized proxy connection, rather than from individual agents or appliances on your network.

FireAMP subscription

A separately purchased subscription that allows your organization to use FireAMP as an advanced malware protection (AMP) solution. Compare with a Malware license, which you enable on managed devices to perform network-based AMP.

FireSIGHT license

The default license on the Defense Center, which allows you to perform host, application, and user discovery. The FireSIGHT license also determines how many individual hosts and users you can monitor with the Defense Center and its managed devices, as well as the number of access-controlled users you can use in access control rules to perform user control.

FireSIGHT Recommendations layer

A built-in layer in an intrusion policy that exists when you allow the system to modify rule states to those recommended by the FireSIGHT recommended rules feature.

FireSIGHT recommended rules

A feature that recommends which rules should be enabled or disabled in your intrusion policy, based on information from your network map. You can choose to allow the system to modify rule states based on recommendations, in which case the system adds a read-only FireSIGHT Recommendations layer.

generator ID (GID)

A number that indicates which component of the system generated an intrusion event. GIDs help you analyze events more effectively by categorizing the type of event in the same way a rule’s Signature ID (Sid) offers context for the packets that trigger rules.

GeoDB

See geolocation database (GeoDB).

geolocation

A feature that provides data on the geographical source of routable IP addresses detected in traffic on your monitored network, including connection type, Internet service provider, and so on. You can see geolocation information in events and host profiles, and use it to filter traffic in an access control policy or SSL policy.

geolocation database (GeoDB)

A regularly updated database of known geolocation data associated with routable IP addresses.

GID

See generator ID (GID).

global blacklist

A Security Intelligence object included by default in every access control policy’s Security Intelligence blacklist. The global blacklist applies to all security zones. You can add individual IP addresses to the global blacklist using the IP address context menu in the dashboard, Context Explorer, and many event viewer pages.

global whitelist

A Security Intelligence object included by default in every access control policy’s Security Intelligence whitelist. The global whitelist applies to all security zones. You can add individual IP addresses to the global whitelist using the IP address context menu in the dashboard, Context Explorer, and many event viewer pages.

HA link interface

Also called the high availability link interface, a physical interface that you configure on each member of a clustered pair of devices to act as a redundant communications channel for sharing health information between the devices.

health event

An event generated when one of the appliances in your deployment meets (or fails to meet) performance criteria specified in a health module. Health events can also generate alerts.

health module

A test of a particular performance aspect, such as CPU usage or available disk space, of the appliances in your deployment. Health modules, which you enable in a health policy, generate health events when the performance aspects they monitor reach a certain level.

health monitor

A feature that continuously monitors the performance of the appliances in your deployment. The health monitor uses health modules within an applied health policy to test the appliances.

health monitor blacklist

A configuration that temporarily disables aspects of health monitoring to prevent the generation of unnecessary health events. You can disable monitoring for a group of appliances, a single appliance, or a specific health module.

health policy

The criteria used when checking the health of an appliance in your deployment. Health policies use health modules to indicate whether system hardware and software are working correctly. You can use the default health policy or create your own.

high availability

A feature that allows you to configure redundant physical Defense Centers to manage groups of devices. Event data streams from managed devices to both Defense Centers and most configuration elements are maintained on both Defense Centers. If your primary Defense Center fails, you can monitor your network without interruption using the secondary Defense Center. Compare with clustering, which allows you to designate redundant devices.

host

A device that is connected to a network and has a unique IP address. To the FireSIGHT System, a host is any identified host that is not categorized as a mobile device, bridge, router, NAT device, or load balancer.

host attribute

A tool you can use to provide information about hosts detected by the system, classifying them in ways that are important to your network environment. The system has two predefined host attributes, host criticality and notes, as well as host attributes that indicate the compliance of each host with each active compliance white list. You can also create your own host attributes.

host criticality

A host attribute that indicates the business criticality (importance) of any given host detected by the system.

host history

A graphical representation of the last 24 hours of a user’s activity. The host history, which you can view in a user’s user details, displays the IP addresses of the hosts that the user logged into, with approximate login and logout times represented by bar graphs.

host input

A feature that allows you to import data from third-party sources using scripts or command-line files to augment the information in the network map. The web interface also provides some host input functionality; you can modify operating system or application protocol identities, validate or invalidate vulnerabilities, and delete various items from the network map, including clients and server ports.

host input event

A kind of discovery event that is generated when you use the host input feature. In general, the system treats host input and passive discovery events identically, though they are distinguished when building correlation rules.

host profile

Collected information about a specific detected host. This includes general host information, such as its name and operating system, as well as the protocols and applications running on the host. The host profile may also include user history, host attributes, Virtual local area network (VLAN) information, applicable white list violations, detected vulnerabilities, indications of compromise (IOC), and scan results for that host.

host profile qualification

A constraint placed on a traffic profile or correlation rule. A host profile qualification within a correlation rule specifies that the Defense Center should generate a correlation event only if the host involved meets certain criteria. A host profile qualification within a traffic profile limits the hosts that are profiled.

host view

The final page in workflows that display discovery events or network assets. The host view displays the host profiles of the hosts involved in the events or assets you are viewing.

HTTP response page

A web page you can configure the system to display when a user’s HTTP request is blocked by access control. You can display a generic Cisco-provided response page, or you can provide custom HTML. If the request was blocked by an Interactive Block rule, you can allow users to click a button on the response page to continue to the originally requested site.

hybrid interface

A logical interface on a managed device that allows the system to bridge traffic between a virtual router and a virtual switch.

identity conflict

The conflict that occurs when the system reports a new passive operating system or server identity that conflicts with the current active identity and previously reported passive identities.

impact

For intrusion events, a numbered indicator of the correlation between intrusion data, discovery data, and vulnerability information. Impact level 1 (red impact icon) means that the targeted host is vulnerable to the attack represented by the intrusion event, impact level 2 (orange impact icon) means it is potentially vulnerable , and so on. Attacks directed at hosts on networks not monitored by the network discovery policy are impact level 0 (gray impact icon), which indicates that the Defense Center cannot determine the events’ impact.

import

A method that you can use to transfer various configurations from appliance to appliance. You can import configurations that you previously exported from another appliance of the same type.

inactive period

An interval during which a correlation rule does not trigger. You can configure the time, frequency, and duration of inactive periods. See also snooze period.

incident

One or more intrusion events that you suspect are involved in a possible violation of your security policy. The system provides incident-handling features that you can use to collect and process information that is relevant to your investigation of the incident.

indications of compromise (IOC)

Configured in the network discovery policy, a feature where the system correlates FireAMP endpoint data with hosts on your monitored network. Potentially compromised hosts are marked with tags to indicate their status, visible in the host profile and in relevant event views.

inline deployment

A deployment of the FireSIGHT System where your managed devices are placed inline on a network. In this configuration, devices can affect network traffic flow. Contrast with passive detection, where you can analyze and respond to, but not affect, the flow of traffic.

inline interface

A sensing interface configured to handle traffic in an inline deployment. You must add inline interfaces to inline sets in pairs.

inline set

One or more pairs of inline interfaces.

Intelligence Feed

A collection of regularly updated lists of IP addresses determined by the Cisco VRT to have a poor reputation. Each list in the Intelligence Feed represents a specific category: open relays, known attackers, bogus IP addresses (bogon), and so on. In an access control policy, you can blacklist any or all of the categories using Security Intelligence. Because the Intelligence Feed is regularly updated, using it ensures that the system uses up-to-date information to filter your network traffic.

Interactive Block

An access control rule action that allows your users to click a button on an HTTP response page to continue to an initially blocked web site.

internal authentication

An authentication method that stores user credentials in a local database on the appliance. When a user logs into the appliance, the user name and password are checked against the information in the database. Compare with external authentication.

intrusion

A security breach, attack, or exploit that occurs on your network.

intrusion detection and prevention

The monitoring of your network traffic for security policy violations, and, in inline deployments, the ability to block or alter malicious traffic. In the FireSIGHT System, you perform intrusion detection and prevention when you preprocess traffic with a network analysis policy, then associate an intrusion policy with an access control rule or default action.

intrusion event

An event that records an intrusion policy violation. Intrusion event data includes the date, time, and the type of exploit, as well as other contextual information about the attack and its target.

intrusion policy

A variety of components that you can configure to inspect your network traffic for intrusions and security policy violations. When your network traffic meets the conditions in an access control rule, you can inspect that traffic with an intrusion policy; you can also associate an intrusion policy with the access control policy’s default action. The main components of an intrusion policy are intrusion rules, which inspect traffic, and preprocessor rules, which generate events for associated preprocessor options in the network analysis policy. You can also add an optional FireSIGHT Recommendations layer, as well as configure advanced settings to inspect sensitive data or perform special intrusion event handling. Intrusion policies are always paired with variable sets.

intrusion rule

A set of keywords and arguments that, when applied to monitored network traffic, identify potential intrusions, security policy violations, and security breaches. The system compares packets against rule conditions. If the packet data matches the conditions, the rule triggers and generates an intrusion event. Intrusion rules include drop rules and pass rules.

layer

A complete set of configurations within an intrusion policy or network analysis policy. You can add custom user layers to the built-in layer in your policy. A setting in a higher layer overrides a setting in a lower layer.

LDAP authentication

A form of external authentication that verifies user credentials by comparing them to a Lightweight Directory Access Protocol (LDAP) directory stored on an LDAP directory server.

Lights-Out Management (LOM)

A Series 3 feature that allows you to use an out-of-band Serial over LAN (SOL) management connection to remotely monitor or manage certain appliances without logging into the web interface of the appliance. You can perform limited tasks, such as viewing the chassis serial number or monitoring such conditions as fan speed and temperature.

Link Aggregation Control Protocol (LACP)

A component of the IEEE 802.3ad specification that provides a method of exchanging system and port information to control the bundling of several physical ports together to form a single logical data channel called a link aggregation group (LAG). When you enable LACP, each device on either end of the channel uses LACP to determine which links will be actively used in the aggregation.

link aggregation group (LAG)

A Series 3 feature that allows you to group multiple physical Ethernet interfaces into a single logical link on managed devices configured in either a Layer 2 deployment that provides packet switching between networks, or a Layer 3 deployment that routes traffic between interfaces. This single aggregate logical link provides higher bandwidth, redundancy, and load-balancing between two endpoints.

link state propagation

An option for inline sets in bypass mode that automatically brings down the second interface in a pair when one of the interfaces in an inline set goes down. When the downed interface comes back up, the second interface automatically comes back up also. In other words, if the link state of a paired interface changes, the link state of the other interface changes automatically to match it.

list

See Security Intelligence list.

load balancer

A network device that distributes traffic to optimize performance and resource use. Using discovery, the system can identify load balancers.

logical interface

A virtual subinterface that you define to handle traffic with specific Virtual local area network (VLAN) tags as the tagged traffic passes through a physical interface.

malware blocking

A component of Cisco’s network-based advanced malware protection (AMP) solution. In an inline deployment, if malware detection yields a malware disposition for a detected file or the detected file is on the custom detection list, you can either block the file or allow its upload or download. Compare this functionality with FireAMP, Cisco’s endpoint-based AMP tool that requires a FireAMP subscription.

malware cloud lookup

A process by which the Defense Center communicates with the Collective Security Intelligence Cloud to determine the malware disposition of a file detected in network traffic, based on the file’s SHA-256 hash value.

malware detection

A component of Cisco’s network-based advanced malware protection (AMP) solution. File policies applied to managed devices as part of your overall access control configuration inspect network traffic. The Defense Center then performs malware cloud lookups for specific detected file types, and generates events that alert you to the files’ malware dispositions. AMP malware blocking follows and either blocks the file or allows its upload or download. Compare this functionality with FireAMP, Cisco’s endpoint-based AMP tool that requires a FireAMP subscription.

malware disposition

A determination by the Collective Security Intelligence Cloud as to whether a file contains malware, based on the file’s SHA-256 hash value, threat score, and whether the file is on the clean list or custom detection list.

malware disposition cache

A cache on the Defense Center that stores malware dispositions and threat scores for files. To improve performance, if the system already knows the disposition or threat score for a file based on its SHA-256 hash value, the Defense Center uses the cached information rather than performing a malware cloud lookup. Information in the cache times out after a certain period of time so that cache data does not become stale.

malware event

An event generated by one of Cisco’s advanced malware protection solutions. Network-based malware events are generated when the Collective Security Intelligence Cloud returns a malware disposition for a file detected in network traffic; retrospective malware events are generated when that disposition changes. Compare with endpoint-based malware events, which are generated when a deployed FireAMP Connector detects a threat, blocks malware execution, or quarantines or fails to quarantine malware.

Malware license

A license that allows you to perform advanced malware protection (AMP) in network traffic. Using a file policy, you can configure the system to perform malware cloud lookups on specific file types detected by managed devices. Compare with FireAMP subscription.

malware protection

See advanced malware protection.

malware storage pack

A secondary solid-state drive supplied by Cisco that you can install in certain devices to store captured files, freeing space on the device’s primary hard drive for event and configuration storage.

managed device

See device.

management interface

The network interface that you use to administer a FireSIGHT System appliance. In most deployments, the management interface is connected to an internal protected network. Compare with sensing interface. On virtual Defense Centers and all Series 3 appliances, you can configure multiple management interfaces to either separate traffic into channels to improve performance, or to create a route to an additional network to allow a Defense Center to isolate traffic on different networks. You can also route traffic channels to separate networks to increase throughput capacity.

management traffic channel

See traffic channel.

mobile device

In the FireSIGHT System, a host identified by the discovery feature as a mobile, handheld device (such as a mobile phone or tablet). The system can often detect whether a mobile device is jailbroken.

Monitor

A way to log matching traffic, but also to allow the system to continue evaluating the connection rather than immediately allowing or blocking it. You can monitor traffic that violates a Security Intelligence blacklist, or that matches any combination of criteria in an access control rule or SSL rule.

NAT

Network address translation, a feature most commonly used to share a single Internet connection among multiple hosts on a private network. Using discovery, the system can identify network devices as load balancers. In addition, in a Layer 3 deployment of the FireSIGHT System, you can configure routing with NAT using a NAT policy.

NAT policy

A policy that uses NAT rules to perform routing with NAT.

NAT rule

A set of configurations and conditions that evaluate network traffic and specify how traffic matching those qualifications is translated. NAT rules are added to an existing NAT policy to perform routing using NAT.

NetFlow

An open but proprietary network protocol for collecting IP traffic information, developed by Cisco to run on Cisco IOS-enabled equipment. You can use the information collected by NetFlow-enabled devices to supplement the discovery and connection data collected by the FireSIGHT System and to monitor networks not covered by managed devices.

NetMod

A module that you install in the chassis of a managed device that contains the sensing interfaces for that device.

network analysis policy

A variety of preprocessors that you can configure to decode, normalize, and preprocess network traffic in preparation for later analysis by an intrusion policy. By default, a single system-provided network analysis policy preprocesses all traffic handled by an access control policy. However, you can choose a custom network analysis policy to perform this preprocessing. Advanced users can use network analysis rules to allow multiple custom network analysis policies to preprocess traffic based on security zone, network, or VLAN tag.

network analysis rule

A set of conditions that advanced FireSIGHT System users can use to perform targeted preprocessing using multiple custom network analysis policies. You configure network analysis rules as an advanced option in an access control policy.

network device

In the FireSIGHT System, a host identified as a bridge, router, NAT device, or load balancer.

network discovery

See discovery.

network discovery policy

A policy that specifies the kinds of discovery data (including host, user, and application data) the system collects for specific network segments, including networks monitored by NetFlow-enabled devices. The network discovery policy also manages identity conflict resolution preferences, active detection source priorities, and indications of compromise (IOC).

network file trajectory

A visual representation of a file’s path as hosts transfer it across your network. For any file with an associated SHA-256 hash value, the trajectory map displays the IP addresses of all hosts that have transferred the file, the time the file was detected, the file’s malware disposition, associated file events and malware events, and so on.

network map

A detailed representation of your network. The network map allows you to view your network topology in terms of the hosts, mobile devices, and network devices running on your network, as well as their associated host attributes, application protocols, and vulnerabilities.

network object

A reusable object that represents one or more IP addresses, CIDR blocks, or prefix lengths.

Nmap

Network Mapper, an open source active scanner that you can use to detect operating systems and application protocols running on a host. Running an Nmap scan adds the information detected to your network map.

non-access-controlled user

Any user, whether detected by the User Agent or a managed device, that is not used for access control. A non-access-controlled user can only be the current user for a host if no access-controlled user has ever logged into the host.

non-bypass mode

A characteristic of an inline set that blocks traffic if the sensing interfaces in the set fail for any reason.

object

A reusable configuration that associates a name with a value (for example, an IP address or URL) so that when you want to use that value in the web interface, you can use the named object instead. You create objects using the object manager. See also: network object, Security Intelligence object, port object, VLAN tag object, URL object, application filter, variable set, file list, HA link interface, security zone, cipher suite list, distinguished name object, and PKI object.

object manager

The page on the web interface where you manage objects and object groups.

operating system identity

The operating system vendor and version details for an operating system on a host.

packet view

A type of workflow page that provides detailed information about the packet that triggered an intrusion rule or the preprocessor that generated an intrusion event. The packet view is the final page in workflows based on intrusion events.

pass rule

An intrusion rule that, when triggered, does not generate an intrusion event and does not log the details of the packet that triggered the rule. Pass rules allow you to prevent packets that meet specific criteria from generating an event in specific situations, as an alternative to disabling the intrusion rule. Compare with drop rule.

passive detection

The collection of discovery data through analysis of traffic passively collected by managed devices. Compare with active detection.

passive interface

A sensing interface configured to analyze traffic in a passive deployment.

pending (application protocol)

A designation given to an application protocol identity when the system can neither positively nor negatively identify the application protocol. Most often, the system needs to collect and analyze more data before it can identify a pending application protocol.

physical interface

An interface that represents a physical port on a NetMod.

PKI

See public key infrastructure (PKI).

PKI object

Reusable objects that represent public key certificates and paired private keys.

policy

A mechanism for applying settings, most often to an appliance. See access control policy, correlation policy, file policy, health policy, intrusion policy, network analysis policy, network discovery policy, SSL policy, and system policy.

policy target

An appliance or zone where you apply a policy. A policy may have multiple targets.

port object

A reusable object that represents an open port that uses transport layer protocols (for example, TCP, UDP, or ICMP).

preprocessor

A component of the system that prepares traffic to be further inspected for intrusions and exploits. Preprocessors normalize traffic and help identify network layer and transport layer protocol anomalies by identifying inappropriate header options, defragmenting IP datagrams, providing TCP stateful inspection and stream reassembly, and validating checksums. Preprocessors can also render specific types of packet data in a format that the system can analyze; these preprocessors are called data normalization preprocessors, or application layer protocol preprocessors. Normalizing application layer protocol encoding allows the system to effectively apply the same content-related intrusion rules to packets whose data is represented differently and obtain meaningful results. Preprocessors generate preprocessor events whenever packets trigger preprocessor options that you configure. Preprocessors require specific expertise to configure, typically require little or no modification, and are not common to every deployment.

preprocessor event

A type of intrusion event that is generated when a packet triggers specified preprocessor options. Preprocessor events can help you detect anomalous protocol exploits.

preprocessor rule

An intrusion rule associated with a preprocessor or with the portscan flow detector. You must enable preprocessor rules if you want them to generate events. Preprocessor rules have a preprocessor-specific generator ID (GID).

private key

A cryptographic key known only to the owner of the paired public key certificate. The public key and private key are used for Secure Sockets Layer (SSL) and Transport Layer Security encryption and decryption.

private search

A named set of search criteria for a specific table, tied to your user account. Only you and users with Administrator access can use your private searches.

protected network

Your organization’s internal network that is protected from users of other networks by a device such as a firewall. Many of the intrusion rules delivered with the system use variables to define the protected network and the unprotected (or outside) network.

Protection license

A license that allows you to perform intrusion detection and prevention, file control, and Security Intelligence filtering. Without a license, Series 2 devices automatically have Protection capabilities, with the exception of Security Intelligence.

public key

A cryptographic key associated with a public key certificate that is available to everyone. The public key and paired private key are used for Secure Sockets Layer (SSL) and Transport Layer Security encryption and decryption.

public key certificate

A digital document issued by a certificate authority to an individual that confirms the public key stored in the certificate belongs to the individual.

public key infrastructure (PKI)

A system to manage how a certificate authority issues public key certificates and paired private keys to individuals.

RADIUS authentication

Remote Authentication Dial In User Service, a service used to authenticate, authorize, and account for user access to network resources. You can create an external authentication object to allow FireSIGHT System users to authenticate through a RADIUS server.

rate filtering

A form of anomaly detection that sets a new intrusion rule state for a rule based on the rate of matching traffic.

remediation

An action that mitigates potential attacks on your system. You can configure remediations and, within a correlation policy, associate them with correlation rules and compliance white lists so that when they trigger, the Defense Center launches the remediation. This can not only automatically mitigate attacks when you are not immediately available to address them, but can also ensure that your system remains compliant with your organization’s security policy. The Defense Center ships with predefined remediation modules, and you can also use a flexible API to create custom remediations.

remediation instance

A set of configurations for a remediation module. You can configure multiple instances per module, for example, you could respond to different correlation policy violations using the same module, but different instances that have different settings. When a remediation instance triggers, the resulting action is called a remediation.

remediation module

A program that launches a remediation, using sets of configurations called remediation instances. The FireSIGHT System ships with several remediation modules that perform various actions; you can also use a flexible API to create your own modules.

remediation status event

An event generated when a remediation is launched.

report template

A template that specifies the data constraints and formats for a report and its sections.

reputation (IP address)

See Security Intelligence.

reputation (URL)

See URL reputation.

response

A reaction to a correlation policy violation — either an alert or a remediation.

retrospective malware event

A network-based malware event generated when the malware disposition for a previously detected file changes. When this occurs, the system also updates the dispositions for files and malware that share the retrospective event’s SHA-256 hash value.

risk

See application risk.

routed interface

An interface that routes traffic in a Layer 3 deployment. You can set up physical routed interfaces for handling untagged Virtual local area network (VLAN) traffic, and logical routed interfaces for handling traffic with designated VLAN tags. You can also add static Address Resolution Protocol (ARP) entries to routed interfaces.

router

A network device, located at a gateway, that forwards packets between networks. Using network discovery, the system can identify routers. In addition, you can configure managed devices as virtual routers that route traffic between two or more interfaces.

RSA cryptography

A cryptographic method based on factoring a large number into two prime numbers. Contrast with elliptic curve (EC) cryptography.

rule

A construct, often within a policy, that provides criteria against which network traffic is examined. See also: access control rule, correlation rule, discovery rule, fast-path rule, file rule, intrusion rule, network analysis rule, preprocessor rule, and SSL rule.

rule action

A setting that determines how the system handles network traffic that meets the conditions of a rule. See also: access control rule action, file rule action, and SSL rule action.

rule state

Whether an intrusion rule is enabled (set to Generate Events or Drop and Generate Events), or disabled (set to Disable) within an intrusion policy. If you enable a rule, it is used to evaluate your network traffic; if you disable a rule, it is not used.

rule update

An as-needed intrusion rule update that contains new and updated standard text rules, shared object rules, and preprocessor rules. A rule update may also delete rules; modify default intrusion policy, network analysis policy, and advanced access control policy settings; and add or delete default variables and rule categories.

scheduled task

An administrative task that you can schedule to run once or at recurring intervals.

Secure Sockets Layer (SSL)

A cryptographic application layer protocol that preceded the Transport Layer Security protocol. The SSL inspection feature allows you to decrypt traffic encrypted with the SSL protocol.

Security Intelligence

A feature that allows you to specify the traffic that can traverse your network, per access control policy, based on the source or destination IP address. This is especially useful if you want to blacklist—deny traffic to and from—specific IP addresses, before the traffic is subjected to analysis by access control rules. Optionally, you can use a Monitor setting for Security Intelligence filtering, which allows the system to analyze connections that would have been blacklisted, but also logs the match to the blacklist.

Security Intelligence blacklist

In an access control policy, a list of IP addresses that allows you to deny traffic to and from those hosts, before the traffic is subjected to analysis by access control rules. A blacklist is comprised of Security Intelligence objects, including the global blacklist. An access control policy’s Security Intelligence whitelist overrides its blacklist.

Security Intelligence event

A connection event generated by traffic that is blocked or monitored by the Security Intelligence blacklist. You can view and interact with Security Intelligence events independently from ordinary connection events.

Security Intelligence feed

One of the types of Security Intelligence objects, a dynamic collection of IP addresses that the system downloads on a regular basis, at an interval you configure. Because feeds are regularly updated, using them ensures that the system uses up-to-date information to filter your network traffic using the Security Intelligence feature. See also the Intelligence Feed.

Security Intelligence list

A simple static collection of IP addresses that you manually upload to the Defense Center as a Security Intelligence object. Use lists to augment and fine-tune Security Intelligence feeds as well as the global blacklist and global whitelist.

Security Intelligence object

A single configuration that represents one or more IP addresses, and that you add to an access control policy’s Security Intelligence blacklist and Security Intelligence whitelist. Security Intelligence objects include Security Intelligence lists, Security Intelligence feeds, and network objects and groups. The global blacklist, global whitelist, and the categories in the Intelligence Feed are also considered Security Intelligence objects.

Security Intelligence whitelist

In an access control policy, a list of IP addresses that forces the policy to examine traffic to and from those hosts using access control rules, that is, to not deny the traffic using Security Intelligence. Because a policy’s whitelist overrides its Security Intelligence blacklist, you can use it to fine-tune the blacklist. A whitelist is comprised of Security Intelligence objects, including the global whitelist.

security policy

An organization's guidelines for protecting its network. For example, your security policy might forbid the use of wireless access points. A security policy may also include an acceptable use policy (AUP), which provides employees with guidelines of how they may use their organization’s systems.

security policy violation

A security breach, attack, exploit, or other misuse of your network.

security zone

A grouping of one or more inline, passive, switched, or routed interfaces that you can use to manage and classify traffic flow in various policies and configurations. The interfaces in a single zone may span multiple devices; you can also configure multiple security zones on a single device. You must assign at least one interface to a security zone to match traffic against that security zone, and each interface can belong to only one zone.

sensing interface

A network interface on a device that you use to monitor a network segment. Compare with management interface.

Series 2

The second series of FireSIGHT System appliance models. Because of resource, architecture, and licensing limitations, Series 2 appliances support a restricted set of features. Series 2 devices include the 3D500, 3D1000, 3D2000, 3D2100, 3D2500, 3D3500, 3D4500, 3D6500, and 3D9900. Series 2 Defense Centers include the DC500, DC1000, and DC3000.

Series 3

The third series of FireSIGHT System appliance models. Series 3 appliances include 7000 Series and 8000 Series devices, as well as the DC750, DC1500, DC2000, DC3500, and DC4000 Defense Centers.

server

The server application (compare with client application) installed on a host, identified by application protocol traffic.

server banner

The first 256 bytes of the first packet detected for a server, which can provide additional information that may help you identify the server. The system collects a server banner only once, the first time the server is detected.

server certificate

An encrypted certificate issued by a certificate authority that provides unalterable confirmation of the server identity. You can request a certificate from any certificate authority and upload that custom certificate to your appliance.

server identity

The application protocol type, vendor, and version details for a server on a host.

SFP module

A small form-factor pluggable transceiver that is inserted into a network module on a 71xx Family device. Sensing interfaces on SFP modules do not allow configurable bypass.

SHA-256 hash value

Sometimes abbreviated as SHA256, a 32-bit string that represents a file for which you are performing a malware cloud lookup. The hash value is calculated using a cryptographic hash function so that files with identical SHA-256 values are very likely to have identical contents.

shared layer

An intrusion policy or network analysis policy layer that you allow to be used by other policies. Policies using a shared layer are updated with changes in the shared layer when you commit those changes. A shared layer can be modified only in the policy that allows it to be shared; it is read-only in policies using it.

shared object rule

An intrusion rule delivered as a binary module compiled from C source code. You can use shared object rules to detect attacks in ways that standard text rules cannot. You cannot modify the rule keywords and arguments in a shared object rule; you are limited to either modifying variables used in the rule, or modifying aspects, such as the source and destination ports and IP addresses, and saving a new instance of the rule as a custom shared object rule. Shared object rules have a generator ID (GID) of 3.

SID

See Signature ID (Sid).

Signature ID (Sid)

A unique identifying number assigned to each intrusion rule (also known as a Snort ID). When you create a new rule or modify an existing standard text rule, it is given an SID of 1,000,000 or greater. The SIDs for shared object rules and standard text rules delivered with the FireSIGHT System are lower than 1,000,000. Also, preprocessors and decoders use SIDs to identify the different types of packets they detect.

snooze period

An interval specified in seconds, minutes, or hours after a correlation rule triggers during which the system stops firing that rule, even if the rule is violated again during the interval. When the snooze period has ended, the rule can trigger again (and start a new snooze period). See also inactive period.

Snort

An open source intrusion detection system that performs real-time traffic analysis and packet logging on IP networks. Snort can perform protocol analysis, content searching and matching, and can detect a variety of attacks and probes. Snort uses a flexible rules language to describe network traffic that it should collect or pass. The FireSIGHT System uses Snort to test packets against decoders, preprocessors, and intrusion rules.

Spero analysis

A method of submitting file structural characteristics to the Collective Security Intelligence Cloud for malware analysis. The results supplement dynamic analysis.

SSL

See Secure Sockets Layer (SSL).

SSL inspection

A feature that allows you to inspect, decrypt, and log the encrypted traffic that traverses your network. Both traffic you choose not to decrypt and decrypted traffic can be further inspected with access control.

SSL policy

A policy that you apply as part of a parent access control policy, and that performs SSL inspection on the encrypted traffic monitored by policy target devices. An SSL policy may include multiple SSL rules; it also specifies a default action, which determines the handling and logging of traffic that does not meet the criteria of any of those rules. An SSL policy can also specify how to handle undecryptable traffic, and what encrypted traffic it trusts, based on CA public key certificates.

SSL rule

A set of conditions the system uses to examine encrypted traffic and which allows SSL inspection. SSL rules, which populate an SSL policy, may perform simple IP address matching, or may characterize complex connections involving different users, applications, ports, URLs, and encrypted session characteristics. The SSL rule action determines how the system handles traffic that meets the rule’s conditions. Other rule settings determine how (and whether) the connection is logged.

SSL rule action

A setting that determines how the system handles encrypted network traffic that meets the conditions of an SSL rule. You can block matching traffic (with or without resetting the connection). You can also not decrypt encrypted traffic, decrypt incoming traffic with an uploaded private key, decrypt outgoing traffic with a re-signed public key certificate, or continue to monitor traffic with additional SSL rules.

stack

Two to four connected devices that share detection resources.

stacking

A feature that allows you to increase the amount of traffic inspected on a network segment by connecting two to four physical devices in a stacked configuration. When you establish a stacked configuration, you combine the resources of each stacked device into a single, shared configuration.

standard text rule

An intrusion rule created based on the identifiers, keywords, and arguments available in the rule editor. You can create your own custom standard text rules and modify Cisco-provided standard text rules. A standard text rule has a generator ID (GID) of 1.

state sharing

A feature that allows clustered devices or stacks to synchronize so that if either device or stack fails, the peer can take over with no interruption to traffic flow. State sharing ensures that strict TCP enforcement, unidirectional access control rules, blocking persistence, and dynamic NAT fail over properly.

stored file

A captured file that is saved to a device’s hard drive or malware storage pack, if installed. Stored files can be downloaded and analyzed at a later time.

sub-server

A server called by another server on the same host.

suppression

See event suppression.

SVID

See vulnerability ID.

switch

A network device that acts as a multiport bridge. Using network discovery, the system identifies switches as bridges. In addition, you can configure managed devices as virtual switches, performing packet switching between two or more networks.

switched interface

An interface that you want to use to switch traffic in a Layer 2 deployment. You can set up physical switched interfaces for handling untagged Virtual local area network (VLAN) traffic, and logical switched interfaces for handling traffic with designated VLAN tags.

system policy

Settings that are likely to be similar for multiple appliances in a deployment, such as mail relay host preferences and time synchronization settings. Use the Defense Center to apply a system policy to itself and its managed devices.

table view

A type of workflow page that displays event information, with one column for each of the fields in the database table. When performing event analysis, you can use drill-down pages to constrain the events you want to investigate before moving to the table view that shows you the details about the events you are interested in. The table view is often the next-to-last page in workflows delivered with the system.

tag (application)

See application tag.

tap mode

An advanced inline set option available on 3D9900 and Series 3 devices where a copy of each packet is analyzed and the network traffic flow is undisturbed instead of passing through the device. Because you are working with copies of packets rather than the packets themselves, the device cannot affect the packet stream even if you configure access control and intrusion policies to drop, modify, or block traffic.

target device

See policy target.

task queue

A queue of jobs that the appliance needs to perform. When you apply a policy, install software updates, and perform other long-running jobs, the jobs are queued and their status reported on the Task Status page. The Task Status page provides a detailed list of jobs and refreshes every ten seconds to update their status.

third-party vulnerability

Vulnerability data obtained from a third party. If your organization can write scripts or create command line import files to import network map data from third-party applications, you can use the host input feature to import third-party vulnerability data to augment the system’s vulnerability data.

threat score

A rating of 1-100 assigned to a file as a result of submission to the Collective Security Intelligence Cloud for dynamic analysis that measures the likelihood the file contains malware.

thresholding

See event thresholding.

time window

A time constraint on the events in any event view. Different event views may have different default time windows, depending on your user preferences. Note that not all event views can be constrained by time.

TLS

See Transport Layer Security.

traffic channel

A connection you can configure on the management interface of a Series 3 appliance or virtual Defense Center to carry either management or event traffic. The event traffic channel carries only event data generated on the managed device’s network segment and the management traffic channel carries only internally generated traffic (that is, management traffic between the Defense Center and the device). See management interface.

traffic profile

A profile of the traffic on your network, based on connection events logged over a time span that you specify. You can create profiles using all the traffic on a monitored network segment, or you can create more targeted profiles. Then, you can use the correlation feature to detect abnormal network traffic by evaluating new traffic against an existing profile.

transparent inline mode

An advanced inline set option that allows a device to act as a “bump in the wire” and to forward all the network traffic it sees, regardless of its source and destination.

Transport Layer Security

A cryptographic application layer protocol that succeeded the Secure Sockets Layer (SSL) protocol. The SSL inspection feature allows you to decrypt traffic encrypted with the TLS protocol.

unidentified host

A host whose operating system cannot be identified because the system has not yet gathered enough information about the host. Compare with unknown host.

Unified file

A binary file format that the FireSIGHT System uses to log event data.

unknown host

A host whose traffic has been analyzed by the system, but whose operating system does not match any known fingerprints. Compare with unidentified host.

URL category

A general classification for a URL, such as malware or social networking.

URL filtering

A feature that allows you to write access control rules that determine the traffic that can traverse your network based on URLs requested by monitored hosts, correlated with URL category and URL reputation information about those URLs, which is obtained from the Collective Security Intelligence Cloud by the Defense Center. You can also achieve more granular, custom control over web traffic by specifying individual URLs or groups of URLs to allow or block.

URL Filtering license

A license that allows you to perform URL filtering based on URL category and URL reputation information. URL Filtering licenses may expire.

URL object

A reusable object that represents an individual URL.

URL reputation

A representation of how likely a website is to be used for purposes that might be against your organization’s security policy, as determined by the Collective Security Intelligence Cloud.

user

A user whose network activity has been detected by a managed device or User Agent.

user activity

An event generated when the system detects a user login or logoff (optionally, including some failed login attempts) or the addition or deletion of a user record from the Defense Center database.

User Agent

An agent you install on a server to monitor users as they log into the network or when they authenticate against Active Directory credentials for any other reason. Activity by access-controlled users is used for access control only when a User Agent reports it.

user awareness

A feature that allows your organization to correlate threat, endpoint, and network intelligence with user identity information, and that allows you to perform user control.

user awareness object

A collection of settings that allows you to connect to an LDAP server to retrieve metadata for users whose activity was detected in network traffic or by a User Agent. If your organization uses Microsoft Active Directory, user awareness objects can also specify your access-controlled users.

user certificate

An encrypted certificate that identifies a user's browser to the FireSIGHT System web server, allowing the server to do a secondary verification of user identity. The certificate must be issued by the same certificate authority that issued the server certificate for your appliance.

user control

A feature that, as part of access control, allows you to specify and log the user-associated traffic that can traverse your network.

user details

The final page in user identity and user activity workflows. Along with general information about the user, the user details also display a host history, which is a graphical representation of the last twenty-four hours of the user’s activity.

user history

A graphical representation of the last twenty-four hours of user activity for a host. The user history, which you can view in a host’s host profile, displays the user names of the users detected logging into the host, with approximate login and logout times represented by bar graphs.

user identity

See user.

user layer

A layer in an intrusion policy where you can modify settings in the policy.

user role

The level of access granted to a user of the FireSIGHT System. For example, you can grant different access privileges to the web interface for event analysts, the administrator managing the FireSIGHT System, users accessing the Defense Center database using third-party tools, and so on. You can also create custom roles with specialized access privileges.

user role escalation

A privilege you can give to custom user roles that allows users to enter a password to gain the permissions of another user role for the duration of a login session.

UTC time

Coordinated Universal Time. Also known as Greenwich Mean Time (GMT), UTC is the standard time common to every place in the world. The FireSIGHT System uses UTC, although you can set the local time using the Time Zone feature.

variable

A representation of a value that is commonly used in intrusion rules. The FireSIGHT System uses preconfigured variables, organized in variable sets, to define networks and port numbers. Rather than hard-coding these values in multiple rules, to tailor a rule to accurately reflect your network environment, you can change the variable value.

variable set

A collection of variable configurations that you link to an intrusion policy so you can tailor intrusion rules enabled in each intrusion policy to closely match your network traffic.

VDB

See vulnerability database.

virtual Defense Center

A Defense Center that you can deploy on your own equipment in a virtual hosting environment.

virtual device

A managed device that you can deploy on your own equipment in a virtual hosting environment. Virtual devices do not support hardware-based features, such as high availability, clustering, stacking, NAT, VPN, and fast-path rules, and you cannot configure a virtual device as a virtual switch or virtual router.

Virtual local area network (VLAN)

VLANs map hosts not by geographic location, but by some other criterion, such as by department or primary use. A monitored host’s host profile shows any VLAN information associated with the host. Innermost VLAN tag information is also included in various events. The system can also perform multiple types of traffic handling including access control, based on a connection’s VLAN tag. In Layer 2 and Layer 3 deployments, you can configure virtual switches and virtual routers on managed devices to appropriately handle VLAN-tagged traffic.

virtual router

A group of routed interfaces that route Layer 3 traffic. In a Layer 3 deployment, you can configure virtual routers to route packets by making packet forwarding decisions according to the destination IP address. You can define static routes, configure Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) dynamic routing protocols, as well as implement Network Address Translation ( NAT).

virtual switch

A group of switched interfaces that process inbound and outbound traffic through your network. In a Layer 2 deployment, you can configure virtual switches on managed devices to operate as standalone broadcast domains, dividing your network into logical segments. A virtual switch uses the media access and control (MAC) address from a host to determine where to send packets.

VLAN

See Virtual local area network (VLAN).

VLAN tag object

A reusable object that represents an individual Virtual local area network (VLAN) tag.

VPN

A feature that allows you to build secure VPN tunnels between the virtual routers of FireSIGHT System managed devices.

VPN license

A license that allows you to build secure VPN tunnels between the virtual routers of FireSIGHT System managed devices.

VRT

See Cisco VRT.

VRT Analysis Report

A record of the Cisco VRT’s analysis of a captured file submitted for dynamic analysis, detailing the information presented in the dynamic analysis summary report, as well as additional information discovered during dynamic analysis.

vulnerability

A description of a specific compromise to which a host is susceptible. The Defense Center provides information on the vulnerabilities to which each of your hosts is vulnerable in the hosts’ host profiles. In addition, you can use the vulnerabilities network map to obtain an overall view of the vulnerabilities that the system has detected on your entire monitored network. If you deem a host or hosts no longer vulnerable to a specific compromise, you can deactivate, or mark as invalid, a specific vulnerability.

vulnerability database

Also called the VDB, a database of known vulnerabilities to which hosts may be susceptible. The system correlates the operating system, application protocols, and clients detected on each host with the VDB to help you determine whether a particular host increases your risk of network compromise. VDB updates may contain new and updated vulnerabilities, as well as new and updated application detectors.

vulnerability detail

The final page in vulnerability workflows. Vulnerability details provide information about a specific vulnerability, including technical details and known solutions.

vulnerability ID

An identification number associated with a particular vulnerability. The Cisco vulnerability database and third-party vulnerability databases, such as Bugtraq and CVE, have different vulnerability ID numbering schemes.

vulnerability mapping

The association of vulnerability information with discovery data, so that you can perform impact correlation.

web application

A type of application that represents the content of, or requested URL for, HTTP traffic.

whitelist

A compliance white list, a Security Intelligence whitelist, the HA link interface, or a list of IP addresses that you can configure within a remediation to exempt IP addresses from some kind of action.

white list event

An event generated when the system detects that a valid target host has become non-compliant with a compliance white list. White list events are a special kind of correlation event.

white list violation

Information that you can view in the event viewer that details how a host is non-compliant with a compliance white list.

widget

See dashboard widget.

workflow

A series of pages you can use to view and evaluate events by moving from a broad view of event data to a more focused view that contains only the events of interest to you. Workflows can include three types of pages, each of which performs a unique function: drill-down pages, table views, and a final page. Depending on the workflow type, the final page may be a table view, packet view, host view, vulnerability detail, or user details.

X-Series

The short name for Cisco NGIPS for Blue Coat X-Series.

zone

See security zone.

FireSIGHT System User Guide

Version 5.4.1

XXXX

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

© 2015 Cisco Systems, Inc. All rights reserved.