Working with Intrusion Events
The following topics describe how to work with intrusion events.
About Intrusion Events
The Firepower 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 [sometimes called by a legacy term, "IPS 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 Firepower Management 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.
Tools for Reviewing and Evaluating Intrusion Events
You can use the following tools to review intrusion events and evaluate whether they are important in the context of your network environment and your security policies.
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
External tools for managing and analyzing data. You can send data to those tools using syslog or eStreamer. For more information, see Event Analysis Using External Tools
Additionally, you can use publicly-available information such as the predefined resources on the Analysis > Advanced > Contextual Cross-Launch page to learn more about malicious entities.
To search for a particular message string and retrieve documentation for the rule that generated an event, see //www.snort.org/rule_docs/.
License Requirements for Intrusion Events
FTD License
Threat
Classic License
Protection
Requirements and Prerequisites for Intrusion Events
Model Support
Any.
Supported Domains
Any
User Roles
Admin
Intrusion Admin
Viewing Intrusion Events
You view an intrusion event to determine whether there is a threat to your network security.
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.
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.
In a multidomain deployment, you can view data for the current domain and for any descendant domains. You cannot view data from higher level or sibling domains.
Procedure
| Step 1 | Choose . |
| Step 2 | You have the following choices:
|
About Intrusion Event Fields
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.
You can view intrusion event data in the Firepower Management Center web interface at Analysis > Intrusions > Events or emit data from certain fields as syslog messages for consumption by an external tool. Syslog fields are indicated in the list below; fields without a listed syslog equivalent are not available in syslog messages.
When searching intrusion events, keep in mind that the information available for any individual event can vary depending on how, why, and when system logged the event. For example, only intrusion events triggered on decrypted traffic contain TLS/SSL information.
Note | In the Firepower Management Center web interface, some fields in the table view of intrusion events are disabled by default. To enable a field for the duration of your session, expand the search constraints, then click the column name under Disabled Columns. |
Intrusion Event Fields
Access Control Policy [Syslog: ACPolicy]
The access control policy associated with the intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event is enabled.
Access Control Rule [Syslog: AccessControlRuleName]
The access control rule that invoked the intrusion policy that generated the event. 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.
This field is empty [or, for syslog messages, omitted] if there is:
No associated rule/default action: Intrusion inspection was associated with neither an access control rule nor the default action, for example, if the packet was examined by the intrusion policy specified to handle packets that must pass before the system can determine which rule to apply. [This policy is specified in the Advanced tab of the access control policy.]
No associated connection event: The connection event logged for the session has been purged from the database, for example, if connection events have higher turnover than intrusion events.
Application Protocol [Syslog: ApplicationProtocol]
The application protocol, if available, which represents communications between hosts detected in the traffic that triggered the intrusion event.
Application Protocol Category and Tag
Criteria that characterize the application to help you understand the application's function.
Application Risk
The risk associated with detected applications in the traffic that triggered the intrusion event: Very High, High, Medium, Low, and Very Low. Each type of application detected in a connection has an associated risk; this field displays the highest risk of those.
Business Relevance
The business relevance associated with detected applications in the traffic that triggered the intrusion event: Very High, High, Medium, Low, and Very Low. Each type of application detected in a connection has an associated business relevance; this field displays the lowest [least relevant] of those.
Classification [Syslog: Classification]
The classification where the rule that generated the event belongs.
See a list of possible classification values in Intrusion Event Details.
When searching this field, 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.
Client [Syslog: Client]
The client application, if available, which represents software running on the monitored host detected in the traffic that triggered the intrusion event.
Client Category and Tag
Criteria that characterize the application to help you understand the application's function.
Connection Counter [Syslog Only]
A counter that distinguishes one connection from another simultaneous connection. This field has no significance on its own.
The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter.
Connection Instance ID [Syslog Only]
The Snort instance that processed the connection event. This field has no significance on its own.
The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter.
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. This field is not searchable.
CVE ID
This field is a search field only.
Search by the identification number associated with the vulnerability in MITRE’s Common Vulnerabilities and Exposures [CVE] database [//cve.mitre.org/].
Destination Continent
The continent of the receiving host involved in the intrusion event.
Destination Country
The country of the receiving host involved in the intrusion event.
Destination IP [Syslog: DstIP]
The IP address used by the receiving host involved in the intrusion event.
See also A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields.
Destination Port / ICMP Code [Syslog: DstPort, ICMPCode]
The port number for the host receiving the traffic. For ICMP traffic, where there is no port number, this field displays the ICMP code.
Destination User
The username associated with the Responder IP of the connection event. This host may or may not be the host receiving the exploit. This value is typically known only for users on your network.
.
See also A Note About Initiator/Responder, Source/Destination, and Sender/Receiver Fields.
Device
The managed device where the access control policy was deployed.
DeviceUUID [Syslog Only]
The unique identifier of the device that generated an event.
The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter.
Domain
The domain of the device that detected the intrusion. This field is only present if you have ever configured the Firepower Management Center for multitenancy.
Egress Interface [Syslog: EgressInterface]
The egress interface of the packet that triggered the event. This interface column is not populated for a passive interface.
Egress Security Zone [Syslog: EgressZone]
The egress security zone of the packet that triggered the event. This security zone field is not populated in a passive deployment.
Egress Virtual Router
In networks using virtual routing, the name of the virtual router through which traffic exited the network.
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.
Email Headers
This field is a search field only.
The data that was extracted from the email header.
To associate email headers with intrusion events for SMTP traffic, you must enable the SMTP preprocessor Log Headers option.
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.
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.
First Packet Time [Syslog Only]
The time the system encountered the first packet.
The following fields collectively uniquely identify the connection event associated with a particular intrusion event: DeviceUUID, First Packet Time, Connection Instance ID, and Connection Counter.
Generator
The component that generated the event.
See also information about the following intrusion event fields: GID, Message, and Snort ID.
GID [Syslog Only]
Generator ID; the ID of the component that generated the event.
See also information about the following intrusion event fields: Generator, Message, and Snort ID.
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 associate host names with intrusion events for HTTP client traffic, you must enable the HTTP Inspect preprocessor Log Hostname option.
In table views, 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.
HTTP Response Code [Syslog: HTTPResponse]
The HTTP status code sent in response to a client's HTTP request over the connection that triggered the event. It indicates the reason behind sucessful and failed HTTP request.
For more details about HTTP response codes, see RFC 2616, Section 10.
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 associate URIs with intrusion events for HTTP traffic, you must enable the HTTP Inspect preprocessor Log URI option.
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.
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.
Impact
The impact level in this field indicates the correlation between intrusion data, network discovery data, and vulnerability information.
When searching this field, do not specify impact icon colors or partial strings. For example, do not use blue, level 1, or 0. 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, Impact Level 4
Because no operating system information is available for hosts added to the network map from NetFlow data, the system cannot assign Vulnerable [impact level 1: red] impact levels for intrusion events involving those hosts. In such cases, use the host input feature to manually set the operating system identity for the hosts.
Ingress Interface [Syslog: IngressInterface]
The ingress interface of the packet that triggered the event. Only this interface column is populated for a passive interface.
Ingress Security Zone [Syslog: IngressZone]
The ingress security zone or tunnel zone of the packet that triggered the event. Only this security zone field is populated in a passive deployment.
Ingress Virtual Router
In networks using virtual routing, the name of the virtual router through which traffic entered the network.
Inline Result [Syslog: InlineResult]
In workflow and table views, this field displays one of the following:
Table 1. Inline Result Field Contents in Workflow and Table ViewsThe system dropped the packet that triggered the rule. | |
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. | |
IPS may have transmitted or delivered the packet to the destination, but the connection that contained this packet is now blocked. | |
No icon [blank] | The triggered rule was not set to Drop and Generate Events |
The following table lists the possible reasons for the inline results — Would have dropped and Partially dropped.
Would Have Dropped | Interface in Passive or Tap mode | You have configured the interfaces in inline tap or passive mode. |
Intrusion Policy in "Detection" Inspection Mode | You have set the inspection mode in the intrusion policy to Detection. | |
Connection Timed Out | The Snort inspection engine has suspended the inspection as the TCP/IP connection timed out. | |
Partially Dropped | Connection Closed [0x01] | While creating a new flow, if the allocated flows are more than the allowed number of flows, the Snort inspection engine prunes the least recently used flows. |
Connection Closed [0x02] | When reloading the Snort inspection engine causes a memory adjustment, the engine prunes the least recently used flows. | |
Connection Closed [0x04] | When the Snort inspection engine is gracefully shutting down, the engine purges all the active flows. |
In a passive deployment, the system does not drop packets, including when an inline interface is in tap mode, regardless of the rule state or the inline drop behavior of the intrusion policy.
When searching this field, enter either of the following:
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.
partially dropped to specify whether the packet is transmitted or delivered to the destination, but the connection that contained this packet is now blocked.
Intrusion Policy [Syslog: IntrusionPolicy]
The intrusion policy where the intrusion, preprocessor, or decoder rule that generated the event was enabled. You can choose an intrusion policy as the default action for an access control policy, or you can associate an intrusion policy with an access control rule.
IOC [Syslog: NumIOC]
Whether the traffic that triggered the intrusion event also triggered an indication of compromise [IOC] for a host involved in the connection.
When searching this field, specify triggered or n/a.
Message [Syslog: 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.
The Generator and Snort IDs [GID and SID] and the SID version [Revision] are appended in parentheses to the end of each message in the format of numbers separated by colons [GID:SID:version]. For example [1:36330:2].
MPLS Label [Syslog: MPLS_Label]
The Multiprotocol Label Switching label associated with the packet that triggered the intrusion event.
Network Analysis Policy [Syslog: NAPPolicy]
The network analysis policy, if any, associated with the generation of the event.
This field 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.
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.
Priority [Syslog: Priority]
The event priority as determined by the Cisco Talos Intelligence Group [Talos]. 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.
Protocol [Syslog: Protocol]
In the Firepower Management Center web interface, this field is a search field only.
The name or number of the transport protocol used in the connection as listed in //www.iana.org/assignments/protocol-numbers. This is the protocol associated with the source and destination port/ICMP column.
Reviewed By
The name of the user who reviewed the event. When searching this field, you can enter unreviewed to search for events that have not been reviewed.
Revision [Syslog Only]
The version of the signature that was used to generate the event.
See also information about the following intrusion event fields: Generator, GID, Message, SID, and Snort ID.
Security Context [Syslog: Context]
The metadata identifying the virtual firewall group through which the traffic passed. The system only populates this field for ASA FirePOWER in multiple context mode.
SID [Syslog Only]
The signature ID [also known as the Snort ID] of the rule that generated the event.
See also information about the following intrusion event fields: Generator, GID, Message, Revision, and Snort ID.
Snort ID
This field is a search field only.
[For the syslog field, see SID.]
When performing your search: 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:
Table 2. Snort ID Search Valuesa 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 | Intrusions > Events > Edit Search Supported Platforms: All. |