FireSIGHT System User Guide Version 5.4.1

Due to memory limitations, some device models perform URL filtering with a smaller, less granular, set of categories and reputations. For example, if a parent domain's subsites have different URL categories and reputations, some devices may use the parent site's data for all subsites. These devices include the 7100 Family and the following ASA FirePOWER models: ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, ASA 5516-X, and the ASA 5525-X.

For virtual devices, see the installation guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.

When you create either correlation rule trigger criteria, host profile qualifications, user qualifications, or connection trackers, the syntax varies but the mechanics remain consistent. For more information, See Understanding Rule Building Mechanics.

To create a correlation rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule .

The Create Rule page appears.

Step 3 Provide basic rule information, such as the rule name, description, and group.

See Providing Basic Rule Information.

Step 4 Specify the basic criteria on which you want the rule to trigger.

See Specifying Correlation Rule Trigger Criteria.

Step 5 Optionally, add a host profile qualification to the rule.

See Adding a Host Profile Qualification.

Step 6 Optionally, add a connection tracker to the rule.

See Constraining Correlation Rules Using Connection Data Over Time.

Step 7 Optionally, add a user qualification to the rule.

See Adding a User Qualification.

Step 8 Optionally, add an inactive period or snooze period (or both) to the rule.

See Adding Snooze and Inactive Periods.

Step 9 Click Save Rule .

The rule is saved. You can now use the rule within correlation policies or within other correlation rules that trigger on the same event type.

Providing Basic Rule Information

License: Any

You must give each correlation rule a name and, optionally, a short description. You can also place the rule in a rule group.

To provide basic rule information:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule .

The Create Rule page appears.

Step 3 On the Create Rule page, in the Rule Name field, type a name for the rule.

Step 4 In the Rule Description field, type a description for the rule.

Step 5 Optionally, select a group for the rule from the Rule Group drop-down list.

For more information on rule groups, see Managing Rules for Correlation Policies.

Step 6 Continue with the procedure in the next section, Specifying Correlation Rule Trigger Criteria.

Specifying Correlation Rule Trigger Criteria

License: feature dependent

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

A simple correlation rule requires only that an event of a certain type occurs; you do not need to provide more specific conditions. For example, correlation rules based on traffic profile changes do not require any conditions at all. In contrast, correlation rules may be complex, with multiple nested conditions. For example, the rule shown in the following graphic comprises criteria that direct the rule to trigger if an IP address that is not in the 10.x.x.x subnet transmits an IGMP message.

Due to memory limitations, some device models perform URL filtering with a smaller, less granular, set of categories and reputations. For example, if a parent URL's subsites have different URL categories and reputations, some devices may use the parent URL's data for all subsites. As a specific example, the system might evaluate mail.google.com using the google.com category and reputation. Affected devices include the 71xx Family and the following ASA models: ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, ASA5512-X, ASA5515-X, ASA5516-X, and ASA5525-X.

Note When building a condition based on events, you can add a correlation rule trigger criterion only if your device can collect the information required for the condition, and your Defense Center can manage that information. For example, because neither Series 2 devices nor the DC500 Defense Center support SSL inspection, URL filtering by category or reputation, or Security Intelligence, you cannot configure event conditions on those appliances based on those features. For more information, see Creating Rules for Correlation Policies.

To specify correlation rule trigger criteria:

Access: Admin/Discovery Admin

Step 1 Select the type of event on which you want to base your rule.

When you build a correlation rule, you must first select the type of event on which you want to base your rule. You have a few options under Select the type of event for this rule :

• Select an intrusion event occurs to trigger your rule when a specific intrusion event occurs.
• Select a Malware event occurs to trigger the rule when a specific malware event occurs.
• Select a discovery event occurs to trigger the rule when a specific discovery event occurs. When triggering a correlation rule on a discovery event, you must also choose the type of event you want to use. You can choose from a subset of the discovery events described in Understanding Discovery Event Types; you cannot, for example, trigger a correlation rule on a hops change. You can, however, choose there is any type of event to trigger the rule when any kind of discovery event occurs.
• Select user activity is detected to trigger the rule when a new user is detected or a user logs in to a host.
• Select a host input event occurs to trigger the rule when a specific host input event occurs. When triggering a correlation rule on a host input event, you must also choose the type of event you want to use. You can choose from a subset of the events described in Understanding Host Input Event Types.
• Select a connection event occurs to trigger the rule when connection data meets specific criteria. When triggering a correlation rule on a connection event, you must also choose whether you want to use connection events that represent the beginning or the ending of the connection, or either.
• Select a traffic profile changes to trigger the correlation rule when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile.

Step 2 Specify the rule’s conditions.

The syntax you can use within correlation rule trigger criteria conditions varies depending on the base event you chose in step 1 , but the mechanics are the same. For more information, see Understanding Rule Building Mechanics.

The syntax you can use to build conditions is described in the following sections:

• Syntax for Intrusion Events
• Syntax for Malware Events
• Syntax for Discovery Events
• Syntax for User Activity Events
• Syntax for Host Input Events
• Syntax for Connection Events
• Syntax for Traffic Profile Changes

Tip You can nest rules that share the base event type you specified in step 1. For example, if you create a new rule based on the detection of an open TCP port, the trigger criteria for the new rule could include rule “MyDoom Worm” is true and rule “Kazaa (TCP) P2P” is true.

Step 3 Optionally, continue with the procedures in the following sections:

• Adding a Host Profile Qualification
• Constraining Correlation Rules Using Connection Data Over Time
• Adding a User Qualification
• Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Intrusion Events

License: Protection

The following table describes how to build a correlation rule condition when you choose an intrusion event as the base event.

When you build rule conditions, you should make sure that your network traffic can trigger the rules. The information available for any individual intrusion event depends on several factors, including the detection method and logging method. For more information, see Understanding Intrusion Events.

Syntax for Malware Events

License: Any or Malware

Supported Devices: feature dependent

Supported Defense Centers: feature dependent

The syntax for correlation rule conditions based on malware events depends on whether the event is reported by an endpoint-based malware agent, detected by a managed device, or detected by a managed device and retrospectively identified as malware.

Note that because Series 2 and Cisco NGIPS for Blue Coat X-Series devices and the DC500 Defense Center do not support network-based malware protection, these appliances do not support triggering a correlation rule on a malware event based on network-based malware data or retrospective network-based malware data.

When you build rule conditions, you should make sure that your network traffic can trigger the rules. The information available for any individual connection or connection summary event depends on several factors, including the detection method, the logging method, and event type. For more information, see Understanding the Malware Events Table.

The following table describes how to build a correlation rule condition when you choose a malware event as the base event.

Syntax for Discovery Events

License: FireSIGHT

If you base your correlation rule on a discovery event, you must first choose the type of event you want to use from a drop-down list. The following table lists the events you can choose as trigger criteria from the drop-down list, cross-referenced with their corresponding event types. For detailed descriptions of discovery event types, see Understanding Discovery Event Types.

Syntax for User Activity Events

License: FireSIGHT

If you base your correlation rule on user activity, you must first choose the type of user activity you want to use from a drop-down list, either:

• a user logged into a host, or
• a new user identity was detected

After you choose the user activity type, you can build correlation rule conditions as described in the table below. Depending on the type of user activity you choose, you can build conditions using subsets of the criteria in the following table; for correlation rules triggered on new user identity, you cannot specify an IP address.

Syntax for Host Input Events

License: FireSIGHT

If you base your correlation rule on a host input event, you must first choose the type of host input event you want to use from a drop-down list. The following table lists the events you can choose as trigger criteria from the drop-down list, cross-referenced with their corresponding host input event types. For detailed descriptions of host input event types, see Understanding Host Input Event Types.

Syntax for Connection Events

License: Any

If you base your correlation rule on a connection event, you must first choose whether you want to evaluate events that represent the beginning or ending of the connection, or either the beginning or the end. After you choose the connection event type, you can build correlation rule conditions as described in the Syntax for Connection Events table.

When you build rule conditions, you should make sure that your network traffic can trigger the rules. The information available for any individual connection or connection summary event depends on several factors, including the detection method, the logging method, and event type. For more information, see Information Available in Connection and Security Intelligence Events.

Syntax for Traffic Profile Changes

License: Any

If you base your correlation rule on a traffic profile change, the rule triggers when network traffic deviates from your normal network traffic pattern as characterized in an existing traffic profile. For information on how to build a traffic profile, see Creating Traffic Profiles.

You can trigger the rule based on either raw data or on the statistics calculated from the data. For example, you could write a rule that triggers if the amount of data traversing your network (measured in bytes) suddenly spikes, which could indicate an attack or other security policy violation. You could specify that the rule trigger if either:

• the number of bytes traversing your network spikes above a certain number of standard deviations above or below the mean amount of traffic

Note that to create a rule that triggers when the number of bytes traversing your network falls outside a certain number of standard deviations (whether above or below), you must specify upper and lower bounds, as shown in the following graphic.

 

To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations above the mean, use only the first condition shown in the graphic.

To create a rule that triggers when the number of bytes traversing is greater than a certain number of standard deviations below the mean, use only the second condition.

• the number of bytes traversing your network spikes above a certain number of bytes

You can select the use velocity data check box (see Changing the Graph Type), to trigger the correlation rule based on rates of change between data points. If you wanted to use velocity data in the above example, you could specify that the rule triggers if either:

• the change in the number of bytes traversing your network spikes above or below a certain number of standard deviations above the mean rate of change
• the change in the number of bytes traversing your network spikes above a certain number of bytes

The following table describes how to build a condition in a correlation rule when you choose a traffic profile change as the base event. If your traffic profile uses connection data exported by NetFlow-enabled devices, see Differences Between NetFlow and FireSIGHT Data to learn about how the detection method can affect the data used to create your traffic profile.

Adding a Host Profile Qualification

License: FireSIGHT

If you are using a connection, intrusion, discovery, user activity, or host input event to trigger your correlation rule, you can constrain the rule based on the host profile of a host involved in the event. This constraint is called a host profile qualification .

Note You cannot add a host profile qualification to a correlation rule that triggers on a malware event, traffic profile change, or on the detection of a new IP host.

For example, you could constrain a correlation rule so that it triggers only when a Microsoft Windows host is the target of the offending traffic, because only Microsoft Windows computers are vulnerable to the vulnerability the rule is written for. As another example, you could constrain a correlation rule so that it triggers only when the host is out of compliance with a white list.

To match against implied or generic clients, create a host profile qualification based on the application protocol used by the server responding to the client. When the client list on a host that acts as the initiator or source of a connection includes an application protocol name followed by client , that client may actually be an implied client. In other words, the system reports that client based on server response traffic that uses the application protocol for that client, not on detected client traffic.

For example, if the system reports HTTPS client as a client on a host, create a host profile qualification for Responder Host or Destination Host where Application Protocol is set to HTTPS , because HTTPS client is reported as a generic client based on the HTTPS server response traffic sent by the responder or destination host.

Note that to use a host profile qualification, the host must exist in the network map and the host profile property you want to use as a qualification must already be included in the host profile. For example, if you configure a correlation rule to trigger when an intrusion event is generated for a host running Windows, the rule only triggers if the host is already identified as Windows when the intrusion event is generated.

To add a host profile qualification:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Rule .

The Create Rule page appears.

Step 3 On the Create Rule page, click Add Host Profile Qualification .

The Host Profile Qualification section appears.

Tip To remove a host profile qualification, click Remove Host Profile Qualification.

Step 4 Build the host profile qualification’s conditions.

You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions.

The syntax you can use to build conditions is described in Syntax for Host Profile Qualifications.

Step 5 Optionally, continue with the procedures in the following sections:

• Constraining Correlation Rules Using Connection Data Over Time
• Adding a User Qualification
• Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Host Profile Qualifications

License: FireSIGHT

When you build a host profile qualification condition, you must first select the host you want to use to constrain your correlation rule. The host you can choose depends on the type of event you are using to trigger the rule, as follows:

• If you are using a connection event, select Responder Host or Initiator Host .
• If you are using an intrusion event, select Destination Host or Source Host .
• If you are using a discovery event, host input event, or user activity, select Host .

After you select the host type, you continue building your host profile qualification condition, as described in the following table.

Note that although you can configure the network discovery policy to add hosts to the network map based on data exported by NetFlow-enabled devices, the available information about these hosts is limited. For example, there is no operating system data available for these hosts, unless you provide it using the host input feature. In addition, if you use connection data exported by NetFlow-enabled devices, keep in mind that NetFlow records do not contain information about which host is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

Constraining Correlation Rules Using Connection Data Over Time

License: FireSIGHT

A connection tracker constrains a correlation rule so that after the rule’s initial criteria are met (including host profile and user qualifications), the system begins tracking certain connections. The Defense Center generates a correlation event for the rule if the tracked connections meet additional criteria gathered over a time period that you specify.

If you are using a connection, intrusion, discovery, user activity, or host input event to trigger your correlation rule, you can add a connection tracker to the rule. You cannot add a connection tracker to a rule that triggers on a malware event or traffic profile change.

Tip Connection trackers typically monitor very specific traffic and, when triggered, run only for a finite, specified time. Compare connection trackers with traffic profiles, which typically monitor a broad range of network traffic and run persistently; see Creating Traffic Profiles.

There are two ways a connection tracker can generate an event, depending on how you construct the tracker:

Connection Trackers That Fire Immediately When Conditions Are Met

You can configure a connection tracker so that the correlation rule fires as soon as network traffic meets the tracker’s conditions. When this happens, the system stops tracking connections for this connection tracker instance, even if the timeout period has not expired. If the same type of policy violation that triggered the correlation rule occurs again, the system creates a new connection tracker.

If, on the other hand time expires before network traffic meets the conditions in the connection tracker, the Defense Center does not generate a correlation event, and also stops tracking connections for that rule instance.

For example, a connection tracker can serve as a kind of event threshold by generating a correlation event only if a certain type of connection occurs more than a specific number of times within a specific time period. Or, you can generate a correlation event only if the system detects excessive data transfer after an initial connection.

Connection Trackers That Fire at The End of The Timeout Period

You can configure a connection tracker so that it relies on data collected over the entire timeout period, and therefore cannot fire until the end of the timeout period.

For example, if you configure a connection tracker to fire if you detect fewer than a certain number of bytes being transferred during a certain time period, the system waits until that time period passes and then generates an event if network traffic met that condition.

For more information, see the following sections:

• Adding a Connection Tracker
• Syntax for Connection Trackers
• Syntax for Connection Tracker Events
• Example: Excessive Connections From External Hosts
• Example: Excessive BitTorrent Data Transfers

Adding a Connection Tracker

License: FireSIGHT

A connection tracker constrains a correlation rule so that after its initial criteria are met (including host profile and user qualifications), the system begins tracking certain connections. The Defense Center generates a correlation event for the rule if the tracked connections meet additional criteria gathered over a time period that you specify.

When you configure a connection tracker, you must specify:

• which connections you want to track
• the conditions that the connections you are tracking must meet for the Defense Center to generate a correlation event
• the maximum duration of the connection tracker, that is, the time period during which the conditions you specify must be met to generate a correlation event

Tip You can add a connection tracker to a simple correlation rule that requires only that any connection, intrusion, discovery, user identity, or host input event occurs.

To add a connection tracker:

Access: Admin/Discovery Admin

Step 1 On the Create Rule page, click Add Connection Tracker .

The Connection Tracker section appears.

Tip To remove a connection tracker, click Remove Connection Tracker.

Step 2 Specify which connections you want to track by setting connection tracker criteria.

You can set connection tracker criteria by creating a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions.

See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions. The syntax you can use to build connection tracker conditions is described in Syntax for Connection Trackers.

Step 3 Based on the connections you decided to track in step 2 , describe when you want to generate a correlation event.

You can create a single, simple condition that describes when you want to generate an event, or you can create more elaborate constructs by combining and nesting conditions.

You must also specify the interval (in seconds, minutes, or hours) during which the conditions you specify must be met to generate a correlation event.

See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions. The syntax you can use to build connection tracker conditions is described in Syntax for Connection Tracker Events.

Step 4 Optionally, continue with the procedures in the following sections:

• Adding a User Qualification
• Adding Snooze and Inactive Periods

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for Connection Trackers

License: Any

The following table describes how to build a connection tracker condition that specifies the kind of connections you want to track.

You should keep in mind that connections detected by Cisco managed devices and connection data exported by NetFlow-enabled devices contain different information. For example, connections detected by managed devices do not contain TCP flag information. Therefore, if you want to specify that a connection event have a certain TCP flag to trigger a correlation rule, none of the connections detected by managed devices will trigger the rule.

As another example, NetFlow records do not contain information about which host in the connection is the initiator and which is the responder. When the system processes NetFlow records, it uses an algorithm to determine this information based on the ports each host is using, and whether those ports are well-known. For more information, see Differences Between NetFlow and FireSIGHT Data.

 

---

Tip To specify that the connection tracker track connections for a specific IP address or block of IP addresses, click switch to manual entry to manually specify the IP. Click switch to event fields to go back to using the IP address in the event.

---

Syntax for Connection Tracker Events

License: Any

The following table describes how to how to build a connection tracker condition that specifies when you want to generate a correlation event based on the connections you are tracking.

Example: Excessive Connections From External Hosts

Consider a scenario where you archive sensitive files on network 10.1.0.0/16, and where hosts outside this network typically do not initiate connections to hosts inside the network. An occasional connection initiated from outside the network might occur, but you have determined that when four or more connections are initiated within two minutes, there is cause for concern.

The rule shown in the following graphic specifies that when a connection occurs from outside the 10.1.0.0/16 network to inside the network, the system begins tracking connections that meet that criterion. The Defense Center then generates a correlation event if the system detects four connections (including the original connection) within two minutes that match that signature.

 

 

The following diagram shows how network traffic can trigger the above correlation rule.

 

In this example, the system detected a connection that met the basic conditions of the correlation rule, that is, the system detected a connection from a host outside the 10.1.0.0/16 network to a host inside the network. This created a connection tracker.

The connection tracker is processed in the following stages:

---

Step 1 The system starts tracking connections when it detects a connection from Host A outside the network to Host 1 inside the network.

Step 2 The system detects two more connections that match the connection tracker signature: Host B to Host 2 and Host C to Host 1.

Step 3 The system detects a fourth qualifying connection when Host A connects to Host 3 within the two-minute time limit. The rule conditions are met.

Step 4 The Defense Center generates a correlation event and the system stops tracking connections.

---

 

Example: Excessive BitTorrent Data Transfers

Consider a scenario where you want to generate a correlation event if the system detects excessive BitTorrent data transfers after an initial connection to any host on your monitored network.

The following graphic shows a correlation rule that triggers when the system detects the BitTorrent application protocol on your monitored network. The rule has a connection tracker that constrains the rule so that the rule triggers only if hosts on your monitored network (in this example, 10.1.0.0/16) collectively transfer more than 7MB of data (7340032 bytes) via BitTorrent in the five minutes following the initial policy violation.

The following diagram shows how network traffic can trigger the above correlation rule.

In this example, the system detected the BitTorrent TCP application protocol on two different hosts: Host 1 and Host 2. These two hosts transmitted data via BitTorrent to four other hosts: Host A, Host B, Host C, and Host D.

This connection tracker is processed in the following stages:

Step 1 The system starts tracking connections at the 0-second marker when the system detects the BitTorrent application protocol on Host 1.

Note that the connection tracker will expire if the system does not detect 7MB of BitTorrent TCP data being transmitted in the next 5 minutes (by the 300-second marker).

Step 2 At 5 seconds, Host 1 has transmitted 3MB of data that matches the signature:

• 1MB from Host 1 to Host A, at the 1-second marker (1MB total BitTorrent traffic counted towards fulfilling the connection tracker)
• 2MB from Host 1 to Host B, at the 5-second marker (3MB total)

Step 3 At 7 seconds, the system detects the BitTorrent application protocol on Host 2 and starts tracking BitTorrent connections for that host as well.

Step 4 At 20 seconds, the system has detected additional data matching the signature being transmitted from both Host 1 and Host 2:

• 1MB from Host 2 to Host A, at the 10-second marker (4MB total)
• 2MB from Host 1 to Host C, at the 15-second marker (6MB total)
• 1MB from Host 2 to Host B, at the 20-second marker (7MB total)

Although Host 1 and Host 2 have now transmitted a combined 7MB of BitTorrent data, the rule does not trigger because the total number of bytes transmitted must be more than 7MB ( Responder Bytes are greater than 7340032 ).

At this point, if the system were to detect no additional BitTorrent transfers for the remaining 280 seconds in the tracker’s timeout period, the tracker would expire and the Defense Center would not generate a correlation event.

Step 5 However, at 30 seconds, the system detects another BitTorrent transfer:

• 2MB from Host 1 to Host D at the 30-second marker (9MB total)

The rule conditions are met.

Step 6 The Defense Center generates a correlation event.

The Defense Center also stops tracking connections for this connection tracker instance, even though the 5-minute period has not expired. If the system detects a new connection using the BitTorrent TCP application protocol at this point, it will create a new connection tracker.

Note that the Defense Center generates the correlation event after Host 1 transmits the entire 2MB to Host D, because it does not tally connection data until the session terminates.

Adding a User Qualification

License: FireSIGHT

If you are using a connection, intrusion, discovery, or host input event to trigger your correlation rule, you can constrain the rule based on the identity of a user involved in the event. This constraint is called a user qualification . You cannot add a user qualification to a correlation rule that triggers on a traffic profile change or on the detection of user activity.

For example, you could constrain a correlation rule so that it triggers only when the identity of the source or destination user is one from the sales department.

To add a user identity qualification:

Access: Admin/Discovery Admin

Step 1 On the Create Rule page, click Add User Qualification .

The User Identity Qualification section appears.

Tip To remove a user qualification, click Remove User Qualification.

Step 2 Build the user qualification’s conditions.

You can create a single, simple condition, or you can create more elaborate constructs by combining and nesting conditions. See Understanding Rule Building Mechanics for information on how to use the web interface to build conditions.

The syntax you can use to build conditions is described in Syntax for User Qualifications.

Step 3 Optionally, continue with Adding Snooze and Inactive Periods.

If you are finished building the correlation rule, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

Syntax for User Qualifications

License: FireSIGHT

When you build a user qualification condition, you must first select the identity you want to use to constrain your correlation rule. The identity you can choose depends on the type of event you are using to trigger the rule, as follows:

• If you are using a connection event, select Identity on Initiator or Identity on Responder .
• If you are using an intrusion event, select Identity on Destination or Identity on Source .
• If you are using a discovery event, select Identity on Host .
• If you are using a host input event, select Identity on Host .

After you select the user type, you continue building your user qualification condition, as described in the following table.

The Defense Center obtains certain information about users, including first and last names, department, telephone number, and email address, from an optional Defense Center-LDAP server connection; see Using User Agents to Report Active Directory Logins. This information may not be available for all users in the database.

Adding Snooze and Inactive Periods

License: Any

You can configure snooze periods in correlation rules. When a correlation rule triggers, a snooze period instructs the Defense Center to stop firing that rule for a specified interval, even if the rule is violated again during the interval. When the snooze period has elapsed, the rule can trigger again (and start a new snooze period).

For example, you may have a host on your network that should never generate traffic. A simple correlation rule that triggers whenever the system detects a connection involving that host may create multiple correlation events in a short period of time, depending on the network traffic to and from the host. To limit the number of correlation events exposing your policy violation, you can add a snooze period so that the Defense Center generates a correlation event only for the first connection (within a time period that you specify) that the system detects involving that host.

You can also set up inactive periods in correlation rules. During inactive periods, the correlation rule will not trigger. You can set up inactive periods to recur daily, weekly, or monthly. For example, you might perform a nightly Nmap scan on your internal network to look for host operating system changes. In that case, you could set a daily inactive period on the affected correlation rules for the time and duration of your scan so that those rules do not trigger erroneously.

The following graphic shows a portion of a correlation rule that is configured with a snooze period and an inactive period.

 

To add a snooze period:

Access: Admin/Discovery Admin

---

Step 1 On the Create Profile page, under Rule Options , specify the interval that the Defense Center should wait to trigger a rule again, after the rule triggers.

---

Tip To remove a snooze period, specify an interval of 0 (seconds, minutes, or hours).

---

To add an inactive period:

Access: Admin/Discovery Admin

---

Step 1 On the Create Profile page, under Rule Options , click Add Inactive Period .

Step 2 Using the drop-down lists and text field, specify when and how often you want the Defense Center to refrain from evaluating network traffic against the correlation rule.

---

Tip To delete an inactive period, click the delete icon () next to the inactive period you want to delete.

---

When you are finished adding snooze and inactive periods, continue with step 9 of the procedure in Creating Rules for Correlation Policies to save the rule.

---

 

Understanding Rule Building Mechanics

License: Any

You build correlation rules, connection trackers, user qualifications, and host profile qualifications by specifying the conditions under which they trigger. You can create simple conditions, or you can create more elaborate constructs by combining and nesting conditions.

For example, if you want to generate a correlation event every time a new host is detected, you can create a very simple rule with no conditions, as shown in the following graphic.

If you wanted to further constrain the rule and generate an event only if that new host was detected on the 10.4.x.x network, you can add a single condition, as shown in the following graphic.

But the following rule, which detects SSH activity on a non-standard port on the 10.4.x.x network and the 192.168.x.x network, has four conditions, with the bottom two constituting a complex condition.

 

The syntax you can use within conditions varies depending on the element you are creating, but the mechanics are the same.

---

Caution Evaluating complex correlation rules that trigger on frequently occurring events can degrade Defense Center performance. For example, a multi-condition rule that the Defense Center must evaluate against every connection logged by the system can cause resource overload.

---

For more information on condition building, see:

• Building a Single Condition
• Adding and Linking Conditions
• Using Multiple Values in a Condition

Building a Single Condition

License: Any

Most conditions have three parts: a category , an operator , and a value ; some conditions are more complex and contain several categories, each of which may have their own operators and values.

For example, the following correlation rule triggers if a new host is detected on the 10.4.x.x network. The category of the condition is IP Address , the operator is is in , and the value is 10.4.0.0/16 .

 

 

To build the correlation rule trigger criteria in the example above:

Access: Admin/Discovery Admin

---

Step 1 Begin building a correlation rule.

For more information, see Creating Rules for Correlation Policies.

Step 2 On the Create Rule page, under Select the type of event for this rule , select a discovery event occurs , then select a new IP host is detected from the drop-down list.

Step 3 Start building the rule’s single condition by selecting IP Address from the first (or category ) drop-down list.

Step 4 Select is in from the operator drop-down list that appears.

---

Tip When the category represents an IP address, choosing is in or is not in as the operator allows you to specify whether the IP address is in or is not in a block of IP addresses, as expressed in special notation such as CIDR. For information on using IP address notation in the FireSIGHT System, see IP Address Conventions.

---

Step 5 Type 10.4.0.0/16 in the text field.

In contrast, the following host profile qualification is more complex; it constrains a correlation rule such that the rule triggers only if the host involved in the discovery event on which the rule is based is running a version of Microsoft Windows.

 

---

 

To build the host profile qualification in the example above:

Access: Admin/Discovery Admin

---

Step 1 Build a correlation rule that triggers on an discovery event.

For more information, see Creating Rules for Correlation Policies.

Step 2 On the Create Rule page, click Add Host Profile Qualification .

The Host Profile Qualification section appears.

Step 3 Under Host Profile Qualification , in the first condition, specify the host whose host profile you want to use to constrain your correlation rule.

Because this host profile qualification is part of a correlation rule based on an discovery event, the only available category is Host .

Step 4 Begin specifying the details of the operating system of the host by choosing the Operating System category.

Three subcategories appear: OS Vendor , OS Name , and OS Version .

Step 5 To specify that the host can be running any version of Microsoft Windows, use the same operator for all three subcategories: is .

Step 6 Finally, specify the values for the subcategories.

Select Microsoft as the value for OS Vendor , Windows as the value for OS Name , and leave any as the value for OS Version .

---

 

Note that the categories you can choose from depend on whether you are building correlation rule triggers, a host profile qualification, a connection tracker, or a user qualification. Within correlation rule triggers, the categories further depend on what kind of event is the basis for your correlation rule.

In addition, a condition’s available operators depend on the category you choose. Finally, the syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you must type the value in a text field. Other times, you can pick a value from a drop-down list.

---

Note Where the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For more information, see Using Multiple Values in a Condition.

---

For more information on the syntax for building correlation rule trigger criteria, see:

• Syntax for Intrusion Events
• Syntax for Malware Events
• Syntax for Discovery Events
• Syntax for User Activity Events
• Syntax for Host Input Events
• Syntax for Connection Events
• Syntax for Traffic Profile Changes

For more information on the syntax for building host profile qualifications, user qualifications, and connection trackers, see:

• Syntax for Host Profile Qualifications
• Syntax for Connection Trackers
• Syntax for Connection Tracker Events
• Syntax for User Qualifications

Adding and Linking Conditions

License: Any

You can create simple correlation rule triggers, connection trackers, host profile qualifications, and user qualifications, or you can create more elaborate constructs by combining and nesting conditions.

When your construct includes more than one condition, you must link them with an AND or an OR operator. Conditions on the same level are evaluated together:

• The AND operator requires that all conditions on the level it controls must be met.
• The OR operator requires that at least one of the conditions on the level it controls must be met.

For example, the following correlation rule trigger criteria contains two conditions, linked by OR . This means that the rule triggers if either condition is true, that is, if a host with an IP address is not in the 10.x.x.x subnet or if a host transmits an IGMP message.

In contrast, the following rule, which detects SSH activity on a non-standard port on the 10.4.x.x network and the 192.168.x.x network, has four conditions, with the bottom two constituting a complex condition.

This rule triggers if SSH is detected on a non-standard port; the first two conditions demand that the application protocol name is SSH and the port is not 22. The rule further requires that the IP address of the host involved in the event is in either the 10.4.x.x network or the 192.168.x.x network.

Logically, the rule is evaluated as follows:

 

Table 51-15 Rule Evaluation

Where...	Is the condition that states...
A	Application Protocol is SSH
B	Application Port is not 22
C	IP Address is in 10.4.0.0/8
D	IP Address is in 196.168.0.0/16

To add a single condition:

Access: Admin/Discovery Admin

---

Step 1 To add a single condition, click Add condition above the current condition.

A new condition is added below the current set of conditions, on the same level as the current set of conditions. By default, it is linked to the conditions on the same level with the OR operator, though you can change the operator to AND .

For example, if you add a simple condition to the following rule:

 

The result is:

 

---

 

To add a complex condition:

Access: Admin/Discovery Admin

---

Step 1 Click Add complex condition above the current condition.

A complex condition is added below the current set of conditions. The complex condition comprises two subconditions, which are linked to each other with the opposite operator from the one used to link the conditions on the level above it.

For example, if you add a complex condition to the following rule:

 

The result is:

 

---

 

To link conditions:

Access: Admin/Discovery Admin

---

Step 1 Use the drop-down list to the left of a set of conditions. Choose:

• the AND operator to require that all conditions on the level it controls be met
• the OR operator to require that only one of the conditions on the level it controls be met

---

 

Using Multiple Values in a Condition

License: Any

When you are building a condition, and the condition syntax allows you to pick a value from a drop-down list, you can often use multiple values from the list. For example, if you want to add a host profile qualification to a rule that requires that a host be running some flavor of UNIX, instead of constructing multiple conditions linked with the OR operator, use the following procedure.

To include multiple values in one condition:

Access: Admin/Discovery Admin

Step 1 Build a condition, choosing is in or is not in as the operator.

The drop-down list changes to a text field.

Step 2 Click anywhere in the text field or on the Edit link.

A pop-up window appears.

Step 3 Under Available , use Ctrl or Shift while clicking to select multiple values. You can also click and drag to select multiple adjacent values.

Step 4 Click the right arrow ( > ) to move the selected entries to Selected .

Step 5 Click OK .

The Create Rule page appears again. Your selections appear in the value field of your condition.

Modifying a Rule

License: Any

Use the following procedure to modify an existing correlation rule.

To modify an existing rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 If the rule is in a rule group, click the group name to expand the group.

Step 3 Next to the rule you want to modify, click the edit icon ( ).

The Create Rule page appears.

Step 4 Make modifications as necessary and click Save .

The rule is updated.

Deleting a Rule

License: Any

You cannot delete correlation rules that you are using in one or more correlation policies; you must first delete the rule from all policies in which it is included. For information on deleting a rule from a policy, see Editing a Correlation Policy.

To delete an existing rule:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 If the rule is in a rule group, click the group name to expand the group.

Step 3 Next to the rule you want to delete, click the delete icon ( ).

Step 4 Confirm that you want to delete the rule.

The rule is deleted.

Creating a Rule Group

License: Any

Create rule groups to help you organize correlation rules. The FireSIGHT System ships with many default rules, which are grouped according to function. For example, the Worms rule group comprises rules that detect activity by common worms. Note that rule groups exist only to help you organize correlation rules; you cannot assign a group of rules to a correlation policy. Instead, add each rule individually.

You can add a rule to an existing group when you create the rule. You can also modify an existing rule to add it to a group. For more information, see the following sections:

• Creating Rules for Correlation Policies
• Modifying a Rule

Tip To delete a rule group, click the delete icon () next to the group you want to delete. When you delete a rule group, rules that were in the group are not deleted. Rather, they merely become ungrouped

To create a rule group:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation , then select the Rule Management tab.

The Rule Management page appears.

Step 2 Click Create Group .

The Create Group page appears.

Step 3 In the Group Name field, type a name for the group.

Step 4 Click Add Group .

The group is added.

Creating a Response Group

License: Any

You can place individual alerts and remediations in response groups, which can then be assigned to rules within correlation policies so that a group of alerts and remediations can be launched when a policy is violated. After a group has been assigned to rules in active policies, changes to the group and to alerts or remediations within the group are automatically applied to active policies.

To create a response group:

Access: Admin

Step 1 Select Policies > Correlation , then click Groups .

The Groups page appears.

Step 2 Click Create Group .

The Response Group page appears.

Step 3 In the Name field, type a name for the new group.

Step 4 Select Active to activate the group so that you can use it in response to a correlation policy violation.

Step 5 From the Available Responses list, select the alerts and remediations you want to include in the group.

Tip Hold down the Ctrl key while clicking to select multiple responses.

Step 6 Click > to move alerts and remediations into the group.

Conversely, you can select alerts and remediations from the Responses in Group list and click < to move the alerts out of the response group.

Step 7 Click Save .

The group is created.

Modifying a Response Group

License: Any

Use the following procedure to modify a response group.

To modify a response group:

Access: Admin

Step 1 Select Policies > Correlation , then click Groups .

The Groups page appears.

Step 2 Click the edit icon ( ) next to the group you want to modify.

The Response Group page appears.

Step 3 Make changes as needed and click Save .

If the group is active and in use, the changes you made take effect immediately.

Deleting a Response Group

License: Any

You can delete a response group if it is not used in a correlation policy. Deleting a response group does not delete the responses in the group, just their association with each other.

To delete a response group:

Access: Admin

Step 1 Select Policies > Correlation , then click Groups .

The Groups page appears.

Step 2 Click the delete icon ( ) next to the group you want to delete.

Step 3 Confirm that you want to delete the group.

The group is deleted.

Activating and Deactivating Response Groups

License: Any

You can temporarily deactivate a response group without deleting it. This leaves the group on the system but does not launch it when a policy to which the group is assigned is violated. Note that if a response group is used in a correlation policy when you deactivate it, it is still considered in use even though it is deactivated; you cannot delete in-use response groups.

To activate or deactivate a response group:

Access: Admin

Step 1 Select Policies > Correlation , then click Groups .

The Groups page appears.

Step 2 Next to the response group you want to activate or deactivate, click the slider.

If the group was activated, it is deactivated. If it was deactivated, it is activated.

Providing Basic Policy Information

License: Any

You must give each policy an identifying name. Optionally, you can add a short description to the policy.

You can also assign a user-defined priority to your policy. If your correlation policy is violated, the resultant correlation events display the priority value you assign to the policy (unless the rule that was triggered has its own priority).

Note Rule and white list priorities override policy priorities. For more information, see Adding Rules and White Lists to a Correlation Policy.

To provide basic policy information:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, in the Policy Name field, type a name for the policy.

Step 2 In the Policy Description field, type a description for the policy.

Step 3 From the Default Priority drop-down list, select a priority for the policy.

You can select a priority value from 1 to 5, where 1 is highest and 5 is lowest. Or, you can select None to only use the priorities assigned to specific rules.

Step 4 Continue with the procedure in the next section, Adding Rules and White Lists to a Correlation Policy.

Adding Rules and White Lists to a Correlation Policy

License: Any

A correlation policy contains one or more correlation rules or white lists. When any rule or white list in a policy is violated, the system logs an event to the database. If you assigned one or more responses to the rule or white list, those responses are launched.

The following graphic shows a correlation policy composed of a compliance white list and a set of correlation rules, configured with a variety of responses.

z

To add rules or white lists to a correlation policy:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, click Add Rules .

The Available Rules pop-up appears.

Step 2 Click the appropriate folder name to expand it.

Step 3 Select the rules and white lists that you want to use in the policy and click Add .

The Create Policy page appears again. The rules and white lists you selected populate the policy.

Step 4 Continue with the procedure in the next section, Setting Rule and White List Priorities.

Setting Rule and White List Priorities

License: Any

You can assign a user-defined priority to each correlation rule or compliance white list in your correlation policy. If a rule or white list triggers, the resulting event displays the priority you assign to the rule or white list. On the other hand, if you do not assign a priority value and the rule or white list triggers, the resulting event displays the priority value of the policy.

For example, consider a policy where the policy itself has a priority of 1 and its rules or white lists are set with the default priority, with the exception of one rule given a priority of 3. If the priority 3 rule triggers, the resulting correlation event shows 3 as its priority value. If other rules or white lists in the policy trigger, the resulting events show 1 as their priority values, retained from the policy’s priority.

To set rule or white list priorities:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, from the Priority list for each rule or white list, select a default priority. You can select:

• a priority value from 1 to 5, where 1 is highest and 5 is lowest
• None
• Default to use the policy’s default priority

Step 2 Continue with the procedure in the next section, Adding Responses to Rules and White Lists.

Adding Responses to Rules and White Lists

License: Any

Within a correlation policy, you can map each rule or white list to a single response or to a group of responses. When any one of the rules or white lists in a policy is violated, the system logs an associated event to the database and launches the responses assigned to that rule or white list. If multiple rules or white lists within a policy trigger, the Defense Center launches the responses associated with each rule or white list.

For more information on creating responses and response groups, see:

• Configuring External Alerting
• Configuring Remediations
• Grouping Correlation Responses

Note Do not assign an Nmap remediation as a response to a correlation rule that triggers on a traffic profile change. The remediation will not launch.

The following graphic shows a correlation policy composed of a compliance white list and a set of correlation rules, configured with a variety of responses.

z

To add responses to rules and white lists:

Access: Admin/Discovery Admin

Step 1 On the Create Policy page, next to a rule or white list where you want to add responses, click the responses icon ( ).

A pop-up window appears.

Step 2 Under Unassigned Responses , select the response, multiple responses, or response group you want to launch when the rule or white list triggers, and click the up arrow.

Tip Hold down the Ctrl key while clicking to select multiple responses.

Step 3 Click Update .

The Create Policy page appears again. The responses you specified are added to the rule or white list.

Activating and Deactivating Correlation Policies

License: Any

Use the following procedure to either activate or deactivate a correlation policy.

To activate or deactivate a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation .

The Policy Management page appears.

Step 2 Next to the policy you want to activate or deactivate, click the slider.

If the policy was active, it is deactivated. If it was deactivated, it is activated.

Editing a Correlation Policy

License: Any

Use the following procedure to modify a correlation policy.

To edit a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation .

The Policy Management page appears.

Step 2 Click the edit icon ( ) next to the policy.

The Create Policy page appears. See Creating Correlation Policies for information on the various configurations you can change. To remove a rule or white list from a correlation policy, on the Create Policy page, click the delete icon ( ) next to the rule or white list you want to remove.

Step 3 Make changes as needed and click Save .

The policy is changed. If the policy is active, the changes you made take effect immediately.

Deleting a Correlation Policy

License: Any

Use the following procedure to delete a correlation policy.

To delete a policy:

Access: Admin/Discovery Admin

Step 1 Select Policies > Correlation .

The Policy Management page appears.

Step 2 Click the delete icon ( ) next to the policy you want to delete.

The policy is deleted.

Viewing Correlation Events

License: Any

You can view a table of correlation events, then manipulate the event view depending on the information you are looking for.

The page you see when you access correlation events differs depending on the workflow you use. You can use the predefined workflow, which includes the table view of correlation events. You can also create a custom workflow that displays only the information that matches your specific needs. For information on creating a custom workflow, see Creating Custom Workflows.

The following table describes some of the specific actions you can perform on an correlation events workflow page.

 

Table 51-16 Correlation Event Actions

To...	You can...
view the host profile for an IP address	click the host profile icon that appears next to the IP address.
view user profile information	click the user icon ( ) that appears next to the user identity. For more information, see Understanding User Details and Host History.
sort and constrain events on the current workflow page	find more information in Sorting Drill-Down Workflow Pages.
navigate within the current workflow page	find more information in Navigating to Other Pages in the Workflow.
navigate between pages in the current workflow, keeping the current constraints	click the appropriate page link at the top left of the workflow page. For more information, see Using Workflow Pages.
learn more about the columns that appear	find more information in Understanding the Correlation Events Table.
modify the time and date range for displayed events	find more information in see Setting Event Time Constraints. Note that events that were generated outside the appliance's configured time window (whether global or event-specific) may appear in an event view if you constrain the event view by time. This may occur even if you configured a sliding time window for the appliance.
drill down to the next page in the workflow, constraining on a specific value	use one of the following methods: on a drill-down page that you created in a custom workflow, click a value within a row. Note that clicking a value within a row in a table view constrains the table view and does not drill down to the next page. To drill down to the next workflow page constraining on some users, select the check boxes next to the users you want to view on the next workflow page, then click View . To drill down to the next workflow page keeping the current constraints, click View All . Tip Table views always include “Table View” in the page name. For more information, see Constraining Events.
delete correlation events from the system	use one of the following methods: To delete some events, select the check boxes next to the events you want to delete, then click Delete . To delete all events in the current constrained view, click Delete All , then confirm you want to delete all the events.
navigate to other event views to view associated events	find more information in Navigating Between Workflows.

To view correlation events:

Access: Admin/Any Security Analyst

---

Step 1 Select Analysis > Correlation > Correlation Events .

The first page of the default correlation events workflow appears. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings. If no events appear, you may need to adjust the time range; see Setting Event Time Constraints.

---

Tip If you are using a custom workflow that does not include the table view of correlation events, click (switch workflow), then select Correlation Events.

---

---

 

Understanding the Correlation Events Table

License: Any

When a correlation rule triggers, the Defense Center generates a correlation event. The fields in the correlation events table are described in the following table.

Searching for Correlation Events

License: Any

You can search for specific correlation events. You may want to create searches customized for your network environment, then save them to reuse later. The following table describes the search criteria you can use.

 

Table 51-18 Correlation Event Search Criteria

Field	Search Criteria Rules
Policy	Type the name of the correlation policy you want to search for.
Rule	Type the name of the correlation rule you want to search for.
Description	Type all or part of the correlation event description. The information in the description depends on the event that caused the rule to trigger.
Priority	Specify the priority of the correlation event, which is determined by the priority of either the triggered rule or the violated correlation policy. Enter none for no priority. For information on setting correlation rule and policy priorities, see Providing Basic Policy Information and Setting Rule and White List Priorities.
Source Country, Destination Country, or Source/Destination Country	Specify the country associated with the source, destination, or source or destination host IP addresses in the event that triggered the policy violation.
Source Continent, Destination Continent, or Source/Destination Continent	Specify the continent associated with the source, destination, or source or destination host IP addresses in the event that triggered the policy violation.
Security Intelligence Category	Specify the Security Intelligence category associated with the correlation event that triggered the policy violation. The Security Intelligence category can be the name of a Security Intelligence object, the global blacklist, a custom Security Intelligence list or feed, or one of the categories in the Intelligence Feed. For more information, see Blacklisting Using Security Intelligence IP Address Reputation.
Source IP, Destination IP, or Source/Destination IP	Specify the IP address of the source, destination, or source or destination hosts in the event that triggered the policy violation. You can specify a single IP address or address block, or a comma-separated list of either or both. You can also use negation. See Specifying IP Addresses in Searches for more information.
Source User or Destination User	Specify the user logged in to the source or destination host in the event that triggered the policy violation.
Source Port/ICMP Type or Destination Port/ICMP Code	Specify the source port or ICMP type for source traffic or destination port or ICMP code for destination traffic associated with the event that triggered the policy violation.
Impact	Specify the impact assigned to the correlation event. Valid case-insensitive values are Impact 0 , Impact Level 0 , Impact 1 , Impact Level 1 , Impact 2 , Impact Level 2 , Impact 3 , Impact Level 3 , Impact 4 , and Impact Level 4 . Do not use impact icon colors or partial strings (for example, do not use blue , level 1 , or 0 ). For more information, see Using Impact Levels to Evaluate Events.
Inline Result	For policy violations triggered by intrusion events, type either: dropped , to specify whether the packet was dropped in an inline, switched, or routed deployment would have dropped , to specify whether the packet would have dropped if the intrusion policy had been set to drop packets in an inline, switched, or routed deployment Note that the system does not drop packets in a passive deployment, including when an inline set is in tap mode, regardless of the rule state or the drop behavior of the intrusion policy.
Source Host Criticality or Destination Host Criticality	Specify the host criticality of the source or destination host involved in the policy violation: None , Low , Medium , or High . Note that only correlation events generated by rules based on discovery events, host input events, or connection events contain a source host criticality. For more information on host criticality, see Working with the Predefined Host Attributes.
Ingress Security Zone, Egress Security Zone, or Ingress/Egress Security Zone	Specify the ingress, egress, or ingress or egress security zone in the intrusion or connection event that triggered the policy violation.
Device	Type the device name or IP address, or a device group, stack, or cluster name to restrict the search to specific devices that generated events that triggered a policy violation. For more information on how the FireSIGHT System treats the device field in searches, see Specifying Devices in Searches.
Ingress Interface or Egress Interface	Specify the ingress or egress interface in the intrusion or connection event that triggered the policy violation.

To search for correlation events:

Access: Admin/Any Security Analyst

---

Step 1 Select Analysis > Search .

The Search page appears.

Step 2 Select Correlation Events from the table drop-down list.

The page updates with the appropriate constraints.

Step 3 Enter your search criteria in the appropriate fields, as described in the Correlation Event Search Criteria table:

• All fields accept negation ( ! ).
• All fields accept comma-separated lists of search values. Records that contain any of the listed values in the specified field match that search criteria.
• All fields accept comma-separated lists enclosed in quotation marks as search values.

– For fields that may contain only a single value, records with the specified field containing the exact string specified within the quotation marks match the search criteria. For instance, a search for A, B, "C, D, E" will match records where the specified field contains "A" or "B" or "C, D, E" . This permits matching on fields that include the comma in possible values.

– For fields that may contain multiple values at the same time, records with the specified fields containing all of the values in the quote-enclosed comma-separated list match that search criteria.

– For fields that may contain multiple values at the same time, search criteria may include single values as well as quote-enclosed comma-separated lists. For instance, a search for A, B, "C, D, E" on a field that may contain one of more of these letters matches records where the specified field contains A or B , or all of C , D , and E .

• Searches return only records that match the search criteria specified for all fields.
• Many fields accept one or more asterisks ( * ) as wild cards.
• Specify n/a in any field to identify events where information is not available for that field; use !n/a to identify the events where that field is populated.
• Click the add object icon (
) that appears next to a search field to use an object as a search criterion.

For more information on search syntax, including using objects in searches, see Searching for Events.

Step 4 Optionally, if you plan to save the search, you can select the Private check box to save the search as private so only you can access it. Otherwise, leave the check box clear to save the search for all users.

---

Tip If you want to use the search as a data restriction for a custom user role, you must save it as a private search.

---

Step 5 Optionally, you can save the search to be used again in the future. You have the following options:

• Click Save to save the search criteria.

For a new search, a dialog box appears prompting for the name of the search; enter a unique search name and click Save . If you save new criteria for a previously-existing search, no prompt appears. The search is saved (and visible only to your account if you selected Private ) so that you can run it at a later time.

• Click Save As New to save a new search or assign a name to a search you created by altering a previously-saved search.

A dialog box appears prompting for the name of the search; enter a unique search name and click Save . The search is saved (and visible only to your account if you selected Private ) so that you can run it at a later time.

Step 6 Click Search to start the search.

Your search results appear in the default correlation events workflow, constrained by the current time range. To use a different workflow, including a custom workflow, click (switch workflow) by the workflow title. For information on specifying a different default workflow, see Configuring Event View Settings.

---