- Title Page
- 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
- Viewing Intrusion Event Statistics
- Viewing Intrusion Event Performance
- Viewing Intrusion Event Graphs
- Viewing Intrusion Events
- Understanding Workflow Pages for Intrusion Events
- Using Drill-Down and Table View Pages
- Using the Packet View
- Using Impact Levels to Evaluate Events
- Reading Preprocessor Events
- Searching for Intrusion Events
- Using the Clipboard
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.
- 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
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:
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.
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
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
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.
Viewing Intrusion Event Performance
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:
Step 1 Select Overview > Summary > Intrusion Event Performance .
The Intrusion Event Performance page appears.
Generating Intrusion Event Performance Statistics Graphs
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.
To generate intrusion event performance graphs:
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.
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
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
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.
Viewing Intrusion Events
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
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
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.
The following list describes the information that an intrusion event contains. Note that some fields in the table view of intrusion events are disabled by default. To enable a field for the duration of your session, click the expand arrow (
) to expand the search constraints, then click the column name under
Disabled Columns
.
The date and time of the event.
The event priority as determined by the Cisco VRT.
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.
- 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.
The IP address used by the sending host.
The country of the sending host.
The IP address used by the receiving host.
The country of the receiving host.
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.
The port number on the sending host. For ICMP traffic, where there is no port number, the system displays the ICMP type.
The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, the system displays the ICMP code.
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)
.
Click the lock icon (
) to view certificate details. For more information, see Viewing the Certificate Associated with an Encrypted Connection.
The innermost VLAN ID associated with the packet that triggered the intrusion event.
The Multiprotocol Label Switching label associated with the packet that triggered this intrusion event.
This field is disabled by default.
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.
The classification where the rule that generated the event belongs. See the Rule Classifications table for a list of rule classification names and numbers.
The component that generated the event. See Table 41-7 for a list of intrusion event generator IDs.
The User ID for any known user logged in to the source host.
The User ID for any known user logged in to the destination host.
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 .
The client application, if available, which represents software running on the monitored host detected in the traffic that triggered the intrusion event.
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.
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.
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.
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.
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.
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.
The managed device where the access control policy was applied. See Managing Devices.
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.
The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. See Configuring Sensing Interfaces.
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.
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.
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.
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.
The network analysis policy (NAP), if any, associated with the generation of the event; see Getting Started with Network Analysis Policies.
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.
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.
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.
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.
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.
The name of the user who reviewed the event. See Reviewing Intrusion Events.
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
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:
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
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:
Step 1 On a page that displays intrusion events, you have two options:
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:
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:
Step 1 On a page that displays reviewed events, you have two options:
A success message appears and the list of reviewed events is updated.
Understanding Workflow Pages for Intrusion Events
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:
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.
For example, if you click the close column icon (
) in any column and clear
Time
from the drop-down list, you can remove Time as one of the columns. To narrow the list of events in your analysis, you can click the link for a value in one of the rows in the table view. For example, to limit your analysis to the events generated from one of the source IP addresses (presumably, a potential attacker), click the IP address in the
Source IP Address
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.
- 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
The workflows that you can use to investigate intrusion events take advantage of three different types of pages:
Each of these pages is described in Understanding Workflow Pages for Intrusion Events.
The drill-down views and table view of events share some common features that you can use to narrow a list of events and then concentrate your analysis on a group of related events. The following table describes these features.
find more information in Understanding Intrusion Events. |
|
click the host profile icon ( |
|
click the flag icon that appears in the Source Country or Destination Country columns. |
|
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. |
|
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:
The clipboard stores up to 25,000 events per user. For more information, see Using the Clipboard. |
mark events reviewed to remove them from intrusion event pages, but not the event database |
use one of the following methods:
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:
Captured packets are saved in libpcap format. This format is used by several popular protocol analyzers. |
find more information in Navigating Between Workflows. |
|
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. |
click Dashboards . For more information, see Working with Dashboards. |
|
click View Bookmarks . For more information, see Using Bookmarks. |
|
click Report Designer . For more information, see Creating a Report Template from an Event View. |
) that appears next to the host IP address.The number of intrusion events that appear on the event views may be quite large, depending on:
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.
The following table describes how to use the drill-down pages.
The following table describes how to use the table view.
) to expand the search constraints, then click the column name under Disabled Columns.
) next to the event whose packets you want to view.
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
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.
The following table describes the actions you can take on the packet view.
find more information in Setting Event Time Constraints. |
|
learn more about the information displayed in the packet view |
|
add an event to the clipboard so you can transfer it to the incidents at a later time |
The clipboard stores up to 25,000 events per user. For more information on the clipboard, see Using the Clipboard. |
mark an event reviewed to remove it from event views, but not the event database. |
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 |
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. |
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
On the packet view, you can view information about the packet in the Event Information section.
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.
The time that the packet was captured.
The event classification. For rule-based events, this corresponds to the rule classification. For other events, this is determined by the decoder or preprocessor.
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.
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.
For an inline deployment, the egress security zone of the packet that triggered the event. See Working with Security Zones.
The managed device where the access control policy was applied. See Managing Devices.
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.
The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface. See Configuring Sensing Interfaces.
For an inline set, the egress interface of the packet that triggered the event. See Configuring Sensing Interfaces.
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 of the packet that triggered the event. For ICMP traffic, where there is no port number, the system displays the ICMP type.
The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, the system displays the ICMP code.
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.
The host name, if present, extracted from the HTTP request Host header. This row displays the complete host name, up to 256 bytes. Click the expand arrow (
) 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.
The raw URI, if present, associated with the HTTP request packet that triggered the intrusion event. This row displays the complete URI, up to 2048 bytes. Click the expand arrow (
) 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.
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.
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.
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.
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.
For standard text rule events, expand Actions to take any of the following actions on the rule that triggered the event:
– view documentation for the revision of the rule
– change the state of the rule
– set a threshold for 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
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.
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.
For standard text rule events, click View Documentation to learn more about the rule revision that generated the event.
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.
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.
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.
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.
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
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:
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:
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:
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
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:
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:
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:
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
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.
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.
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.
The length of the frame in bytes.
The length of the captured frame in bytes.
Viewing Data Link Layer Information
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.
The MAC address for the destination host.
Note Ethernet can also use multicast and broadcast addresses as the destination address.
The MAC address for the source host.
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.
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
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.
Viewing IPv4 Network Layer Information
The following listing describes protocol-specific information that might appear in an IPv4 packet.
The Internet Protocol version number.
The number of bytes in the header, including any IP options. An IP header with no options is 20 bytes long.
The values for differentiated services that indicate how the sending host supports Explicit Congestion Notification (ECN):
–
0x0
— does not support ECN-Capable Transport (ECT)
–
0x3
— Congestion Experienced (CE)
The length of the IP packet, in bytes, minus the IP header.
The value that uniquely identifies an IP datagram sent by the source host. This value is used to trace fragments of the same datagram.
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
The value for the fragment offset from the beginning of the datagram.
The remaining number of hops that the datagram can make between routers before the datagram expires.
The transport protocol that is encapsulated in the IP datagram; for example, ICMP, IGMP, TCP, or UDP.
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.
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
The following listing describes protocol-specific information that might appear in an IPv6 packet.
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.
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.
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.
An 8-bit field identifying the type of header immediately following the IPv6 header, using the same values as the IPv4 Protocol field.
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.
Viewing Transport Layer Information
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:
Note Note that these examples discuss TCP, UDP, and ICMP packets; other protocols may also appear.
TCP Packet View
This section describes the protocol-specific information for a TCP packet.
The number that identifies the originating application protocol.
The number that identifies the receiving application protocol.
The value for the first byte in the current TCP segment, keyed to initial sequence number in the TCP stream.
In a response packet, the sequence number of the next packet to send.
The TCP acknowledgement, which is keyed to the sequence number of the previously accepted data.
The number of bytes in the header.
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
–
S
— synchronize sequence numbers to start a new connection
–
F
— the sender has finished sending data
The amount of unacknowledged data, in bytes, that the receiving host will accept.
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.
The position, if present, in the TCP segment where the urgent data ends. Used in conjunction with the
U
flag.
UDP Packet View
This section describes the protocol-specific information for a UDP packet.
The number that identifies the originating application protocol.
The number that identifies the receiving application protocol.
The combined length of the UDP header and data.
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
This section describes the protocol-specific information for an ICMP packet.
– 15 — information request (obsolete)
– 16 — information reply (obsolete)
The accompanying code for the ICMP message type. ICMP message types 3, 5, 11, and 12 have corresponding codes as described in RFC 792.
The indicator for whether the ICMP checksum is valid. If the checksum is invalid, the datagram may have been corrupted during transit.
Using Impact Levels to Evaluate Events
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.
The following table describes the possible values for the impact levels.
Neither the source nor the destination host is on a network that is monitored by network discovery. |
|||
|
|||
Either the source or the destination host is in the network map and one of the following is true: |
|||
Either the source or the destination host is in the network map and one of the following is true: |
|||
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:
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
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
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
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.
The following table describes the types of events that generate each GID.
Searching for Intrusion Events
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:
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
.
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.
–
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.
Specify the IP address used by the source host involved in the intrusion events.
Specify the IP address used by the destination host involved in the intrusion events.
Specify the source or destination IP address used by the host whose intrusion events you want to view.
Specify the country of the source host involved in the intrusion events.
Specify the country of the destination host involved in the intrusion events.
Specify the country of the source or destination host involved in the intrusion events you want to view.
Specify the continent of the source host involved in the intrusion events.
Specify the continent of the destination host involved in the intrusion events.
Specify the continent of the source or destination host involved in the intrusion events you want to view.
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.
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.
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.
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.
Specify the innermost VLAN ID associated with the packet that triggered the intrusion event.
Specify the Multiprotocol Label Switching label of the packet associated with the packet that triggered the intrusion event.
Specify all or part of the event message for the events you want to view.
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.
Specify the component that generated the events you want to view, as listed in Table 41-7.
Specify the Snort ID (SID) of the rule that generated the event or, optionally, specify the combination generator ID (GID) and SID of the rule, where the GID and SID are separated with a colon (:) in the format GID:SID. You can specify any of the values in the following table:
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.
Specify the User ID for a user logged in to the source host.
Specify the User ID for a user logged in to the destination host.
Specify the User ID for a user logged in to the source or destination host.
Type the name of the application protocol, which represents communications between hosts, detected in the traffic that triggered the intrusion event.
Type the name of the client application, which represents software running on the monitored host detected in the traffic that triggered the intrusion event.
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.
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.
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.
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.
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.
Type the name of an interface associated with the packet that triggered the event; see Configuring Sensing Interfaces.
Type the name of the intrusion policy associated with the event; see Managing Intrusion Policies.
Type the name of the access control policy associated with the event; see Managing Access Control Policies.
Type the name of the access control rule associated with the event; see Tuning Traffic Flow Using Access Control Rules.
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.
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.
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.
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.
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.
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.
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.
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.
Type any of the following keywords to view intrusion events for encrypted traffic that the system failed to decrypt for the reason specified:
–
Session Undecryptable in Passive Mode
–
Pending Server Name Category Lookup
–
Pending Common Name Category Lookup
–
Network Parameters Unavailable
–
Invalid Server Certificate Handle
–
Server Certificate Fingerprint Unavailable
–
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
This column does not appear in the intrusion events table view.
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.
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.
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.
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:
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:
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.
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
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
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:
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 .
Step 3 You have the following options:
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.
Deleting Events from the Clipboard
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:
Step 1 Select Analysis > Intrusions > Clipboard .
Step 2 You have the following options:
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.
Feedback