Correlation Policies

The following topics describe how to configure correlation policies and rules.

Introduction to Correlation Policies and Rules

You can use the correlation feature to respond in real time to threats to your network, using correlation policies.

A correlation policy violation occurs when the activity on your network triggers either a correlation rule or compliance allow list within an active correlation policy.

Correlation Rules

When a correlation rule in an active correlation policy triggers, the system generates a correlation event. Correlation rules can trigger when:

  • The system generates a specific type of event (connection, intrusion, malware, discovery, user activity, and so on).

  • Your network traffic deviates from its normal profile.

You can constrain correlation rules in the following ways:

  • Add a host profile qualification to constrain the rule using information from the host profile of a host involved in the triggering event.

  • Add a connection tracker to a correlation rule so that after the rule’s initial criteria are met, the system begins tracking certain connections. Then, a correlation event is generated only if the tracked connections meet additional criteria.

  • Add a user qualification to a correlation rule to track certain users or groups of users. For example, you can constrain a correlation rule so that it triggers only for a particular user's traffic, or traffic from a specific department.

  • Add snooze periods. When a correlation rule triggers, a snooze period causes that rule not to trigger again for a specified interval. After the snooze period elapses, the rule can trigger again and start a new snooze period.

  • Add inactive periods. During inactive periods, correlation rules do not trigger.

Although you can configure correlation rules without licensing your deployment, rules that use unlicensed components do not trigger.

Compliance Allow Lists

A compliance allow list specifies which operating systems, applications (web and client), and protocols are allowed on hosts on your network. When a host violates an allow list used in an active correlation policy, the system generates an allow list event.

Correlation Responses

Responses to correlation policy violations include simple alerts and various remediations (such as scanning a host). You can associate each correlation rule or allow list with a single response or group of responses.

If network traffic triggers multiple rules or allow lists, the system launches all the responses associated with each rule and allow list.

Correlation and Multitenancy

In a multidomain deployment, you can create correlation policies at any domain level, using whatever rules, allow lists, and responses are available at that level. Higher-level domain administrators can perform correlation within or across domains:

  • Constraining a correlation rule by domain matches events reported by that domain's descendants.

  • Higher-level domain administrators can create compliance allow lists that evaluate hosts across domains. You can target different subnets in different domains in the same allow list.


Note

The system builds a separate network map for each leaf domain. Using literal configurations (such as IP addresses, VLAN tags, and usernames) to constrain cross-domain correlation rules can have unexpected results.

Requirements and Prerequisites for Compliance

Model Support

Any

Supported Domains

Any

User Roles

  • Admin

Configuring Correlation Policies

Use correlation rules, compliance allow lists, alert responses, and remediations to build correlation policies.

In a multidomain deployment, you can create correlation policies at any domain level, using whatever constituent configurations are available at that level.

You can assign a priority to each correlation policy, and to each rule and allow list used in that policy. Rule and allow list priorities override correlation policy priorities. If network traffic violates the correlation policy, the resultant correlation events display the policy priority value, unless the violated rule or allow list has its own priority.

Procedure

Step 1

Choose Policies > Correlation.

Step 2

Click Create Policy.

Step 3

Enter a Policy Name and Policy Description.

Step 4

From the Default Priority drop-down list, choose a priority for the policy. Choose None to use rule priorities only.

Step 5

Click Add Rules, check the rules and allow lists that you want to use in the policy, then click Add.

Step 6

From the Priority list for each rule or allow list, choose a priority:

  • A priority value from 1 to 5
  • None
  • Default to use the policy’s default priority

Step 7

Add responses to rules and allow lists as described in Adding Responses to Rules and Allow Lists.

Step 8

Click Save.

What to do next

  • Activate the policy by clicking the slider.

Adding Responses to Rules and Allow Lists

You can associate each correlation rule or allow list with a single response or group of responses. If network traffic triggers multiple rules or allow lists, the system launches all the responses associated with each rule and allow list. Note that an Nmap remediation does not launch when used as a response to a traffic profile change.

In a multidomain deployment, you can use responses created in the current domain or in ancestor domains.

Procedure

Step 1

In the correlation policy editor, next to a rule or allow list where you want to add responses, click Responses (comment icon).

Step 2

Under Unassigned Responses, choose the responses you want to launch when the rule or allow list triggers, and click the up arrow (^).

Step 3

Click Update.

Managing Correlation Policies

Changes made to active correlation policies take effect immediately.

When you activate a correlation policy, the system immediately begins processing events and triggering responses. Note that the system does not generate allow list events for non-compliant hosts on its initial, post-activation evaluation.

In a multidomain deployment, the system displays correlation policies created in the current domain, which you can edit. It also displays selected correlation policies from ancestor domains, which you cannot edit. To view and edit correlation policies created in a lower domain, switch to that domain.


Note

The system does not display configurations from ancestor domains if the configurations expose information about unrelated domains, including names, managed devices, and so on.

Procedure

Step 1

Choose Policies > Correlation.

Step 2

Manage your correlation policies:

  • Activate or Deactivate — Click the slider. If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
  • Create — Click Create Policy; see Configuring Correlation Policies.
  • Edit — Click Edit (edit icon); see Configuring Correlation Policies. If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
  • Delete — Click Delete (delete icon). If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Configuring Correlation Rules

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 conditions. You can also create complex correlation rules, with multiple conditions and added constraints.

When you create correlation rule trigger criteria, host profile qualifications, user qualifications, or connection trackers, the syntax varies but the mechanics remain consistent.


Note

In a multidomain deployment, constraining a correlation rule by an ancestor domain matches events reported by that domain's descendants.

Before you begin

  • Confirm that your deployment is collecting the type of information you want to use to trigger correlation events. For example, 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. The system can add hosts to the network map from exported NetFlow records, but the available information for these hosts is limited; see Differences between NetFlow and Managed Device Data.

Procedure

Step 1

Choose Policies > Correlation, then click Rule Management.

Step 2

Click Create Rule.

Step 3

Enter a Rule Name and Rule Description.

Step 4

Optionally, choose a Rule Group for the rule.

Step 5

Choose a base event type and, optionally, specify additional trigger criteria for the correlation rule. You can choose the following base event types:

Step 6

Optionally, further constrain the correlation rule by adding any or all of the following:

  • Host Profile Qualification—Click Add Host Profile Qualification; see Syntax for Correlation Host Profile Qualifications.
  • Connection Tracker—Click Add Connection Tracker; see Connection Trackers.
  • User Qualification—Click Add User Qualification; see Syntax for User Qualifications.
  • Snooze Period—Under Rule Options, use the Snooze text field and drop-down list to specify the interval that the system should wait to trigger a correlation rule again, after the rule triggers.
  • Inactive Period—Under Rule Options, click Add Inactive Period. Using the text field and drop-down lists, specify when and how often you want the system to refrain from evaluating network traffic against the correlation rule.

Tip

 

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

Step 7

Click Save Rule.

Example Simple Correlation Rule

The following simple correlation rule triggers if a new host is detected in a specific subnet. Note that 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.

What to do next

Syntax for VPN Troubleshoot Event Trigger Criteria

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

Table 1. Syntax for VPN Troubleshoot Events

If you specify...

Choose an operator, then enter...

Device

Choose one or more devices with VPN troubleshoot syslog enabled.

Syslog Message Class

Choose the VPN syslog message class. When syslog with the selected message class is generated, it fulfils the correlation rule criteria and generates a correlation event.

Syslog Message ID

Specify the VPN syslog message IDs for the correlation rule.

Syslog Message Text

Specify the VPN syslog message text for the correlation rule.

Syslog Severity

Specify the VPN syslog severity. VPN troubleshoot syslog generated for the selected severity triggers the correlation event.

Username

Mention the VPN user name for whose traffic a correlation event need to be generated.

Syntax for Intrusion Event Trigger Criteria

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

Table 2. Syntax for Intrusion Events

If you specify...

Choose an operator, then...

Access Control Policy

Choose one or more access control policies that use the intrusion policy that generated the intrusion event.

Access Control Rule Name

Enter all or part of the name of the access control rule that uses the intrusion policy that generated the intrusion event.

Application Protocol

Choose one or more application protocols associated with the intrusion event.

Application Protocol Category

Choose one or more category of application protocol.

Classification

Choose one or more classifications.

Client

Choose one or more clients associated with the intrusion event.

Client Category

Choose one or more category of client.

Destination Country or Source Country

Choose one or more countries associated with the source or destination IP address in the intrusion event.

Destination IP, Source IP, Both Source IP and Destination IP, or Either Source IP or Destination IP

Enter a single IP address or address block.

Destination Port/ICMP Code or Source Port/ICMP Type

Enter the port number or ICMP type for source traffic or the port number or ICMP code for destination traffic.

Device

Choose one or more devices that may have generated the event.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Egress Interface or
 Ingress Interface

Choose one or more interfaces.

Egress Security Zone or Ingress Security Zone

Choose one or more security zones or tunnel zones.

Generator ID

Choose one or more preprocessors.

Impact Flag

Choose the impact level assigned to the intrusion event.

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.

Inline Result

Choose whether the system dropped or would have dropped packets as a result of the intrusion policy violation.

The system can drop packets in an inline, switched, or routed deployment. It does not drop packets in a passive deployment, including when an inline set is in tap mode, regardless of intrusion rule state or the drop behavior of the intrusion policy.

Intrusion Policy

Choose one or more intrusion policies that generated the intrusion event.

IOC Tag

Choose whether an indication of compromise tag was set as a result of the intrusion event.

Priority

Choose the rule priority.

For rule-based intrusion events, the priority corresponds to either the value of the priority keyword or the value for the classtype keyword. For other intrusion events, the priority is determined by the decoder or preprocessor.

Protocol

Enter the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

Rule Message

Enter all or part of the rule message.

Rule SID

Enter a single Snort ID (SID) or multiple SIDs separated by commas.

If you choose is in or is not in as the operator, you cannot use the multi-selection pop-up window. You must enter a comma-separated list of SIDs.

Rule Type

Specify whether the rule is local.

Local rules include custom standard text intrusion rules, standard text rules that you modified, and any new instances of shared object rules created when you saved the rule with modified header information.

SSL Actual Action

Choose the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Enter the fingerprint of the certificate used to encrypt the traffic, or choose a subject common name associated with the fingerprint.

SSL Certificate Subject Common Name (CN)

Enter all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Choose one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Enter all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Enter all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Flow Status

Choose one or more statuses based on the result of the system’s attempt to decrypt the traffic.

Username

Enter the username of the user logged into the source host in the intrusion event.

VLAN ID

Enter the innermost VLAN ID associated with the packet that triggered the intrusion event

Web Application

Choose one or more web applications associated with the intrusion event.

Web Application Category

Choose one or more category of web application.

Syntax for Malware Event Trigger Criteria

To base a correlation rule on a malware event, first specify the type of malware event you want to use. Your choice determines the set of trigger criteria you can use. You can choose:

  • by endpoint-based malware detection (detection by Secure Endpoint)

  • by network-based malware detection (detection by malware defense)

  • by retrospective network-based malware detection (retroactive detection by malware defense)

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

Table 3. Syntax for Malware Events

If you specify...

Choose an operator, then...

Application Protocol

Choose one or more application protocols associated with the malware event.

Application Protocol Category

Choose one or more category of application protocol.

Client

Choose one or more clients associated with the malware event.

Client Category

Choose one or more category of client.

Destination Country or Source Country

Choose one or more countries associated with the source or destination IP address in the malware event.

Destination IP, Host IP, or Source IP

Enter a single IP address or address block.

Destination Port/ICMP Code

Enter the port number or ICMP code for destination traffic.

Disposition

Choose either or both Malware or Custom Detection.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Event Type

Choose one or more event types associated with the malware event detected by Secure Endpoint.

File Name

Enter the name of the file.

File Type

Choose the file type.

File Type Category

Choose one or more file type categories.

IOC Tag

Choose whether an indication of compromise tag is or is not set as a result of the malware event.

SHA-256

Enter or paste the SHA-256 hash value of the file.

SSL Actual Action

Choose the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Enter the fingerprint of the certificate used to encrypt the traffic, or choose a subject common name associated with the fingerprint.

SSL Certificate Subject Common Name (CN)

Enter all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Choose one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Enter all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Enter all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Flow Status

Choose one or more statuses based on the result of the system’s attempt to decrypt the traffic.

Source Port/ICMP Type

Enter the port number or ICMP type for source traffic.

Web Application

Choose one or more web applications associated with the malware event.

Web Application Category

Choose one or more category of web application.

Syntax for Discovery Event Trigger Criteria

To base a correlation rule on a discovery event, first specify the type of discovery event you want to use. Your choice determines the set of trigger criteria you can use. The following table lists the discovery event types you can choose.

You cannot trigger a correlation rule on hops changes, or when the system drops a new host due to reaching the host limit. You can, however, choose there is any type of event to trigger the rule when any type of discovery event occurs.

Table 4. Correlation Rule Trigger Criteria vs Discovery Event Types

Choose this option...

To use this discovery event type...

a client has changed

Client Update

a client timed out

Client Timeout

a host IP address is reused

DHCP: IP Address Reassigned

a host is deleted because the host limit was reached

Host Deleted: Host Limit Reached

a host is identified as a network device

Host Type Changed to Network Device

a host timed out

Host Timeout

a host’s IP address has changed

DHCP: IP Address Changed

a NETBIOS name change is detected

NETBIOS Name Change

a new client is detected

New Client

a new IP host is detected

New Host

a new MAC address is detected

Additional MAC Detected for Host

a new MAC host is detected

New Host

a new network protocol is detected

New Network Protocol

a new transport protocol is detected

New Transport Protocol

a TCP port closed

TCP Port Closed

a TCP port timed out

TCP Port Timeout

a UDP port closed

UDP Port Closed

a UDP port timed out

UDP Port Timeout

a VLAN tag was updated

VLAN Tag Information Update

an IOC was set

Indication of Compromise

an open TCP port is detected

New TCP Port

an open UDP port is detected

New UDP Port

the OS information for a host has changed

New OS

the OS or server identity for a host has a conflict

Identity Conflict

the OS or server identity for a host has timed out

Identity Timeout

there is any kind of event

any event type

there is new information about a MAC address

MAC Information Change

there is new information about a TCP server

TCP Server Information Update

there is new information about a UDP server

UDP Server Information Update

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

Table 5. Syntax for Discovery Events

If you specify...

Choose an operator, then...

Application Protocol

Choose one or more application protocols.

Application Protocol Category

Choose one or more category of application protocol.

Application Port

Enter the application protocol port number.

Client

Choose one or more clients.

Client Category

Choose one or more category of client.

Client Version

Enter the version number of the client.

Device

Choose one or more devices that may have generated the discovery event.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Hardware

Enter the hardware model for the mobile device. For example, to match all Apple iPhones, enter iPhone.

Host Type

Choose one or more host types. You can choose between a host or one of several types of network device.

IP Address or
New IP Address

Enter a single IP address or address block.

Jailbroken

Choose Yes to indicate that the host in the event is a jailbroken mobile device or No to indicate that it is not.

MAC Address

Enter all or part of the MAC address of the host.

For example, if you know that devices from a certain hardware manufacturer have MAC addresses that begin with 0A:12:34, you could choose begins with as the operator, then enter 0A:12:34 as the value.

MAC Type

Choose whether the MAC address was ARP/DHCP Detected.

That is, choose whether the system positively identified the MAC address as belonging to the host (is ARP/DHCP Detected), or whether the system is seeing many hosts with that MAC address because, for example, there is a router between the managed device and the host (is not ARP/DHCP Detected).

MAC Vendor

Enter all or part of the name of the MAC hardware vendor of the NIC used by the network traffic that triggered the discovery event.

Mobile

Choose Yes to indicate that the host in the event is a mobile device or No to indicate that it is not.

NETBIOS Name

Enter the NetBIOS name of the host.

Network Protocol

Enter the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

OS Name

Choose one or more operating system names.

OS Vendor

Choose one or more operating system vendors.

OS Version

Choose one or more operating system versions.

Protocol or
Transport Protocol

Enter the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

Source

Choose the source of the host input data (for operating system and server identity changes and timeouts).

Source Type

Choose the type of the source for the host input data (for operating system and server identity changes and timeouts).

VLAN ID

Enter the VLAN ID of the host involved in the event.

Web Application

Choose a web application.

Syntax for User Activity Event Trigger Criteria

To base a correlation rule on user activity, first choose the type of user activity you want to use. Your choice determines the set of trigger criteria you can use. You can choose:

  • a new user identity is detected
  • a user logs into a host

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

Table 6. Syntax for User Activity

If you specify...

Choose an operator, then...

Device

Choose one or more devices that may have detected the user activity.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

IP Address

Enter a single IP address or address block.

Username

Enter a username.

Syntax for Host Input Event Trigger Criteria

To base a correlation rule on a host input event, first specify the type of host input event you want to use. Your choice determines the set of trigger criteria you can use. The following table lists the host input event types you can choose.

You cannot trigger a correlation rule when you add, delete, or change the definition of a user-defined host attribute, or set a vulnerability impact qualification.

Table 7. Correlation Rule Trigger Criteria vs Host Input Event Types

Choose this option...

To trigger the rule on this event type...

a client is added

Add Client

a client is deleted

Delete Client

a host is added

Add Host

a protocol is added

Add Protocol

a protocol is deleted

Delete Protocol

a scan result is added

Add Scan Result

a server definition is set

Set Server Definition

a server is added

Add Port

a server is deleted

Delete Port

a vulnerability is marked invalid

Vulnerability Set Invalid

a vulnerability is marked valid

Vulnerability Set Valid

an address is deleted

Delete Host/Network

an attribute value is deleted

Host Attribute Delete Value

an attribute value is set

Host Attribute Set Value

an OS definition is set

Set Operating System Definition

host criticality is set

Set Host Criticality

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

Table 8. Syntax for Host Input Events

If you specify...

Choose an operator, then...

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

IP Address

Enter a single IP address or address block.

Source

Choose the source for the host input data.

Source Type

Choose the type of the source for the host input data.

Syntax for Connection Event Trigger Criteria

To base a correlation rule on a connection event, first specify the type of connection event you want to use. Note that the information available for a connection event can vary depending on how, why, and when the system logged the connection. You can choose:

  • at either the beginning or the end of the connection

  • at the beginning of the connection

  • at the end of the connection

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

Table 9. Syntax for Connection Events

If you specify...

Choose an operator, then...

Access Control Policy

Choose one or more access control policies that logged the connection.

Access Control Rule Action

Choose one or more actions associated with the access control rule that logged the connection.

Choose Monitor to trigger correlation events when network traffic matches the conditions of any Monitor rule, regardless of the rule or default action that later handles the connection.

Access Control Rule

Enter all or part of the name of the access control rule that logged the connection.

You can enter the name of any Monitor rule whose conditions were matched by a connection, regardless of the rule or default action that later handled the connection.

Application Protocol

Choose one or more application protocols associated with the connection.

Application Protocol Category

Choose one or more categories of application protocol.

Client

Choose one or more clients.

Client Category

Choose one or more categories of client.

Client Version

Enter the version number of the client.

Connection Duration

Enter the duration of the connection event, in seconds.

Connection Type

Specify whether you want to trigger the correlation rule based on how the connection information was obtained:

  • Choose is and Netflow for connection events generated from exported NetFlow data.

  • Choose is not and Netflow for connection events detected by a managed device.

Destination Country or Source Country

Choose one or more countries associated with the source or destination IP address in the connection event.

Device

Choose one or more devices that either detected the connection, or that processed the connection (for connection data from exported NetFlow records).

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Egress Interface or
 Ingress Interface

Choose one or more interfaces.

Egress Security Zone or
 Ingress Security Zone

Choose one or more security zones or tunnel zones.

Initiator Bytes,
Responder Bytes, or Total Bytes

Enter one of:

  • The number of bytes sent (Initiator Bytes).

  • The number of bytes received (Responder Bytes).

  • The number of bytes both sent and received (Total Bytes).

Initiator IP,
Responder IP, Both Initiator and Responder IP, or Either Initiator IP or Responder IP

Specify a single IP address or address block.

Initiator Packets, 
Responder Packets, or
Total Packets

Enter one of:

  • The number of packets sent (Initiator Packets).

  • The number of packets received (Responder Packets).

  • The number of packets both sent and received (Total Packets)

Initiator Port/ICMP Type or Responder Port/ICMP Code

Enter the port number or ICMP type for initiator traffic or the port number or ICMP code for responder traffic.

IOC Tag

Specify whether an indication of compromise tag is or is not set due to the connection event.

NetBIOS Name

Enter the NetBIOS name of the monitored host in the connection.

NetFlow Device

Choose the IP address of the NetFlow exporter you want to use to trigger the correlation rule. If you did not add any NetFlow exporters to the network discovery policy, the NetFlow Device drop-down list is blank.

Prefilter Policy

Choose one or more prefilter policies that handled the connection.

Reason

Choose one or more reasons associated with the connection event.

Security Intelligence Category

Choose one or more Security Intelligence categories associated with the connection event.

To use Security Intelligence Category as a condition for end-of-connection events, set that category to Monitor instead of Block in your access control policy.

SSL Actual Action

Specify the SSL rule action that indicates how the system handled an encrypted connection.

SSL Certificate Fingerprint

Enter the fingerprint of the certificate used to encrypt the traffic, or choose a subject common name associated with the fingerprint.

SSL Certificate Status

Choose one or more statuses associated with the certificate used to encrypt the session.

SSL Certificate Subject Common Name (CN)

Enter all or part of the subject common name of the certificate used to encrypt the session.

SSL Certificate Subject Country (C)

Choose one or more subject country codes of the certificate used to encrypt the session.

SSL Certificate Subject Organization (O)

Enter all or part of the subject organization name of the certificate used to encrypt the session.

SSL Certificate Subject Organizational Unit (OU)

Enter all or part of the subject organizational unit name of the certificate used to encrypt the session.

SSL Cipher Suite

Choose one or more cipher suites used to encrypt the session.

SSL Encrypted Session

Choose Successfully Decrypted.

SSL Flow Status

Choose one or more statuses based on the result of the system’s attempt to decrypt the traffic.

SSL Policy

Choose one or more SSL policies that logged the encrypted connection.

SSL Rule Name

Enter all or part of the name of the SSL rule that logged the encrypted connection.

SSL Server Name

Enter all or part of the name of the server with which the client established an encrypted connection.

SSL URL Category

Choose one or more URL categories for the URL visited in the encrypted connection.

SSL Version

Choose one or more SSL or TLS versions used to encrypt the session.

TCP Flags

Choose a TCP flag that a connection event must contain in order to trigger the correlation rule. Only connection data generated from NetFlow records contains TCP flags.

Transport Protocol

Enter the transport protocol used by the connection: TCP or UDP.

Tunnel/Prefilter Rule

Enter all or part of the name of the tunnel or prefilter rule that handled the connection.

URL

Enter all or part of the URL visited in the connection.

URL Category

Choose one or more URL categories for the URL visited in the connection.

URL Reputation

Choose one or more URL reputation values for the URL visited in the connection.

Username

Enter the username of the user logged in to either host in the connection.

Web Application

Choose one or more web applications associated with the connection.

Web Application Category

Choose one or more categories of web application.

Syntax for Traffic Profile Changes

To base a correlation rule on a traffic profile change, first choose the traffic profile you want to use. The rule triggers when network traffic deviates from the pattern characterized by the profile you choose.

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 bytes

  • 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.

Check the use velocity data check box 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.

Table 10. Syntax for Traffic Profile Changes

If you specify...

Choose an operator, then enter...

Then choose one of...

Number of Connections

the total number of connections detected

or

the number of standard deviations either above or below the mean that the number of connections detected must be in to trigger the rule

connections

standard deviation(s)

Total Bytes, Initiator Bytes, or Responder Bytes

one of:

  • the total bytes transmitted (Total Bytes)

  • the number of bytes transmitted (Initiator Bytes)

  • the number of bytes received (Responder Bytes)

or

the number of standard deviations either above or below the mean that one of the above criteria must be in to trigger the rule

bytes

standard deviation(s)

Total Packets, Initiator Packets, or Responder Packets

one of:

  • the total packets transmitted (Total Packets)

  • the number of packets transmitted (Initiator Packets)

  • the number of packets received (Responder Packets)

or

the number of standard deviations either above or below the mean that one of the above criteria must be in trigger the rule

packets

standard deviation(s)

Unique Initiators

the number of unique hosts that initiated sessions

or

the number of standard deviations either above or below the mean that the number of unique initiators detected must be to trigger the rule

initiators

standard deviation(s)

Unique Responders

the number of unique hosts that responded to sessions

or

the number of standard deviations either above or below the mean that the number of unique responders detected must be to trigger the rule

responders

standard deviation(s)

Syntax for Correlation Host Profile Qualifications

To constrain a correlation rule based on the host profile of a host involved in the event, add a host profile qualification. 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.

When you build a host profile qualification, first specify the host you want to use to constrain your correlation rule. The host you can choose depends on the rule's base event type:

  • connection event — Choose Responder Host or Initiator Host.

  • intrusion event — Choose Destination Host or Source Host.

  • discovery event, host input event, or user activity — Choose Host.

The following table describes how to build a host profile qualification for a correlation rule.

Table 11. Syntax for Host Profile Qualifications

If you specify...

Choose an operator, then...

Application Protocol >
Application Protocol

Choose an application protocol.

Application Protocol >
Application Port

Enter the application protocol port number.

Application Protocol >
Protocol

Choose a protocol.

Application Protocol Category

Choose a category.

Client > Client

Choose a client.

Client > Client Version

Enter the client version.

Client Category

Choose a category.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Hardware

Enter the hardware model for the mobile device. For example, to match all Apple iPhones, enter iPhone.

Host Criticality

Choose the host criticality.

Host Type

Choose one or more host types. You can choose between a normal host or one of several types of network device.

IOC Tag

Choose one or more indication of compromise tags.

Jailbroken

Choose Yes to indicate that the host in the event is a jailbroken mobile device or No to indicate that it is not.

MAC Address > MAC Address

Enter all or part of the MAC address of the host.

MAC Address > MAC Type

Choose whether the MAC type is ARP/DHCP detected:

  • the system positively identified the MAC address as belonging to the host (is ARP/DHCP Detected)

  • the system is seeing many hosts with that MAC address because, for example, there is a router between the device and the host (is not ARP/DHCP Detected)

  • the MAC type is irrelevant (is any)

MAC Vendor

Enter all or part of the MAC vendor of hardware used by the host.

Mobile

Choose Yes to indicate that the host in the event is a mobile device or No to indicate that it is not.

NetBIOS Name

Enter the NetBIOS name of the host.

Network Protocol

Enter the network protocol number as listed in http://www.iana.org/assignments/ethernet-numbers.

Operating System > OS Vendor

Choose one or more operating system vendor names.

Operating System > OS Name

Choose one or more operating system names.

Operating System > OS Version

Choose one or more operating system versions.

Transport Protocol

Enter the name or number of the transport protocol as listed in http://www.iana.org/assignments/protocol-numbers.

VLAN ID

Enter the VLAN ID number of the host.

Web Application

Choose a web application.

Web Application Category

Choose a category.

any available host attribute, including the default compliance allow list host attribute

Enter or choose the appropriate value, depending on the host attribute type.

Using Implied or Generic Clients to Build a Host Profile Qualification

When system reports a detected client using an application protocol name followed by client (for example, HTTPS client) , that client is an implied or generic client. In these cases, the system has not detected a particular client, but is inferring the existence of a client based on server response traffic.

To create a host profile qualification using an implied or generic client, constrain using the application protocol running on the responder host, not the client.

Using Event Data to Build a Host Profile Qualification

You can often use data from the correlation rule's base event when constructing a host profile qualification.

For example, assume your correlation rule triggers when the system detects the use of a particular browser on one of your monitored hosts. Further assume that when you detect this use, you want to generate an event if the browser version is not the latest.

You could add a host profile qualification to this correlation rule so that the rule triggers only if the Client is the Event Client, but the Client Version is not the latest version.

Example Host Profile Qualification

The following host profile qualification constrains a correlation rule so 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.

Syntax for User Qualifications

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. 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.

You cannot add a user qualification to a correlation rule that triggers on a traffic profile change or on the detection of user activity. Also, the system obtains user details through the management center-server connection established in an identity realm. This information may not be available for all users in the database.

When you build a user qualification, first specify the identity you want to use to constrain your correlation rule. The identity you can choose depends on the rule's base event type:

  • connection event — Choose Identity on Initiator or Identity on Responder.

  • intrusion event — Choose Identity on Destination or Identity on Source.

  • discovery event — Choose Identity on Host.

  • host input event — Choose Identity on Host.

The following table describes how to build a user qualification for a correlation rule.

Table 12. Syntax for User Qualifications

If you specify...

Choose an operator, then...

Authentication Protocol

Choose the authentication protocol (or user type) protocol used to detect the user.

Department

Enter a department.

Domain

Choose one or more domains. In a multidomain deployment, constraining by an ancestor domain matches data reported by that domain's descendants. This field is only present if you have ever configured the management center for multitenancy.

Email

Enter an email address.

First Name

Enter a first name.

Last Name

Enter a last name.

Phone

Enter a telephone number.

Username

Enter a username.

Connection Trackers

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 system generates a correlation event for the rule if the tracked connections meet additional criteria gathered over a time period that you specify.


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.

There are two ways a connection tracker can generate an event.

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.

However, if time expires before network traffic meets the conditions in the connection tracker, the system 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.

Adding a Connection Tracker

Before you begin

  • Create a correlation rule based on a connection, intrusion, discovery, user identity, or host input event. You cannot add a connection tracker to a rule based on a VPN troubleshoot event, malware event or traffic profile change.

Procedure

Step 1

In the correlation rule editor (Polices > Correlation > Rule Management), click Edit, and then click Add Connection Tracker.

Step 2

Specify the connections to track; see Syntax for Connection Trackers.

Step 3

Based on the tracked connections, specify when you want to generate a correlation event; see Syntax for Connection Tracker Events.

Step 4

Specify the interval (in seconds, minutes, or hours) during which the tracker's conditions must be met.

Syntax for Connection Trackers

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

Table 13. Syntax for Connection Trackers

If you specify...

Choose an operator, then...

Access Control Policy

Choose one or more access control policies that handled the connections you want to track.

Access Control Rule Action

Choose one or more access control rule actions associated with the access control rule that logged the connections you want to track.

Choose Monitor to track connections that match the conditions of any Monitor rule, regardless of the rule or default action that later handles the connections.

Access Control Rule Name

Enter all or part of the name of the access control rule that logged the connections you want to track.

To track connections that match a Monitor rule, enter the name of the Monitor rule. The system tracks the connections, regardless of the rule or default action that later handles them.

Application Protocol

Choose one or more application protocols.

Application Protocol Category

Choose one or more application protocol categories.

Client

Choose one or more clients.

Client Category

Choose one or more client categories.

Client Version

Enter the version of the client.

Connection Duration

Enter the connection duration, in seconds.

Connection Type

Specify whether you want to trigger the correlation rule based on how the connection information was obtained:

  • Choose is and Netflow for connection events generated from exported NetFlow records.

  • Choose is not and Netflow for connection events detected by a managed device.

Destination Country or Source Country

Choose one or more countries.

Device

Choose one or more devices whose detected connections you want to track. If you want to track NetFlow connections, choose the devices that process the connection data from exported NetFlow records.

Ingress Interface or Egress Interface

Choose one or more interfaces.

Ingress Security Zone or
 Egress Security Zone

Choose one or more security zones or tunnel zones.

Initiator IP, Responder IP, or
Initiator/Responder IP

Enter a single IP address or address block.

Initiator Bytes, Responder Bytes, or
 Total Bytes

Enter one of:

  • the number of bytes transmitted (Initiator Bytes)

  • the number of bytes received (Responder Bytes)

  • the number of bytes both transmitted and received (Total Bytes)

Initiator Packets,
Responder Packets, or
Total Packets

Enter one of:

  • the number of packets transmitted (Initiator Packets)

  • the number of packets received (Responder Packets)

  • the number of packets both transmitted and received (Total Packets)

Initiator Port/ICMP Type or Responder Port/ICMP Code

Enter the port number or ICMP type for initiator traffic or the port number or ICMP code for responder traffic.

IOC Tag

Choose whether an indication of compromise tag is or is not set.

NETBIOS Name

Enter the NetBIOS name of the monitored host in the connection.

NetFlow Device

Choose the IP address of the NetFlow exporter you want to track. If you did not add any NetFlow exporters to the network discovery policy, the NetFlow Device drop-down list is blank.

Prefilter Policy

Choose one or more prefilter policies that handled the connections you want to track.

Reason

Choose one or more reasons associated with the connections you want to track.

Security Intelligence Category

Choose one or more Security Intelligence categories associated with the connections you want to track.

TCP Flags

Choose the TCP flag that connections must contain in order to track them. Only connections generated from exported NetFlow records contain TCP flag data.

Transport Protocol

Choose the transport protocol used by the connection.

URL

Enter all or part of the URL visited in the connections you want to track.

URL Category

Choose one or more URL categories for the URL visited in the connections you want to track.

URL Reputation

Choose one or more URL reputation values for the URL visited in the connections you want to track

Username

Enter the username of the user logged into either host in the connections you want to track.

Web Application

Choose one or more web applications.

Web Application Category

Choose one or more web application categories.

Using Event Data to Build a Connection Tracker

You can often use data from the correlation rule's base event when constructing a connection tracker.

For example, assume your correlation rule triggers when the system detects a new client. When you add a connection tracker to this type of correlation rule, the system automatically populates the tracker with constraints that refer to the base event:

  • The Initiator/Responder IP is set to the Event IP Address.

  • The Client is set to the Event Client.


Tip

To 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

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

Table 14. Syntax for Connection Tracker Events

If you specify...

Choose an operator, then enter...

Number of Connections

the total number of connections detected

Number of SSL Encrypted Sessions

the total number of SSL- or TLS-encrypted sessions detected

Total Bytes,
 Initiator Bytes, or 
Responder Bytes

one of:

  • the total bytes transmitted (Total Bytes)

  • the number of bytes transmitted (Initiator Bytes)

  • the number of bytes received (Responder Bytes)

Total Packets,
 Initiator Packets, or
 Responder Packets

one of:

  • the total packets transmitted (Total Packets)

  • the number of packets transmitted (Initiator Packets)

  • the number of packets received (Responder Packets)

Unique Initiators or 
Unique Responders

one of:

  • the number of unique hosts that initiated sessions that were detected (Unique Initiators)

  • the number of unique hosts that responded to connections that were detected (Unique Responders)

Sample Configuration for 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 system 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.

Diagram illustrating network traffic triggering a 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:

  • First, the system starts tracking connections when it detects a connection from Host A outside the network to Host 1 inside the network.

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

  • 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.

  • Finally, the system generates a correlation event and the system stops tracking connections.

Sample Configuration for 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.

Diagram illustrating network traffic triggering a 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:

  • First, 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).

  • 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)

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

  • 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 system would not generate a correlation event.

  • However, at 30 seconds, the system detects another BitTorrent transfer, and the rule conditions are met:

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

  • Finally, the system generates a correlation event. The system 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 system 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.

Snooze and Inactive Periods

You can configure snooze periods in correlation rules. When a correlation rule triggers, a snooze period instructs the system 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 system 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.

Correlation Rule Building Mechanics

You build a correlation rule by specifying the conditions under which it triggers. The syntax you can use within conditions varies depending on the element you are creating, but the mechanics are the same.

Most conditions have three parts: a category, an operator, and a value:

  • The categories you can choose 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 the base event type for the rule. Some conditions may contain several categories, each of which may have their own operators and values.

  • A condition’s available operators depend on the category.

  • The syntax you can use to specify a condition’s value depends on the category and operator. Sometimes you type the value in a text field. Other times, you can choose a value (or multiple values) from a drop-down list.

For example, if you want to generate a correlation event every time a new host is detected, you can create a simple rule with no conditions.

If you want 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.

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.

The following rule, which detects SSH activity on a nonstandard 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.

Logically, the rule is evaluated as follows: 


	(A and B and (C or D))
Table 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.0.0.0/8

D

IP Address is in 196.168.0.0/16


Caution

Evaluating complex correlation rules that trigger on frequently occurring events can degrade system performance. For example, a multicondition rule that the system must evaluate against every logged connection can cause resource overload.

Adding and Linking Conditions in Correlation Rules

Procedure

Step 1

In the correlation rule editor (Polices > Correlation > Rule Management), add a simple or complex condition:

  • Simple — Click Add condition.
  • Complex — Click Add complex condition.

Step 2

Link conditions by choosing the AND or OR operator from the drop-down list to the left of the conditions.

Example: Simple vs Complex Conditions

The following graphic shows a correlation rule with two simple conditions joined by the OR operator.

The following graphic shows a correlation rule with one simple condition and one complex condition, joined by the OR operator. The complex condition comprises two simple conditions joined by the AND operator.

Using Multiple Values in Correlation Rule Conditions

When you are building a correlation 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.

Procedure

Step 1

In the correlation rule editor, build a condition, choosing is in or is not in as the operator.

Step 2

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

Step 3

Under Available, choose multiple values. You can also click and drag to choose multiple adjacent values.

Step 4

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

Step 5

Click OK.

Managing Correlation Rules

In a multidomain deployment, the system displays correlation rules and groups created in the current domain, which you can edit. It also displays selected correlation rules and groups from ancestor domains, which you cannot edit. To view and edit correlation rules and groups created in a lower domain, switch to that domain.


Note

The system does not display configurations from ancestor domains if the configurations expose information about unrelated domains, including names, managed devices, and so on.

Changes made to rules in active correlation policies take effect immediately.

Before you begin

Procedure

Step 1

Choose Policies > Correlation, then click Rule Management.

Step 2

Manage your rules:

  • Create — Click Create Rule; see Configuring Correlation Rules.
  • Create Group — Click Create Group, enter a name for the group, and click Save. To add a rule to a group, edit the rule.
  • Edit — Click Edit (edit icon); see Configuring Correlation Rules. If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
  • Delete Rule or Rule Group— Click Delete (delete icon). Deleting a rule group ungroups the rules. If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Configuring Correlation Response Groups

You can create a correlation response group of alerts and remediations, then activate and assign the group to a correlation rule within an active correlation policy. The system launches all the grouped responses when network traffic matches the correlation rule.

When used in an active correlation policy, changes to an active group or any of its grouped responses take affect immediately.

Procedure

Step 1

Choose Policies > Correlation, then click Groups.

Step 2

Click Create Group.

Step 3

Enter a Name.

Step 4

Check the Active check box if you want to activate the group upon creation.

Deactivated groups do not launch responses.

Step 5

Choose the Available Responses to group. then click the right arrow (>) to move them to the Responses in Group. To move responses the other way, use the left arrow (<).

Step 6

Click Save.

What to do next

  • If you did not activate the group upon creation and you want to activate it now, click the slider.

Managing Correlation Response Groups

You can delete a response group if it is not used in a correlation policy. Deleting a response group ungroups its responses. You can also temporarily deactivate a response group without deleting it. This leaves the group on the system but does not launch it when policies are violated.

In a multidomain deployment, the system displays groups created in the current domain, which you can edit. It also displays groups created in ancestor domains, which you cannot edit. To view and edit groups created in a lower domain, switch to that domain.

Changes made to active, in-use response groups take effect immediately.

Procedure

Step 1

Choose Policies > Correlation, then click Groups.

Step 2

Manage response groups:

  • Activate or Deactivate — Click the slider. If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
  • Create — Click Create Group; see Configuring Correlation Response Groups.
  • Edit — Click Edit (edit icon); see Configuring Correlation Response Groups. If View (View button) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
  • Delete — Click Delete (delete icon). If the controls are dimmed, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.