Pre-Process Rules

Create incident pre-process rules in Cortex XSOAR 6.12.

Pre-Process rules enable you to perform certain actions on incidents as soon as they are ingested into Cortex XSOAR directly from the user interface. Through these rules, you can select incoming events on which to perform actions, for example, link the incoming incident to an existing incident, or under pre-configured conditions, drop the incoming incident altogether.

You can de-duplicate incidents by selecting the Link and Close action in the Pre-Process Rules tab. To create a pre-process rule, see Create Pre-Process Rules for Incidents. After you create a pre-process rule, in the Pre-Process Rules tab, you can do the following:

• View, edit, copy, or delete the Pre-Process Rule.
• Enable/disable the Pre-Process Rule.

The Link and Close action creates an entry in the Linked Incidents table of the existing incident to which you link, and closes the incoming incident. If an existing incident matching the defining criteria is not found an incident is created for the incoming event.

For troubleshooting, you might need to identify which pre-process rule was triggered. To store pre-process logs in a separate file, go to Settings → About → Troubleshooting → Add Server Configuration and add preprocess.logs.file with the value true.

Create Pre-Process Rules for Incidents

Pre-processing rules enable you to perform certain actions on incidents as they are ingested into Cortex XSOAR. You can, for example, link an incoming incident to an existing incident, or under certain conditions, drop the incoming incident altogether.

Note

Rules are applied in descending order, and only one rule is applied per incident.

1. Select Settings → OBJECTS SETUP → Incidents → Pre-Process Rules → New Rule.
2. In the Rule Name field, type a name for the rule.

   Give a meaningful name that helps you identify what the rule does. This will be useful when viewing the list of rules.
3. If you want the rule to apply to a specific incident, in the Conditions for Incoming incident section, click Add filter and set the incident field and value.

   For example, if you are running a phishing awareness campaign, you can create a rule for the email subject.

   You can add multiple conditions within a filter and add multiple filters. For more information about filters, see Filter Operators.
4. In the Action section, from the drop-down list determine which action to take if the incoming incident matches the rule.
5. Depending on the Action field, complete section 3.

   For example, in the Action field, if you select Drop and update, in section 3, complete the Update field.

   Section 3 enables you to link to an incoming event and update the incident depending on the selected filter. For information about the Action section and the fields in section 3, see Rule Actions for Pre-Process Rules.
6. (Multi-tenant) From the dropdown list, select the propagation label. When syncing from the main account to the tenant, the pre-processing rule is sent to the tenant based on the propagation label.
7. (Optional) In a remote repository or in a multi-tenant environment, you can view the relevant dependencies to ensure that all necessary dependencies are propagated or pushed to the remote repository.
8. (Optional) To check that the rules are effective and efficient, click Test.

   Testing is useful to check that you are receiving the desired results before putting a rule into production. We recommend you fetch data from an existing incident as a sample incident against which the rule can run. You can also manually enter JSON to use as a test sample or edit the JSON from an existing incident using the Edit button.
9. Click Save.

Pre-process rules examples

Drop incidents

When you run a phishing awareness campaign and send training emails to your employees, you want your employees to report the emails but you don't want to investigate. In this example, we create a condition for incoming incidents with the email subject You've Won the Best Employee Award, and drop those incidents without linking them to another incident.

preProcessing.png

Drop and update incidents

In this example, you want a pre-process rule to do the following:

• Apply to incidents that are ingested from the Sample Incident Generator.
• Drop incoming events and update the incident, if the name of the existing incident is identical to the incoming incident.

  You can add multiple conditionals to check for duplicates (not just the incident name) such as a Threat ID, incident ID, email, and host.

1. Create a pre-process rule.

   

   pre-process-rule-6.png
2. (Optional) Go to an incident and check the Context Data.

   You can see that 43,222 duplicate incidents have been dropped, as seen in the original incident.

   

   pre-process-context-6.png

   In the incident table, you can also see the number of dropped incidents.

   

   pre-process-table.png

   In the dashboard:

   

   pre-process-dash.png

Rule Actions for Pre-Process Rules

The following table describes the rule actions for pre-process rules.

Option	Description	Section 3
Drop	Drops the incoming incident and no incident is created.	None
Close	Closes the incoming incident.	None
Drop and update	Drops the incoming event, and updates the Dropped Duplicate Incidents table of the existing incident that you define. In addition, a War Room entry is created. If an existing incident matching the defined criteria is not found, an incident is created for the incoming event.	Update 1. Determine if you want to update the newest or oldest incident within a time range. 2. Select the incident you want to update together with the value.
Link	Creates an entry in the Linked Incidents table of the existing incident to which you link.	Link to 1. Determine if you want to link to the oldest or newest incident within a time range. 2. Select the incident you want to update together with the value.
Link and close	Creates an entry in the Linked Incidents table of the existing incident to which you link, and closes the incoming incident. If an existing incident matching the defined criteria is not found, an incident is created for the incoming event.	Link to 1. Determine if you want to link to the oldest or newest incident within a time range. 2. Select the incident you want to update together with the value.
Run a script	Select an automation to run on the incoming incident. When you create a script, you need to add the preProcessing tag for the script to appear in the list of available scripts. Note Pre-Process rules that use system-based automations such as GetIncidentsByQuery, by default, are run according to the defined role (Limited User). For example, if the GetIncidentsByQuery automation runs with the Limited User role, it also runs with the Limited User role in the Pre-Process rule. You can change the default by either detaching the automation and updating the RunAs field such as DbotRole, or create a wrapper automation with the required role set in the RunAs field. The wrapper automation calls the system-based automation. The system-based when called by the wrapper automation runs with the role assigned to the wrapper automation. Pre-processing automations can access sensitive incident data. As best practice, we recommend assigning a Role for the pre-processing script to allow only trusted users to edit it.	Choose a script From the dropdown list, select the script to run on the incoming incident. Only scripts that were tagged preProcessing appear in the drop-down list.